Django Rest Framework integration

[Simouche]

Hello, I have been wondering, can this library be integrated in a DRF backend?
if yes, how?

[WhyNotHugo]

It can be, but what are you trying to do?

[Simouche]

i'm trying to make an application using angular and DRF, which is a simple ecommerce application, i just want to keep everything happening on my application (no redirects to external pages).
but i didn't find a proper guide/doc on how to do that using this library with DRF.

[WhyNotHugo]

First off, let's discuss about what's technically possible:

Keep in mind that this is not possible to implement such a flow for some providers due to the way they're designed. For example, payment providers where the user has to authenticate with their bank will always require that you redirect them to an external page. The same is true for "wallet"-type payment providers. I'm assuming you don't intend on using any such provider.

For other providers, it should be possible to implement this (for example credit-card based ones, where the card-number is something you can request). Keep in mind that handling payment data yourself has complicated compliance requirements, since it's technically a "secret" (though the user keeps sharing it on each purchase).

---

Secondly, let's get into what this package can do right now:

The API in this package will return a Form object which you need to render on the frontend, and there's no native DRF support in the way you're describing. This Form object is a good indicator of which fields you need to request from your users.

I'm open to suggestions on how to implement support for DRF, but I can't think of a very obvious way to do so.

[oguzhancelikarslan]

I thought like form we can return serializer. @WhyNotHugo

[WhyNotHugo]

That would make sense. Each payment provider [that requires a form] implements its own get_form method. The get_serialiser method would need to be implemented for all providers.

Honestly, I think that might be the best approach. I suspect that, initially, most providers won't support DRF until someone adds support for each one.

That said, I guess I could programatically generate a table for the documentation, showing which providers implement get_form and which ones implement get_serialiser.

Note that also some providers (e.g.: MercadoPago, Sofort) don't return a form, but return a RedirectNeeded. The get_form (or get_serialiser) is only required for providers where we need to ask the user for additional information ourselves.

[auvipy]

technically the support for DRF is possible programmatically, we can call them web hooks or reverse API. so in theory possible. you can check the models and views and forms and try to make a serializer & APIviews for them and see wha issues you are facing.

[browniebroke]

I'm myself interested in this feature/guide.

I started looking at how to bring optional support for DRF into the library, but I stumbled upon a decision about the testing strategy on CI: the more versions we add, the higher number of CI jobs.

• I assume we need to run tests with and without DRF installed, right?
• Do we want to test against multiple versions of DRF?

I can start with testing only a few Django & Python versions with DRF, and leave most of CI the matrix without.

[WhyNotHugo]

I'm happy to trim down the CI matrix, it's larger than it needs to be.

Older versions of Python can be tested only with their oldest compatible version of Django. We should only test multiple versions of Django with the latest Python.

For DRF, we can include just the latest Django and Python to start with.