Best practice payment flow with edge cases per provider

[havard024]

Hi,

I recently started using this project and I was wondering if you have any thoughts on adding examples on best practice / full payment flow with edge cases for eg an ecommerce site? eg is it out of scope of this project or something you would accept contributions to eg update documentation and / or add examples per provider.

I belive this issue #328 was looking for something similar.

For example, when implementing a payment flow with stripe using PaymentIntents (I believe this is using the changes API), they recommend to reuse a payment intent instead of creating a new if the user never completed a checkout.

The reuse of payment intent also applies if a user adds / removes products, there stripe recommends to update the existing payment intent if one has been created.

When using the stripe checkout flow I don't think this is needed, you would just create a new checkout session. Though they do have functionality to expire a session https://stripe.com/docs/api/checkout/sessions/expire

The use of the the above cases is to prevent duplicate payments.

Stripe has some more documentation on idempotent requests to prevent duplicate requests which could result in duplicate payment intents / checkout sessions: https://stripe.com/docs/api/idempotent_requests

I understand that each provider might have their own mechanisms to handle, but it's not something that changes over time, thus each provider could document a best practice payment flow or some example flows for specific use cases.

Looking forwards to hear your thoughts on this 💡

[mariofix]

Hi @havard024 Thanks for your question, we're in the process of updating the provider for Stripe (payments.stripe.StripeProviderV3),
One of the main change is the use of Checkout Sessions, it handles by default the Creation using the API, and Payment Confirmation, Expiration, and Refund of each payment using Webhooks.

By using Checkout Sessions in my projects I got rid of the problem you're describing, but I'll make some more tests to see if the idempotency key is needed regardless.

[havard024]

Hi @mariofix thanks for the quick response.

From my experience, the idempotency key helps for cases where client application are able to send two requests to server to create a session. eg a user clicks on a button twice, it can be fixed by disabled the button client side.

I've tried the StripeProviderV3 already and it works like a charm, I believe creating a session for each payment / checkout solves the majority of cases. Looking forward to see finished product!

[mariofix]

Hey @havard024 they are enabled by default 😃 Automatic Retries

[havard024]

Hey @havard024 they are enabled by default 😃 Automatic Retries

Well that makes the job at lot easier 😄 Thanks for looking into it!