SkubaSteveHD-payment-element

[mint ferry]

👋 Happy to help

With Payment Element, it'll support all the available payment methods and some of them require redirection to the payment method page to complete the payment.

I'd recommend adding the query parameter to the return_url to indicate the session ID or order ID, so that you can retrieve the order information back once redirecting to your return_url

[north panther]

Is there a way to process the payment from a Payment Element on the API rather than within the app?

[mint ferry]

Payment Element is the frontend to collect payment method details. It's impossible to do collect payment method without a frontend.

[north panther]

Ok. 2 seconds I'll see if I can explain my situation better

This is our checkout page, I have embedded the Stripe Payment Element within it, I created the Payment Intent on our API.

When I click the Pay button, currently I run this function

What I would like to do, is instead of using this functionality; I would like to get all the payment information from the Payment Element, pass it back to my API, and handle the confirm payment there, or is this not possible with Payment Elements?

[fossil narwhal]

Hi SkubaSteveDH, I asked the exact question you are not long ago. My webapp was designed to work synchronously where a user enters their cc info, hits a button, the payment gateway tells the backend life is good, and they are brought to the next page.

To use Stripe properly, instead of waiting on a payment gateway to tell me the transaction was completed before saving all of the order info in my app, I saved all of the order info in my app using the Stripe PaymentIntent as a key, and then invoked Stripe.

Once Stripe redirected my customer/visitor to the payment completed page, I use the PaymentIntent it sent to look up the order, call out to Stripe to verify that the PaymentIntent is really paid successfully, and then mark the order as paid/fulfilled, and process it.

I hope this helps.

[mint ferry]

Thanks @fossil narwhal for sharing the information. Gizmo's approach is what we recommended.

Although you can set redirect='if_required' that only redirect when it's necessary, some cards will require customer to complete 3DS authentication in the bank page. Customer will still be redirected out of your website to complete the authentication and redirecting back to return_url set.

The recommended approach is like what Gizmo said. You should save order information and give it an ID before confirming PaymentIntent, then retrieve the information after redirecting back to your return_url

[north panther]

Guys, thanks a million for your help. I really appreciate it. I've been trying to work this out for 2 days now, I had this process that Gizmo explained designed out, just wasn't sure if it was the nicest and most elegant way of doing it.

[fossil narwhal]

You're welcome. Since you'll be saving "draft orders" before customers actually pay for them, you can add some kind of a cron to delete draft orders that were never actually purchased after some time if you want. I've been meaning to do the same, but haven't yet.

If you're selling something retail, though, you can always use your draft orders to send those "hey you still have x, y, and z languishing in your shopping cart" emails. 😛

[north panther]

Yeah, I'm going to set an expiry timestamp on the order, if they attempt to checkout after that then I can handle it, if not then I can run a cron job at midnight to remove all expired entities

[north panther]

Now your using your head 😂

[fossil narwhal]

I wasn't excited about the prospect of having to redo my purchase flow to something that felt ... less than natural as compared to getting a synchronous payment confirmation, so think of it as lemonade out of lemons. 😉

[random topaz]

Hey, taking over here. Let me know if there's any follow-up Qs I can answer!