That would work, except with the Stripe provider, GenerateHtmlForm isn't called in the Razor file that's provided.

Hey Benjamin,

It sounds like you might have things a little misconfigured.

First off, you need to create a payment page which contains that stripe form. Onces that is created, you need to configure the stripe provider entering the url for that page into the stripe providers form_url parameter (see https://docs.teacommerce.net/3.3.2/payment-providers/stripe/#configure-tea-commerce)

Then on the checkout step before payment (which is usally a confirmation page) you call TC.GeneratePaymentForm to create the Continue button (see https://docs.teacommerce.net/3.3.2/api/payment-forms/#tab-116). It's this that calls the GenerateHtmlForm method, creating those parameters. Then when you click the Continue button, they get posted through to the payment form and are all populated.

Let me know if that doesn't make any sense.

Matt

Not with how it currently works, but there is a way to kind of "fudge it", which I've done in the past. I'll warn you, it ain't pretty 😂

What I've done before is on the page just before payment, say the "choose payment method / shipping method" step, is have it so that the "Continue" button on that step submits to a hidden Iframe. In that iframe, you then render a blank page which calls something like this (off the top of my head, so probably wrong) TC.GeneratePaymentForm (1, "<script>document.forms[0].target='_top';document.forms[0].submit();</script>") Essentially you are trying to auto submit the generated form so that it sends the top window straight to the payment page, missing out the confirmation page.

As I say, it ain't ideal, but it's the only real option we have for missing out the confirmation step. Ultimately, you have to some how call TC.GeneratePaymentForm regardless.

Matt

Hi Ben,

That's great that you got it working.

RE the payment intent id, I'm not sure why you should need it as the provider should take care of everything for you, but if you do need it, it get's stored as a property on the order https://github.com/TeaCommerce/Tea-Commerce-Payment-Providers/blob/master/Source/TeaCommerce.PaymentProviders.Stripe/Stripe.cs#L180

Many thanks

Matt

I think I might know what you are trying to achieve. It sounds like (reading from your tweets) that you are trying to get straight to the order confirmation page and then on that page fetch the status of the payment intent to see if the order is complete to then fetch the order number?

The way the code in the example checkout is setup works a little different. Instead what we do is hold you in a loop on the payment page (I think this is what was causing you issues on twitter) which we do by looping and checking if there is no longer a current order. When that is the case, we know the order finalized via the webhook and so we can continue to the confirmation page and show the order number.

If you want another approach, we do have another implementation of the stripe payment provider which you can find on this branch https://github.com/TeaCommerce/Tea-Commerce-Payment-Providers/tree/wip/stripe-sync. With this version it uses a synchronous approach to finalizing an order so that the Stripe charge is taken in process and so we know that when that is done it can safely send you to the confirmation page. It basically does away with the webhooks.

I appreciate this is all a bit of a mess, but unfortunately this is the state of Stripe inline payments post SCA updates (https://stripe.com/docs/strong-customer-authentication). We implemented the webhooks approach as this is Stripe recommended approach but we are finding this is far from ideal when you need a finalized order to show confirmation, hence why we've also created the sync approach as an alternative.

Stripe are still going through changes as they've also made some vast improvements with their Checkout option which is now redirect based (which was an inline dialog before) which I think will be the approach we use in Vendr moving forward as it gets rid of ALL this inline complexity.

Anyways, I hope I've read your issue correctly and this helps in some way but I do apologies that this isn't simpler than it is. I'm keen to rectify this in the future.

Matt

Perfect - this is what's missing! When the webhook comes in, the order transaction ID isn't set, which then prevents being able to refund the customer from the dashboard.