Payments integration

[PetrDlouhy]

I am trying to integrate django-plans with some payment system (preferably PayPal for my project). I think, that this is not very well documented, and I think, that there could be much bigger part of the code shared between applications.
That is why I started django-plans-payments, which is my attempt for connecting django-plans with django-payments application.

At this moment it is far from being complete, or even usable in any sensible way.

Anyway, I would like to discuss here some details about future of this project and it's integration with payment backends. I am totally open to integrating my code (when complete) with django-plans. I think it would be nice, if it could support more payment backends (like django-getpaid) in the simplest way possible (ideally only by configuration).

What do you think? Do you payment-specific in your projects, that I could use in django-plans-payments?

[cypreess]

Had you seen my other project? https://github.com/cypreess/django-getpaid

It is exactly solving this problem and integrates automatically with django-plans.

[PetrDlouhy]

@cypress I mentioned that project in my description.
For me, it has several problems:

• It doesn't support PayPal.
• I had problems with Django 2.0

Also, I didn't find any info about the automatic integration in documentation. I expected similar amount of work for both django-payments and django-plans. Is there any info about the automatic integration?

[cypreess]

Currently django-getpaid is undergoing major refactoring thanks to Sunscrapers company that will lead the future development of this tool. You might want to contact @dekoza that is leading this effort.

No PayPal backend for getpaid is an obvious lack, however, there was no effort by anyone to write and commit such backend. We are always happy to see pull requests.

Problems with modern django handling should be over now as @dekoza had updated the code base majorly.

Some integration between plans->getpaid is here https://github.com/cypreess/django-plans/blob/master/plans/listeners.py#L68 . Yes, it is sadly not documented.

The payment process is initiated anyway by your app in a custom way, so there is no further need for integration that I could see at that stage.

[dekoza]

Current master of django-getpaid should have no problems with Django 2.0 (it is tested against it). Please give me some time to finish updating old codebase (you can help too!). I can pretty much release it now as the core is updated but I'm trying hard to get the payment plugins to work as a lot of them refer to APIs that don't exist anymore.

[PetrDlouhy]

@cypreess The plans->getpaid integration you are refering to seems to me to be far from being automatic, but maybe I didn't get it right.

In django-payments-plans I am trying to get to state where only configuration of settings.py and urls.py would be needed for the integration to run seamlessly including the payment buttons on the order page. I think, similar approach could be used for django-getpaid.

[PetrDlouhy]

I decided, that I will stick with django-payments. I hope, that some parts of my project could inspire also integration of getpaid. For example, here is the code, which seamlessly injects payment buttons to the existing order_detail.html template:
https://github.com/PetrDlouhy/django-plans-payments/blob/master/plans_payments/templates/plans/order_detail.html
https://github.com/PetrDlouhy/django-plans-payments/blob/master/plans_payments/templatetags/payment_buttons.py

I would also like to help with documenting both payment integration methods in django-plans documentation.
But I am still confused, how the django-getpaid should be integrated.
From what I have seen, I guess, that it would need some code very similar to django-plans-payments. If that is the case, we probably should share the code or integrate it into django-plans.

[dekoza]

@PetrDlouhy you can have a look at django-getpaid's PR 130 to see how the upcoming version 2.0 will look like. I'll take django-plans integration into consideration and update the PR accordingly before final merge.

[nemesifier]

I successfully integrated https://github.com/mirumee/django-payments, it's quite easy to do so and I recommend doing that.

[PetrDlouhy]

@nemesisdesign I have started the django-plans-payments project, so the integration would be even easier.

[PetrDlouhy]

Hi all,

I spent some time experimenting with the django-plans-payments and currently I also implemented the django-plans-paypal (connector to the django-paypal).
Now I think, that django-plans needs some kind of common API for different payment providers.

My idea is, that we will to implement payment provider chooser inside the django-plans. I have done something similar in the django-plans-payments, but I think, that the implementation would be much easier and better inside the django-plans. I would like to have common configuration for all payment provider connectors in some form like this:

PLANS_PAYMENT_PROVIDERS = [
    (
        'identifier',
        'Display name',
        'path.to.the.ConnectorClass',
        class_init_kwargs_dict,
    ),
    (
        'default',
        'Dummy payment',
        'plans_payments.dummy.DummyProvider',
    )
    (
        'paypal-card-sandbox',
        'PayPal sandbox payment',
        'plans_payments.paypal.PaypalCardProvider',
        {
            'client_id': os.environ.get('PAYPAL_SANDBOX_CLIENT_ID'),
            'secret': os.environ.get('PAYPAL_SANDBOX_SECRET'),
            'endpoint': 'https://api.sandbox.paypal.com',
            'capture': True,
         }
    ),
    ...
}

Then we can easily make payment type chooser in django-plans and redirect the view to success_url given from by the connector class. All further processing would be done inside the connector code. It is responsible for calling order.complete_order() and redirect back to django-plans success url.

Different payment providers have different workflow, so we will probably need to implement some support for delayed payment confirmation. The user shouldn't get confusing messages if the payment was succesfull, but is not confirmed yet.

--

@cypreess @Alir3z4 @nemesisdesign What do you think about this all? Do you have any further thoughts about this implementation?
@dekoza What is the current state of the django-getpaid? Do you think, that you could make the corresponding changes, if I implement this to the django-plans.

[nemesifier]

Personally I'd rather implement what you are describing on my own, ensuring that django-plans provide the right abstractions to do it fast and avoid having to rewrite common logic.

I'm not using the HTML templates, I'm using the django-plans core code via some REST APIs.

[Alir3z4]

I'm very late to this discussion but I think what django-getpaid is doing should be on the correct path as long as the core responsibility is kept in the main library and then backend being implemented separately in different repo.

Good job on that that didn't go to the path of having all the backend in 1 repo,

Regarding supporting into django-plans, I think django-plans would be better to stay DRY and focused on handling plans and nothing about payment, but provided with utilities to get connected to Payments as well so a bridge between django-plans and django-getpaid becomes in matter of some small code changes or some functions being written.

If we get to a point to have django-getpaid and django-plans work with not much of a headache, it would be really easy to plug it into any project and have fun with it.