#peter_braganza - payment intents
1 messages ยท Page 1 of 1 (latest)
Ok
Background: We create the payment method first, pass it to the backend, create the payment_intent and try and confirm it. Then pass the response to the front end. If it requires action, we handle this on the front end
Reason we do this, is because we sometime mix subscription setups with one of payments
And also sometimes we have more than 1 stripe account (we use stripe connect with direct charges), so we create the payment method on our platform in this case so we cna charge on the 2 accounts
Hi there ๐
Yes you could use idempotent requests here to repeat the same request(s) to reduce the risk of duplicate charges. This functionality is built into our API, and you can read more about it here:
https://stripe.com/docs/api/idempotent_requests
You can also put a note on the page to your customers telling them not to refresh the page, I see this approach pretty often in the wild.
If we make a request with an idempotent key and the card is declined, and they enter a new card and we send a request with the same idempotent key, would that be ok?
no you would get an error in that case since you are re-using the idempotent key with different parametets
Right, so it must be the same parameters
So really this wont help our cause?
If they refresh the page
I think the most robust option is to use webhooks
and create PI when the page loads
With PaymentIntent you don't really need idempotency keys since the PaymentIntent can only be successfully confirmed once, unless you create separate PaymentIntents which you shouldn't for a given customer
Ok, so low hanging fruit is just "dont refresh page"
Question is, why at peaks times do we have this issue
Is it a stripe things
Do you throttle requests
depends what you call "peak time" and "throttle"
We sell tickets to events, and sometimes have lots of people trying to buy them from the same stripe account at once
We have rate limits: https://stripe.com/docs/rate-limits
But you, as the developer, should be handling this already in your own code. It's also quite rare for a business to reach those limits
I think its more likely our server
We wait for the payment intent response to come back (from our backend) before we stop the spinning wheel on the payment screen
So when they click pay, we send a request to our backend, then create the payment_intent, confirm it and pass the response to the front end
Its the response coming back which hangs
Although it is successfull on stripe
yeah that's hard to say. You should consider creating the PaymentIntent earlier in your flow instead of when they click Pay
Yes, buts its because of what I said:
Background: We create the payment method first, pass it to the backend, create the payment_intent and try and confirm it. Then pass the response to the front end. If it requires action, we handle this on the front end
Reason we do this, is because we sometime mix subscription setups with one of payments
And also sometimes we have more than 1 stripe account (we use stripe connect with direct charges), so we create the payment method on our platform in this case so we cna charge on the 2 accounts
gotcha
How would you advise?
I did have a good conversation with karlecho, is there ahyway I can find that conversation is Discord?
I don't really have a good recommendation if you have such a complex set up
you can search
Can a customer be created without a payment method?
Just thinking we could do this
1/ Create customer
brb!
๐
back
Ok, so
1/ Create customer
2/ Create subscription
3/ Add any additional payments to the subscription or create an invoice before creating a subscription
4/ Get the latest invoice and thus payment_intent client secret
5/ Send it to front end and confirm
my colleague @wet tide is going to take over and they can help if you have a follow up question
๐ catching up here @safe thorn! Give me one moment.
The flow you outlined mostly seems fine. Are you running into a specific issue with it? I don't really understand step 3 in terms of context of "additional payments" but otherwise looks good.
We have the case where people setup a subscription and pay one off charges at the same time
We currently do this is 2 steps, by creating a payment method, then a customer, then charging, the setting up a subscription
When we are trying to change the flow to create a p_i when the page is loaded
Hey sorry @safe thorn, missed this follow up.
What collection_method are you using for your Subs?
card
Collection_method is send_invoice or charge_automatically.
This will determine whether we finalize the initial invoice for a Subscription immediately or not.
If you use send_invoice, there is a 1 hour delay for finalization where you could add invoice items to the initial invoice if you so desired.