Press Ctrl / CMD + C to copy this to your clipboard.
This post will be reported to the moderators as potential spam to be looked at
I'm currently implementing a Teacommerce site with the Stripe provider. I've found the Razor (here) but I'm unable to determine the URL that the form needs to AJAX post to (the api_url parameter). Can anybody help?
The api_url parameter should be auto filled in by the stripe provider https://github.com/TeaCommerce/Tea-Commerce-Payment-Providers/blob/master/Source/TeaCommerce.PaymentProviders.Stripe/BaseStripeProvider.cs#L70 This should point to the TC communication URL as it's how the front end communicates back to the payment provider to perform the backend steps that are required.
Ultimately you shouldn't have to provide that yourself
That would work, except with the Stripe provider, GenerateHtmlForm isn't called in the Razor file that's provided.
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.
Thanks Matt - so what you're saying is that the StripePaymentForm can't be on the same page as the "Place Order/Confirm/Pay Now" button?
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.target='_top';document.forms.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.
TC.GeneratePaymentForm (1, "<script>document.forms.target='_top';document.forms.submit();</script>")
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.
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
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.
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.
is working on a reply...
Write your reply to:
Image will be uploaded when post is submitted