PayPal 6.0.0 beta - the final push for victory

  • One of the modules we have always been discontent with is PayPal. It is one of the first modules we have forked back in January. To be honest, we never expected that it would need this many changes. We started with version 3.11; now we already are at 6. It is actually the third big push, hopefully one that finally allows us to accept payments with PayPal as it should be.

    The previous big changes were about fixing Express Checkout, the login, connecting with the newer API, avoiding all the API endpoints that have been deprecated this year and the rounding issues. In order to minimize fraud and disputes you should send as much information to PayPal as possible, but this becomes hard with all the rounding options and tax systems out there. Luckily, PayPal provides a couple of new fields which the PayPal module utilizes since version 5, to handle all these extra numbers and still calculate the right order subtotal.

    One of the many reasons we needed another big change in the module is that in practice there are many ways possible to pay with PayPal, of which many cases have never been covered by the module. What if the customer changes the address during the checkout? What if the user has a guest account with a previous address, but suddenly decides to use PayPal Express Checkout again with a different address? What if the German visitor chooses the “Kauf auf Rechnung” option with PayPal plus? What if PayPal suddenly decides to do a fraud check and halts the transaction for a moment? These are all situations I found in production that could previously never be handled properly by the module and even caused customers to pay less (or more!) than needed 😞
    Therefore @lesley and I have discussed and discussed about what the new module should look like. How it should handle all of these situations. One solution we came up with was asynchronous payments. This new version, by default, uses 2-step transactions (authorization => capture [in practice 4 steps]). In order to achieve this we had to migrate every single part of the module to the new REST API that PayPal nowadays provides, including webhooks instead of IPNs. Altogether this makes sure that, whatever happens, the module can handle these exceptional cases thanks to the payment notifications PayPal sends with every status update. As a result, PayPal itself can now do a fraud check, halt the transaction that causes the customer to see a “Pending payment” status for a brief moment, but 5 minutes later show the “Payment accepted” status, because the module was able to handle this (asynchronously) delayed transaction. Or it can charge those extra €5 needed to ship the order to the address that was suddenly changed during the PayPal Express checkout (all with a final confirmation page, of course!)

    All in all, with this new version I run on production myself, I have seen transactions that would previously fail now get handled perfectly fine. Let’s see if the total number of successful transactions becomes a perfect 100% as well. If you would like to test this new version with me, you can now find the new beta version of the module on GitHub:

    Thanks in advance and hope to hear your results soon!

  • Great work! I’ll install it and contribute to the testing.

  • Nice job guys, I’ll give er a try as well.

  • Express Checkout isn’t coming up for me… Login works fine, so far normal checkout looks good…

  • Express checkout seems to work if you are not logged in, if you are, it doesnt show up

  • I’m going back to the offical version. I have a pending in Paypal, yet the site doesn’t show the order at all.

  • @slick_303 said in PayPal 6.0.0-beta.1 - the final push for victory:

    Express checkout seems to work if you are not logged in, if you are, it doesnt show up

    That’s fine. Ever since PayPal removed shipping options from the checkout it is supposed to do that. Even the official is supposed to do that.

  • @slick_303 said in PayPal 6.0.0-beta.1 - the final push for victory:

    I’m going back to the offical version. I have a pending in Paypal, yet the site doesn’t show the order at all.

    Perks of using async transactions. If it is voided then it’s okay. If it is captured then it is not. What is the full status?

  • Just says pending is Paypal…

  • Wait, don’t ship yet

    You’re fine

  • It still should have made an order in TB saying awaiting paypal payment…

  • No, it should not always do that.

  • when will it make it then? when it completes?

  • The only time it shouldnt make one is when it doesnt go through at all

  • It should also not make one when there is no user consent. The new version always shows a confirmation page. If the user decides not to pay and just leave it will not capture the amount.

  • right…thats what i meant 🙂

  • But I get your point. Maybe we can set it to pending and show that the user needs to give consent first. Also send an email to the customer that the order is pending.

  • right. and pending doesn’t always equate to user giving consent, sometimes paypal just audits some people…i think…

  • They do audits indeed, but in that case the module accepts it. If you pay via the sandbox for example, PayPal emulates an audit check and will release the funds after a few minutes delay.

  • I had a situation where Paypal module check the address it was on Presta and sent error valid address.
    Even when customer confirm me that address was correct.
    More painful it was when someone sell digital products and Paypal send error during order.

    I would like to highlight this thing. You can change to do not check address in code, but what about such option in Paypal?

    Regards sandbox testing I have noticed that it was not perfect. Different result compare to real payments, so that’s why I make a test with real cards and payment methods.


Looks like your connection to thirty bees forum was lost, please wait while we try to reconnect.