[Roadmap] RFC: Future of Payum (payments) in Sylius

[pjedrzejewski]

Helloes. 😄

From time to time the topic of Payum and Sylius integration pops inside of Sylius organization and I'd like to pick the community's brain on this. To frame it a bit:

• Payum has been serving quite well as a payment processing library and I am eternally grateful to @makasim for his work and contribution, many years ago it helped push Sylius forward a lot!
• From my own experience and some feedback, the learning curve is relatively steep, once you get it you can be a minigun shooting payment plugins (wink wink @bitbager)
• Payum is fairly stable but not evolving much, while Sylius is evolving fast and pushing more towards headless implementations and handling payments is one of the open questions (see [Roadmap] Shop API with API Platform completed #12466)
• From what I see on the newest Sylius projects, including Sylius Plus customers, a lot simply bypass the whole Payum framework, especially that they do headless payments, so it's minimally useful

I see a couple of options that we discussed internally:

• Contribute money to the development of Payum if there is someone willing to work on it
• Take all the learning from using Payum and start evolving the payments framework inside of Sylius Core with some BC/migration layer so it's not a crazy effort to move projects, plugins, etc.
• Fork it into Sylius Core and evolve it there (the license allows for it)

There are pros and cons to all of these options, so I'd like to hear the community's voice before we make any decision on that. :) Thanks!

Open Questions:

• What's your experience with Payum in Sylius?
• Do you have some benchmarks on how to handle payments? Some approach that you love?
• If you bypassed Payum (some users do it) and integrated payments yourself, how did you do it?

[makasim]

@pierredup has recently taken up a maintainer position of Payum. He has already done good progress on moving Payum forward.

@pierredup wdyt?

[pierredup]

I'll share some info on the roadmap for Payum in the coming days on the Payum repository, but the development pace should start to pick up a bit in the following weeks.

@pjedrzejewski If there are any specific requirements for Sylius or something you would like to see in Payum, let me know and I'll look into it.

[gabiudrescu]

any updates?

[pierredup]

any updates?

From Payum's perspective, we are busy working on a V2 release, which will include a lot of internal changes to the library (adding more strict types, dropping support for PHP 7.x etc). You can follow some of the discussions and plans at Payum/Payum#928 and Payum/PayumBundle#539

Unfortunately, I don't have any definitive timelines on when V2 will be released, but it will be at least in a couple of months, since there are a lot of cleanup and changes that we want to add. I hope this can fit in with the Sylius roadmap, but I'm also open to any input or feedback from the Sylius team

[dbalabka]

@pjedrzejewski , recently, I tried to integrate a new gateway into an existing Sylius project using Payum. So, my experience should be valuable. There are a couple of observations of poor DX that would be great to resolve by evolving Payum or replacing it with any other solutions:

1. Lack of detailed documentation (see Documentation improvements  Payum/Payum#991). Need to read the code instead.
2. Payum's Actions, Requests, and Gateway approach is a bit cumbersome. So, the developer should spend time understanding new concepts that are different from those they are used to using Symfony's ecosystem. Also, the actions flow and how they integrate with Sylius is unclear. Sylius documentation also does not shed much light on how to integrate the gateway. The existing Sylius guidelines are far from real-world examples: https://docs.sylius.com/en/1.12/cookbook/payments/custom-payment-gateway.html
3. URLs with Tokens look logical and secure, but the multiple redirects that they require to perform do not fit nicely into a headless approach. I don't see how to integrate them well with SPA and REST API. For example, to capture payment, we need to redirect to the /capture/{token} URL to start the process, which, to my understanding, is redundant.
4. I really lack receipts for integrating a gateway that follows some standard patterns. Here is the list of possible scenarios:
   1. Acquire an auth token from the gateway API and redirect it to the gateway checkout to capture card details and then to the shop. (e.g., Paypal, Paysera).
   2. Render complete widgets or fields in iframes on the store checkout page. Do not need to redirect to any page. (e.g., Braintree).
   3. One-click payment like Apple, Google, and Paypal provide.
   4. PCA compliance stores can render forms on their behalf by sending card details directly to the payment gateway. This scenario is rare and, in my experience, usually requires complete custom integration w/o the need to use solutions like Payum.

To conclude, payment gateway companies usually provide plugins for more popular e-commerce frameworks like WooCommerce, PrestaShop, Magento, etc. In this sense, it would be great if Sylius could give the simplest way to integrate the payment solution, which would follow some standard patterns.

[Prometee]

@dbalabka hello !

Sylius core team is working on an approche called Payment request you can found more info in this PR #15502 and test it using this branch https://github.com/Sylius/Sylius/tree/payment-request

Creating the PR, I tried to allow Payum to work with this new approach but like you pointed out it's no so easy to do, however the current branch is allowing the old Payum PayPal gateway to work using API calls and normally other gateways can work without any changes in the gateway.

[dbalabka]

@Prometee , thanks for the update. I spend a small amount of time reading the code and discussions in the PR to understand it. Could you please shed some light on how these improvements change the current approach and improve the developers' experience to integrate new payment gateways and understand the existing integrations?

[pierredup]

Creating the PR, I tried to allow Payum to work with this new approach but like you pointed out it's no so easy to do

@Prometee I'm busy working on Payum V2 which will include significant changes to how the payment processing works. If there is anything I can add in Payum to help make it work with this new approach, let me know and I will gladly include it in the next version

URLs with Tokens look logical and secure, but the multiple redirects that they require to perform do not fit nicely into a headless approach. I don't see how to integrate them well with SPA and REST API.

@dbalabka It's definitely possible to integrate Payum with a SPA or using a REST API, as I have done it multiple times before. But I agree it's not very straightforward to implement. This is one of the things I would like to address and make it work better in V2

[Prometee]

@pierredup what I've done to support Payum using this new concept of PaymentRequest is to create those two actions :
https://github.com/Sylius/Sylius/tree/payment-request/src/Sylius/Bundle/CoreBundle/PaymentRequest/Payum/Action

• SyliusGetHttpRequestAction is allowing to get HTTP request using the API endpoint payload.
• SyliusRenderTemplateAction is merging:
  • Response data given by any Command Handler (Messenger) handling the current PaymentRequests.
  • Parameters given to the Payum request : Payum\Core\Request\RenderTemplate.

I identified those two input/output points in Payum where I can easily interact with, only if the action is run during an identified API context.

On an upper level, any Capture/Refund/Notify/etc Payum requests are run using this Processor : https://github.com/Sylius/Sylius/blob/payment-request/src/Sylius/Bundle/CoreBundle/PaymentRequest/Processor/Payum/RequestProcessor.php#L37.
It catch the reply to be able to get any HTTP response thrown during Payum gateway action execution.

[Prometee]

@dbalabka it will simply allows you to decide what your gateway is doing when a PaymentRequest is requested.
Previously you were kind of forced to use Payum, but with PaymentRequest you can use both w/o Payum.
What you need is to create your payment method in the administration, then create services like in this example:

services:

  app.sylius.payment_request.command_provider.my_gateway:
    class: Sylius\Bundle\CoreBundle\PaymentRequest\CommandProvider\ActionsCommandProvider
    public: true
    arguments:
      - !tagged_locator { tag: 'app.payment_request.command_provider.my_gateway', index_by: 'type' }
    tags:
      - name: 'sylius.payment_request.command_provider'
        gateway-factory: 'my_gateway'

  app.sylius.payment_request.command_provider.my_gateway.capture:
    class: App\PaymentRequest\CommandProvider\MyGateway\CapturePaymentRequestCommandProvider
    public: true
    tags:
      - name: 'app.payment_request.command_provider.my_gateway'
        type: 'capture'

  app.sylius.payment_request.command_provider.my_gateway.status:
    class: App\PaymentRequest\CommandProvider\MyGateway\StatusPaymentRequestCommandProvider
    public: true
    tags:
      - name: 'app.payment_request.command_provider.my_gateway'
        type: 'status'

The first service is a gateway actions provider to your 2 possible actions: capture and status depending on the PaymentRequest->action requested it will execute one of your App\PaymentRequest\CommandProvider\MyGateway\*PaymentRequestCommandProvider classes.

Doing this you will be in control of every thing needed for your gateway.

If you want to add an existing Paym gateway you can follow these examples :
https://github.com/Sylius/Sylius/tree/payment-request/src/Sylius/Bundle/CoreBundle/Resources/config/services/integrations/payum