-
-
Notifications
You must be signed in to change notification settings - Fork 282
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Django Rest Framework integration #257
Comments
It can be, but what are you trying to do? |
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). |
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 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. |
I thought like form we can return serializer. @WhyNotHugo |
That would make sense. Each payment provider [that requires a form] implements its own 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 Note that also some providers (e.g.: MercadoPago, Sofort) don't return a form, but return a |
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. |
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 can start with testing only a few Django & Python versions with DRF, and leave most of CI the matrix without. |
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. |
Hello, I have been wondering, can this library be integrated in a DRF backend?
if yes, how?
The text was updated successfully, but these errors were encountered: