Port PayPal payment methods to D8

We haven't ported anything but the internal payment methods (check, COD, other) to D8 yet. See #2621258: Decide on payment methods to ship with 8.x-4.x

I personally haven't put any effort into PayPal because I feel the effort is better spent integrating with Payment. I believe that our own Ubercart-specific version of PayPal is a dead end and it's a waste of time to work on it for D8.

PayPal Express Checkout is a payment method in Ubercart, so you will have to implement an Ubercart PaymentMethod plugin. Yes, you can write this in 1 week. Normally I'd say 20 hours to do a payment method since it requires a lot of research and testing to make sure you're doing it right - you don't want bugs in a payment method! But it will probably take you longer than normal because there is some porting to D8 to do as well - variables to config etc.

Use uc_payment_pack (which implements 3 payment methods) as an example. PayPal WPS is also a payment method so the same advice applies. PayPal WPP is a payment *gateway* and we currently don't have a plugin definition for payment gateways, so that would require considerably more work.

Oh and for the test fail above, the route to the admin page for your method is defined in uc_payment, and until you implement the plugin your test won't work. Again, see uc_payment_pack for an example.

One other thing, many of your patches show "\ No newline at end of file" - please make sure that the last character in each file is \n (newline) to prevent this from happening.

Well you're right, this was hard to review. Largely because it's only a partial port - there is still a huge amount of work to do. Part of the problem is that we've made extensive changes to Ubercart in the past month so a lot of the patch needed to be updated, and a lot will have to be reworked now that payment methods are plugins and not hooks.

I've made a lot of changes to the patch and took out some stuff (like the tests, since they no longer work). I'm just going to commit this, if it passes the tests, because it takes us part way there. But there's still a lot more to do which I hope to get done in the next few days.

Hmm, a 0 byte patch? How did that happen? Here it is again ...

Ah that's the same old intermittent error we've been getting for a while. Let me just retest until it works ...

OK, so it worked. I'm committing this but leaving the issue at "Needs work" because there's still a lot to do.

A very large patch for the testbot to look at. Still not done, but getting there fast ...

I didn't mean to include the tests in that patch - I know they're not working yet ... Here's the patch without the tests.

Committed that hunk. Setting back to needs work again, until it's ready to use.

Both EC and WPS are payment methods, so the can both be ported.

Here's my latest patch for the testbot to look at.

Back to work ...

Remove $_SESSION

Committed, back to needs work.

With this patch applied, I have successfully completed checkout through the PayPal WPS sandbox. The IPN isn't yet handled correctly but it's a start!

We still use $_SESSION for do_complete.

wps_no_shipping should be boolean. If you're getting a variable type conflict in config inspector it's because you had paypal installed before I pushed the schema yesterday and Drupal made an assumption about the type - you have to uninstall then reinstall paypal to make that go away. And in PayPalWebsitePaymentsStandard.php it should probably be initialized to TRUE instead of 1.

Instead of restoring the use of $_SESSION here, why not finish removing it in uc_cart? Most places have been switched to grabbing it from the session service rather than using the superglobal, so I'd rather not go back.

Otherwise looking real good ...

It's definitely a string (or perhaps an integer, if we change the keys):

    $form['wps_no_shipping'] = array(
      '#type' => 'radios',
      '#title' => $this->t('Shipping address prompt in PayPal'),
      '#options' => array(
        '1' => $this->t('Do not show shipping address prompt at PayPal.'),
        '0' => $this->t('Prompt customer to include a shipping address.'),
        '2' => $this->t('Require customer to provide a shipping address.'),
      ),
      '#default_value' => $this->configuration['wps_no_shipping'],
    );

The incorrect type took me some time to track down. With it set to boolean, sending <input name="no_shipping" value> (ie. with no value attribute at all) causes PayPal to throw a nondescript error.

I intend to finish the $_SESSION conversion elsewhere, I will open a new issue for that.

Oh OK, thanks for catching that.

Let's start tagging ...

This patch converts the 'redirect' key to an interface so the form can be contained inside the plugin. This will break 2Checkout but that can be fixed later.

Still to do for PayPal WPS:

• Rename to PayPal Payments Standard (WPS is the old name)
• Get IPN working
• Check that the PayPal variables are up to date
• Use currency from the order instead of configuration
• Check whether we can simplify any of the other configuration options|

Can you make the change to uc_2checkout while it's still fresh in your mind?

Fixed 2Checkout in http://cgit.drupalcode.org/ubercart/commit/?id=709e4e8, the form output looks okay but I have not done an end to end test.

This patch removes the currency setting (as we have it stored against the order already), the cancel URL (we should just send the user back one page), and the stylesheet that contained a single rule and wasn't being applied anyway.

I think we should also remove wps_no_shipping and wps_address_override, and always send the address entered at checkout but never allow the user to override it at PayPal - I don't see the point in any other combination.

This patch additionally removes the address options from the WPS plugin configuration.

Not entirely sure yet whether we should remove the no_shipping and address_override options so I have left them in for now.

This patch cleans up the IPN listener so it POSTs back to PayPal without erroring first, however the PayPal response is still INVALID and I am yet to figure out why.

Another patch to send the order currency automatically for WPP and EC.

This might be helpful https://developer.paypal.com/docs/classic/ipn/integration-guide/IPNSimul...

Resetting issue "Last modified" which was messed up by #2664380: Wrong comment date in automated commit comments

I'm not sure but I think I found problem why IPN verification not going throug.

Paypal's manual say: After receiving an IPN message from PayPal, you must respond to PayPal with a POST message that is an exact copy of the received message but with "cmd=_notify-validate" added to the end of the message

But what I understand programming that cmd=_notify-validate are added before IPN.

$response = \Drupal::httpClient()->request('POST', $host, [
        'form_params' => ['cmd' => '_notify-validate'] + $ipn,
      ]);

I fix that validation like this...

Better fix. There was only one small mistake for that original code

Well, the $data variable isn't defined anywhere, and the 'test_ipn' key isn't defined anywhere either. A proper fix will be to figure out what this test was supposed to do (@longwave? this was added as part of your commit d48c8bbf) and make it work properly. Apparently all your patch does is to force the use of the sandbox server all the time, because you're testing a variable which will always be empty.

The test_ipn key is defined in the PayPal documentation but I am not sure it is entirely reliable, or maybe I misread how it is supposed to work. I thought it would be the right way to identify whether to send IPNs back to the live or sandbox site without necessarily needing to refer back to the payment method config, but maybe we need a different method for this.

Then shouldn't it be $ipn['test_ipn'] instead of $data['test_ipn'] ? $data isn't defined anywhere ...

Ah, yeah, didn't spot that - could well be the issue! I will try that next time I get some free time to work on this.

PayPal sandbox is down but from reading the docs again I think this should work if I use the right variable name, so I committed this change. Express Checkout and WPP still need work.

PayPal Payments Standard lost the "Website" part from its name some time ago.

Back to active to finish off Express Checkout, unfortunately I can't work on this until the PayPal sandbox is back up.

PayPal sandbox is back up and delivered an IPN (12 hours late!) that was successfully processed and verified for PayPal Payments Standard, which is good news.

Work in progress for Express Checkout.

Express Checkout now works for both shortcut flow (cart > PayPal > review > complete) and mark flow (cart > checkout > review > PayPal > complete). We can improve things further later, but for now this is at least as good, if not better, than we had in D7.

This only leaves Website Payments Pro, which still needs conversion.

Cleaned up version of #66. I have PayPal WPP almost ready to go as well.

Committed.