#xlex - Payment Intents
opal otter
Hello! You can fetch the Payment Intent server side using the API and check its status and other properties: https://stripe.com/docs/api/payment_intents/retrieve
boreal swift
Thanks ๐ The API response from GET /intents/pi_abc includes an array of charges. Is there a way to be sure that the charge I see is the one I'm expecting?
opal otter
Which one are you expecting?
boreal swift
I don't expect there would ever be more than one, but I guess it feels a bit vague do just do charges.last and assume it's the charge from my frontend.
Is querying retrieve on the server side the standard way to verify a payment intent?
opal otter
A Payment Intent can have zero or more Charges, but only one successful one. Can you tell me more about which specific Charge you want to see and why you want to see it?
The list on the Payment Intent will only show the latest one, which might be failed or succeeded: https://stripe.com/docs/api/payment_intents/object#payment_intent_object-charges-data
boreal swift
I think that clarifies it -- that there can only be one successful charge.
That's helpful for sure.
Just strange that it's an array I think.
Thanks for the quick reply.
opal otter
Regarding your other question, yep, it's normal to fetch a Payment Intent on the server to check it's status in addition to listening for webhooks.
Webhooks are usually required for a robust integration though. Are you trying to avoid them entirely?
boreal swift
I always worry about the reliability of webhooks; having the server pull for data instead of waiting to receive the push feels more solid.
Why are they required for a more robust integration? Is it for ACH and slower payment sources? We're only looking for credit cards and Apple Pay
opal otter
It may feel more solid, but it's also quite dangerous. For example, how does your server know to fetch the Payment Intent? What triggers that code?
boreal swift
The same process that completes the order. In our existing integration we would
- tokenize card with JS
- pass tokenized card to the server
- server finalizes the order
With payment intents it was going to be the same roughly:
- create intent on the server
- verify intent clientside
- notify server that payment intent succeeded via JS
- server verifies for real that the payment succeeded and finalizes the order
opal otter
Are you and your customers only located in the US and/or Canada?
boreal swift
Our company is. Customers are not exclusively but mostly are.
opal otter
Do you have any plans to expand to any other countries?
boreal swift
What's the dangerous part -- does 3DS not work without webhooks?
opal otter
Imagine this scenario: someone on a train is paying on your website. They get prompted for authentication (3D Secure). Just as they successfully authenticate the train enters a tunnel and they lose their internet connection. The money moved and you got paid when authentication succeeded, but because your client-side code was never run you would never know about it without listening for a webhook.
Thus someone paid you and you didn't fulfill their order.
boreal swift
Goddamn trains are the worst
opal otter
That's just an example, of course. People can lose their connection for many other reasons; their battery dies, the network glitches, etc.
boreal swift
๐
opal otter
That's why webhooks are vital to async payments.
boreal swift
So the browser needs to poll the backend server to check if the webhook has been received -- is that the best flow?
opal otter
No. If your client side code runs normally that's great, you can kick off fulfillment on your server from there and have everything happen at once, but that shouldn't be the only way fulfillment is triggered.
Your server should listen for your client side code and webhooks, and whichever it gets first "wins" and triggers fulfillment. If it gets the webhook first and client side code happens second your server lets the client know about the current status. If client side triggers fulfillment and you get the webhook later you can ignore it since you already fulfilled the order.
boreal swift
Fair enough. Definitely much more complex than the old charges API.
opal otter
Yep, the complexity of the payment industry and payment processes increased, so what you have to build increased along with it (although we try to make it as easy as possible).