Saleor: Extract payment gateways to separate libraries

[maarcingebala]

With the release of Saleor 2.0 we managed to drop django-payments from Saleor and started to shift towards the new payment modules - saleor.payments. However, having them in Saleor repository is an intermediate solution. Our ultimate goal for handling payments is to have all providers abstracted to external libraries.

Currently, we have two gateways (Braintree, Razorpay) plus another one is being implemented (Stripe - #3408). I want to hold on with adding new ones after Stripe is merged and start extracting them to separate libraries. The plan would be as follows:

1. Implement saleor-braintree library and move there all the Braintree logic. We'll provide a new repository for it.
2. Adjust Saleor to use the library.
3. Once everything works, we'll publish the library to PyPI.

When saleor-braintree is ready, it will serve as a model gateway implementation for Saleor, that other packages should follow. Purpose of this issue is to start the discussion and initiate work on extracting Braintree. Any questions or concerns are welcomed.

[jxltom]

How about a library named saleor-payments? It is fine to have standalone repository for each payment, but these payments have so much in common, such as error message, public APIs, etc. Putting them into a same repo will make it easier to share common modules/functions/fixtures, no matter for the gateway itself or the tests. Probably it is also easier to maintain?

[maarcingebala]

One problem that we have to deal with is the multitude of payment gateways available on the market. We cannot guarantee that we'll be able to maintain all of them and merging them to Saleor (or to saleor-payments) would impose this burden on us. That's one of the problems we had with django-payments. As a result, some of the more "exotic" payments gateways were quickly getting outdated and we were not able to provide proper maintenance.

We concluded that maybe we should support only the major gateways and leave the responsibility for all the others that the community comes up with, for the people who really use them and know them better than we? That's the reasoning behind having separate libraries.

I agree that maintaining a single library would be a lot easier than multiple smaller ones. For example, I still have some concerns about the approach we're taking e.g.:

• What would be the best way to enforce the same interface of a payment gateway integration among separate libraries (better than just a convention)?
• How do we handle payment models which currently live in Saleor, but are also used by payment providers? Should we leave them in Saleor and abstract gateways in a manner that they only operate on raw data, not models?

Things we discuss here are still open and I value such input as you gave @jxltom. @michaljelonek is going to experiment with extracting Braintree logic and we'll see what problems we encounter.

[Pacu2]

I think we should also consider versioning between saleor and the gateways, as payments implementation might evolve at some point.

[bykof]

The best approach would be to create a really good interface for the saleor payment models.
So everyone who is interested in adapting his custom payment provider could write either the payment gateway in his own application or in a standalone saleor-payment-xyz library.

So the saleor-payment-xyz library will retrieve user or system calls (through a proper interface) and also it has to use the payment model to alter and create payments for an order.

I think that the documentation of this is really necessary. It could be something like a tutorial how you build your own payment gateway, what kind classes your library should create (maybe there are abstractclasses in saylor of which you can inherit to guarantee methods and proper constants).

[bykof]

How about a library named saleor-payments? It is fine to have standalone repository for each payment, but these payments have so much in common, such as error message, public APIs, etc. Putting them into a same repo will make it easier to share common modules/functions/fixtures, no matter for the gateway itself or the tests. Probably it is also easier to maintain?

I would rather put abstractclasses in saylor and the different payment gateways in external packages, so you can switch them how you want. To manage all payment gateways in one library would, as @maarcingebala said, be hard to maintain.

[kimnam-server]

I want to use saleor in Japan
  Braintree has not yet supported Japanese corporations.

Is there any way to use the existing payment method in the version of saleor2.0 as shown below?

I want to be able to pay for paypal

PAYMENT_VARIANTS = {
     'paypal': ('payments.paypal.PaypalProvider', {
         'client_id': 'xxx',
         'secret': 'xxxx',
         'endpoint': 'https://api.paypal.com',
         'capture': False}),

[Pacu2]

@kimnam-server Unfortunately that's not possible, as architecture totally changed between django-payments and our custom solution.

I think that PayPal provides js-based checkout (in form of a script, as Braintree does), so it should be relatively easy & fast to implement.

We have a guide for that if you want to handle it
https://docs.getsaleor.com/en/latest/guides/payments.html

[kimnam-server]

@Pacu2
thank you for your reply. I will refer to the information you provided.

[Pacu2]

@kimnam-server if you need any guidance or support during the implementation do not hesitate to let us know, either here or on our gitter https://gitter.im/mirumee/saleor

[jdivins]

We want to integrate this payment gateway: https://desarrolladores.addonpayments.com/#!/
Is this documentation "https://docs.getsaleor.com/en/latest/guides/payments.html#adding-payments" obsolete then?

[maarcingebala]

After merging PR #3519, we need to add few more improvemements to the payment implementation. I'll add issues for that marked with label payments. For now I'll remove this ticket from current sprint.

[krzysztofwolski]

One note from me - could we stop using dicts for passing info between payment handling functions? IMO mutable structure could lead to programmer errors:

• when using dict, you have o guarantee which fields are created
• when using dict, you lose all editor support etc
• you cannot type dict, no static code analyze for you

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[jdmueller]

I was still hoping that this would get done so that we can use PayPal and Authorize.net independently from BrainTree.

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[WhyNotHugo]

What's the intention for django-payments here? Is the intent for the new in-tree saleor implementation to be reusable? Will django-payments slowly die offf?

I currently have a MercadoPago (latinamerica) payment implementation that I use with several clients, but want to expand to other payment solutions. My intention is to add mercadopago to django-payments, and then switch to that.

Would you recommend I target saleor.payments instead?

[maarcingebala]

django-payments is suitable when you have classic Django views with forms and templates which is not the use-case with current GraphQL API in Saleor. That's why we don't use it anymore. Currently, all new payment gateways are being added as saleor.payments modules.

If you're maintaining a payment plugin, you can also create it in a separate repository and install it in Saleor, but this is only available in the newest version 2.11.0-rc.1 version. See this documentation page for more information: https://docs.saleor.io/docs/next/developer/extending/plugins/#loading-your-plugin