#cnguyen85

1 messages · Page 1 of 1 (latest)

surreal fogBOT
charred wadi
#

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

fast nova
#

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
charred wadi
#

So you want the payment details stored on both the platform and the connected account (to do direct charges)?

fast nova
#

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)

charred wadi
#

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
fast nova
#

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

charred wadi
#

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.

fast nova
#

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 ?

charred wadi
#

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...

fast nova
#

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 ?

charred wadi
#

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.

fast nova
#

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) ?"

charred wadi
#

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.
fast nova
#

Mmm but it means that the direct charge will be offline ?

charred wadi
#

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
fast nova
#

If he is still on session, it will be safer to handle the "main" payment online. So to do the pi

charred wadi
#

Yes agreed, this way if 3DS is required, the customer will be already there to handle it.

fast nova
#

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)

charred wadi
#

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.

fast nova
#

And when I do the stripe.confirmCardSetup => Do I have the pm_id in the synchronous validation ?

charred wadi
#

Yes the frontend response will contain the PaymentMethod ID

fast nova
#

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 ?

surreal fogBOT
frail briar
#

What's a 'WS'?

fast nova
#

web service

frail briar
#

I don't know what that means. A webhook?

fast nova
#

like a REST API

#

But if you don't know what is it... You can't help me I think ^^

frail briar
#

Never heard to it referred that way. But yes you'll need a server/backend to clone a customer

fast nova
#

lol. Is it possible to continue with soma ? Or to have an other guy please ?

frail briar
#

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

fast nova
#

Have you read all the conversation ?

frail briar
#

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

fast nova
#

Sorry it's because your answers are weird.

#

but let's try

frail briar
#

Really? I think they're pretty clear

fast nova
#

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

frail briar
#

Can you try and re-phrase the question?