#cnguyen85
1 messages · Page 1 of 1 (latest)
Hi there!
The most common fow is to first create the PaymentIntent or SetupIntent, and then use the client secret to display the Payment Element yes.
But we recently released a "deferred flow", where you don't need to create the PaymentIntent/SetupIntent upfront. You can learn about this here: https://stripe.com/docs/payments/accept-a-payment-deferred
OK I see. And I want to validate my flow. I'm the platform account. And there is Standard Connecte Account client.
Explanation :
- On the platform account, I need to keep the customer and the card (off_session) to generate a subscription that is stored in the platform account
- On the connect account, I need to process the purchase (like a direct charges - could be on_session), have the customer and card information too. And it's possible to generate a subscription too (off_session)
So, the customer is on the website of the merchant (standard connect account).
I think that :
- The merchant has to use our pk_live (I will generate a specific one for him)
- So I will handle his purchase/order payment with a direct charges
So you want the payment details stored on both the platform and the connected account (to do direct charges)?
payment details = card or pi ?
For me, on the platform account, I just need to have the customer and the card. Not the PI. PI is for the merchant (connect account)
The way to do this:
- Store all the info on the paltform (Customer and PaymentMethod)
- When you want to charge the customer on the connected account, clone the PaymentMethod on the connected account, and then create a Direct Charge
This doc explains how to clone the PaymentMethod: https://stripe.com/docs/payments/payment-methods/connect#cloning-payment-methods
And the flow will be :
1 - Front => Display the card element (but need a client_secret => we can handle without it with the "deferred flow" => https://stripe.com/docs/payments/accept-a-payment-deferred)
2 - Back => Create the customer and generate the setup_intent (to have the card in "off session")
3 - Front => Do a stripe.confirmCardSetup (with client_secret, card_element) (we can have a 3DS)
4 - Back => On "si.succeeded" webhook, I clone the customer and payment_method from the platform to the connect account => https://stripe.com/docs/payments/payment-methods/connect#cloning-payment-methods)
5 - Front => On si.confirmCardSetup sync validation => call the back to create the PI (direct charges) and send the pm_id to use it to generate the PI
6 - Back => Create the pi and generate the client_client (with the PM generated by SI?)
7 - Front => pi.confirmPayment (to validate the PI with 3DS)
8 - Front => on sync validation of confirmPayment, I can now redirect the customer to the confirmation page
So you want to do a SetupIntent on the paltform, and then right after a PaymentIntent on the connected account?
That should work, but there's a downside: the customer might need to perform two 3DS: one for the SetupIntent and one for the PaymentIntent.
Yes but how can I have the PM in off_session on the 2 sides (platform and connected account) ?
Because if I do directly a PI in direct charges, the pi and the pm will be only on the connected account, no ?
Because if I do directly a PI in direct charges, the pi and the pm will be only on the connected account, no ?
That's correct.
There's no perfect solution for this use case. Thinking about this...
And about my flow, is it a good one ?
When I confirm the confirmCardSetup with 3DS, I can use the PM to create the PI and I will have chance to avoid the 2nd 3DS ? Or I use the same cardElement twice (once for SI and once for PI) ?
And maybe I have to switch the 1 and 2 to generate the clien secret first ? And to generate it, I need to have the customer information ?
And maybe I have to switch the 1 and 2 to generate the clien secret first ? And to generate it, I need to have the customer information ?
As I told you at the very beginning:
The most common fow is to first create the PaymentIntent or SetupIntent, and then use the client secret to display the Payment Element yes.
But we recently released a "deferred flow", where you don't need to create the PaymentIntent/SetupIntent upfront. You can learn about this here: https://stripe.com/docs/payments/accept-a-payment-deferred
So 1 then 2 is the new "deferred flow" which is possible. 2 then 1 is also possible.
And :
"When I confirm the confirmCardSetup with 3DS, I can use the PM to create the PI and I will have chance to avoid the 2nd 3DS ? Or I use the same cardElement twice (once for SI and once for PI) ?"
It's two different things:
- When you confirm the SetupIntent on the frontend, it may trigger a 3DS flow. Then you get a PaymentMethod.
- You then clone the PaymentMethod
- And create a Direct Charge with the cloned PaymentMethod. When you confirm the PaymentIntent it may work directly or may require 3DS.
Mmm but it means that the direct charge will be offline ?
No necessarely, that's up to you. If the customer is still on session, then:
- You create the PaymentIntent on your backend
- Then confirm the PaymentIntent on the frontend
If he is still on session, it will be safer to handle the "main" payment online. So to do the pi
Yes agreed, this way if 3DS is required, the customer will be already there to handle it.
And when I do the stripe.confirmCardSetup => It's on the synchronous validation that I have the pm_id ?
Because, the cloning could only be done on back session. So it's only with the si.suceeded for example. So it's an async way. I an wait the cloning to handle the PI.
I want that the customer enters the card info once and handle the 2 stuffs (SI + PI)
Because, the cloning could only be done on back session. So it's only with the si.suceeded for example. So it's an async way. I an wait the cloning to handle the PI.
Yes that's correct. But it should be pretty quick.
And when I do the stripe.confirmCardSetup => Do I have the pm_id in the synchronous validation ?
Yes the frontend response will contain the PaymentMethod ID
Or maybe the best option is to create a WS to do the cloning ? And to call it just after the si.confirm. Like that I'm sure to create and launch the pi with the cloned customer / pm ?
It will give :
- Create customer + SI
- On si.success => call WS to clone customer and pm
- On WS success => Create the PI with the cloning infos
- On PI.success => redirect to thank you
Is it better ?
What's a 'WS'?
web service
I don't know what that means. A webhook?
for example POST api.test.com
like a REST API
But if you don't know what is it... You can't help me I think ^^
Never heard to it referred that way. But yes you'll need a server/backend to clone a customer
lol. Is it possible to continue with soma ? Or to have an other guy please ?
Nope, I can help. I'm not sure what was confusing about my answer
You asked if you need a 'web service' to clone a customer
Have you read all the conversation ?
Which you do, because you need to call the API that clones the customer with your secret keys
Yep, you're a platofrm attempting to clone PMs to conncted accounts and charge them
Really? I think they're pretty clear
not at all ^^
you didn't understand
and you don't answszer to the question
but anyway
it's ok
i will check myself
I had few interesting information from soma
thank you for your help
Can you try and re-phrase the question?