#sai-rez_best-practices

1 messages ¡ Page 1 of 1 (latest)

radiant currentBOT
#

👋 Welcome to your new thread!

⏲️ We'll be here soon! We typically respond in a few minutes, but in some cases we might need a bit more time (e.g., server's busy, you've got a complex question, etc.).

⏱️ We close idle threads, which makes them read-only. Once a thread is closed it won't be reopened, but you can start a new thread if you have another question.

🔗 This thread will always be available, even after it's closed. You can find it again using Discord's search, or you can save this link: https://discord.com/channels/841573134531821608/1255876880205090867

📝 Have more to share? Add details, code, screenshots, videos, etc. below.

candid light
#

Hello

#

You can't -- the PaymentIntent must be generated in order to attempt a charge

#

Which means the Subscription must be created, as that creates the Invoices which has the associated PaymentIntent

viral vessel
#

Hi, to expand a little more on the scenario, previously when working with the Payment Methods API, when we used to add the card to the customer, we would receive an error saying the card was declined which allowed us to stop at that step and not go ahead with creating a subscription. However with the above flow in the docs, the error is called on the frontend during the confirmation step

candid light
#

Yeah I mean it is always possible though that the issuer doesn't decline on attachment and instead declines on the actual payment attempt.

#

But if you want another layer then you would attach the PaymentMethod via a SetupIntent first (use mode: setup) and then create the Subscription if that is successful

#

But really we don't recommend doing this

viral vessel
#

So we've also migrated from payment methods to confirmation token, atm our flow is like this

Create confirmation token -> send to backend and create customer -> create subscription -> confirm payment (which saves card to customer account)

Our previous flow was like below

Create payment method -> send to backend and create customer and attach payment method -> create active subscription - confirm payment if intent requires action.

When testing with declined cards, in our old flow, stripe would throw an error at this step send to backend and create customer and attach payment method and we wouldn't have to go ahead, now however the error is thrown at the confirm step.

Is there a way to detect if a card is declined prior to creating a subscription?

candid light
#

The only way is what I stated above

#

Confirming a SetupIntent authorizes with the issuer just like when you would do Customer attachment

#

But both of these auth's are separate from the actual payment that happens with the Subscription

#

It is better to just do one auth -- when you actually attempt payment for the Subscription

viral vessel
#

So the method you mentioned would still have to be done at the confirmation step?

candid light
#

Not sure what you mean by that, sorry

viral vessel
#

Sorry I was referring to what you said here Confirming a SetupIntent authorizes with the issuer just like when you would do Customer attachment

candid light
viral vessel
#

Would this work if we are expecting payments right away? So after creating a subscription, could we return the payment intent from the latest invoice to the client and use confirmPayment to take payment?

candid light
#

Yeah but you don't need to do that... you already have the PaymentMethod so you just charge that?

#

What you just described is the recommended way, and what you are already doing it sounds like?

#

I'm giving you an alternative where you collect the PaymentMethod and then create the Subscription immediately afterward

viral vessel
#

Ok so with what you suggested, would this be correct?

1 - Collection payment details and create confirmation token (we need this for extra validation in the backend)
2 - Create a customer on the backend
3 - Create setup intent and confirm on the backend (attaches payment method to the customer) (errors could be caught here)
4 - Assuming no errors, create a subscription, and since the card is on the customer, the charge is taken and the subscription becomes active

candid light
#

Yep that would be the alternative

viral vessel
#

Ok, and how would this work with cards that require SCA verification? Would they need to confirm on the client?

candid light
#

Yes -- there is a chance that the SetupIntent moves into a requires_action status in which case you need to pass the client secret client-side and confirm again

#

Same for the Subscription