#Kev - SetupIntent
dim thicket
Sure: seti_1LZUptHt9gd9Wdo8eiMGFmNN
placid hill
And the related subscription ID please ?
dim thicket
sub_1LZUpsHt9gd9Wdo87YnUO50t
serene kettle
@dim thicket Thanks for the patience whilst we look into this!
placid hill
So to summarize, you have created a PaymentMethod using Stripejs from your platform account https://dashboard.stripe.com/logs/req_rm2TcRYQjdk2vb
After that you have clone it for the connect account https://dashboard.stripe.com/logs/req_ntNS4ZfchMeRrd
Then, you confirmed the SetupIntent created by the subscription using the cloned PayementMethod https://dashboard.stripe.com/logs/req_F8Q5PZul875dw7
When using it for the subscription, the bank asks for a 3ds verification as the card wasn't authenticated.
dim thicket
No problem at all. Thanks for your patience looking into it 😀
placid hill
Why are you creating the PaymentMethod on your platform account like that? it doesn't carry on the necessary authentication for the card, you should use SetupIntent from the begining instead
dim thicket
We recently updated the implementation because of another error. I can check with the team why the new process was chosen.
If we continued to create the payment method on our platform account (which enables saved cards at platform level that can be used with multiple connect customers) could we do the setup intent as we clone the card into the connect account, before the subscription is created?
empty zephyr
well you have multiple options here and it's a bit complicated.
The problem here is you
- tokenize the card on the platform(entirely offline, this doesn't contact the bank or authenticate or anything like that)
- clone to the connected account
- do a SetupIntent. That's the first time we might contact the bank and it might require 3DS so you need to handle it.
One option is to
- use a SetupIntent on the platform to accept and save the card to a Customer there.
- do the cloning
- create the subscription on the connected account. It might still require 3D Secure since it's another payment, but that's normal too and you have to handle it as normal via the
latest_invoice.payment_intent, and when it's complete the subscription is active.
another option is maybe to leave out SetupIntents entirely
-tokenize the card on the platform(entirely offline, this doesn't contact the bank or authenticate or anything like that)
- clone to the connected account
- create the subscription on the connected account. It might still 3D Secure, so you would just handle that as normal via the
latest_invoice.payment_intent, and when it's complete the subscription is active.
dim thicket
Great - thanks very much for the detail.
In the suggested best option do we just accept that the customer will be challenged at the time of first payment? In our use case it will be off session.
empty zephyr
oh ok, well that changes things
the idea is you clone the customer's card and then later when the customer is not present you will be starting a subscription for them on the connected account from a backend action, off-session?
dim thicket
Yes. The customer adds the card (on the platform) and then we clone it on the connect account. The customer is then asked to use the card they have just added (they are still on-session at this point) to create a subscription that will charge on the 1st of the following month.
empty zephyr
then that's not off_session then, fair enough. So the problem with that is they might get 3D Secure twice in a row – once from the SetupIntent prompt, and once from the Subscription payment prompt. That's just how it works, that on-session payment is not what's called a "merchant-initiated-transaction" , so it doesn't get a specific exemption from having been set up previously, so the bank might request 3DS on the payment immediately after, that does happen.
The correct way to do this generally is to never use a SetupIntent and then immediately a payment, you should only use SetupIntents to save a card and charge it later.
In this cloning scenario that's hard to accomplish, but it's why I feel like the last option I posted is the most reasonable from the customer perspective since it only involves a single transaction with the customer's bank, which is creating the subscription's initial payment. But it has the drawback that the card on the platform is not set up(but that might not matter if your platform never actually does anything but clone it to other connected accounts and try to charge/create subscriptions there).
dim thicket
Excellent. It sounds as if you've solved our problem. We'll make some changes and hopefully get it working. Thanks very much for your help 👍
empty zephyr
the one thing I'd mention is that after cloning the card, you need to attach it to a customer on the connected account to be able to create a subscription; you should pass the undocumented validate=false parameter on that API call, since otherwise we can do a $0 validation that can trigger 3DS or declines as well.