My checkout process doesn't have a 'review details' step before progressing to the payment provider (Stripe). The only neat solution that I can think of requires me to create the payment intent/ stripe session at the same time as when my form is posted back to the server.
I've created a fork of the stripe payment provider that moves the session creation in to its own method call(CreateSession()). If I can call this, then I'd be able to put that session Id in my response. Unfortunately I've no idea how I would be able to instantiate/access a StripeCheckoutSettings or VendrContext object in order to create a StripeCheckoutPaymentProvider object and call CreateSession(). Is there any detail on this anywhere?
In order to keep your checkout, non stipe specific, I generally suggest that people keep the GenerateForm page, but instead of displaying the review summary, display a message like "Redirecting to Payment Gateway" (this is what we don on Vendr.net) and in the generate form, render some JS that auto submits it.
It's an extra screen, but I think it makes it clear to the customer what is happening, and it keeps your checkout flow in line with Vendr so if you did change your payment gateway, your implementation wouldn't be tied to Stripe.
I totally understand. The benefits to a consistent approach are significant, but it does create obstacles.
For my money, the best of both worlds would to sublement the GenerateForm with a object CreateIntent(...). An implementation agnostic method might be appreciated for those who are happy to be tightly coupled with a payment provider. SPA developers in particular I'm sure would prefer the option of getting a JSON response.
We do need to review the API as it has largely come from Tea Commerce and the web landscape has changed quite a lot, but the tricky thing is going to be creating an API that can work for many gateways and believe me, no two are alike and many have particular quirks that make this difficult.
Definitely open to suggestions though, but it's getting a view point that isn't tied to one particular payment gateway.
Avoiding GenerateForm
My checkout process doesn't have a 'review details' step before progressing to the payment provider (Stripe). The only neat solution that I can think of requires me to create the payment intent/ stripe session at the same time as when my form is posted back to the server.
I've created a fork of the stripe payment provider that moves the session creation in to its own method call(
CreateSession()). If I can call this, then I'd be able to put that session Id in my response. Unfortunately I've no idea how I would be able to instantiate/access aStripeCheckoutSettingsorVendrContextobject in order to create aStripeCheckoutPaymentProviderobject and callCreateSession(). Is there any detail on this anywhere?In order to keep your checkout, non stipe specific, I generally suggest that people keep the
GenerateFormpage, but instead of displaying the review summary, display a message like "Redirecting to Payment Gateway" (this is what we don on Vendr.net) and in the generate form, render some JS that auto submits it.It's an extra screen, but I think it makes it clear to the customer what is happening, and it keeps your checkout flow in line with Vendr so if you did change your payment gateway, your implementation wouldn't be tied to Stripe.
I totally understand. The benefits to a consistent approach are significant, but it does create obstacles.
For my money, the best of both worlds would to sublement the
GenerateFormwith aobject CreateIntent(...). An implementation agnostic method might be appreciated for those who are happy to be tightly coupled with a payment provider. SPA developers in particular I'm sure would prefer the option of getting a JSON response.I think I'll go with your suggestion for now.
We do need to review the API as it has largely come from Tea Commerce and the web landscape has changed quite a lot, but the tricky thing is going to be creating an API that can work for many gateways and believe me, no two are alike and many have particular quirks that make this difficult.
Definitely open to suggestions though, but it's getting a view point that isn't tied to one particular payment gateway.
Matt
is working on a reply...