Gesundheit-payment-method-setup | Stripe Developers | Page 1

dreamy summit Oct 29, 2021, 2:55 PM

#

Hello again, what are you running in to?

dire frost Oct 29, 2021, 2:55 PM

#

Hello!

#

We're setting up payment methods to collect future payments. Our current flow is use the SetupIntent API to create a SetupIntent, return the client_secret to the front-end to finish the setup.
Because we'd only want one card per user, we listen to setupintent_succeeded to detach the old card and make the new one default.

#

All of these steps will be done on the page before calling the Subscription API to create a Subscription.

#

We'll need the default payment method set to determine taxes.

#

The problem is, webhooks may arrive later than expected on the backend, which will cause desync when the user proceeds to the next page (i.e. create Subscription) before the new payment method is set as default.

#

My colleague told me that we can also start the set up process from the frontend by using (stripe.createPaymentMethod) in Stripe.js, is this true?

dreamy summit Oct 29, 2021, 3:21 PM

#

For that last bit, are we talking confirmSetup vs createPaymentMethod?

#

And can you describe that last part of the issue with the desync in a bit more detail?

dire frost Oct 29, 2021, 3:37 PM

#

dreamy summit And can you describe that last part of the issue with the desync in a bit more d...

Due to design purposes and requirements for Stripe Tax to work, we absolutely need a user to have a payment method attached to them before they proceed to checkout, therefore we ask the user to enter their payment method before they proceed.
Using the setupIntent, once the user hits "update card", the card will be attached to the user; at the same time, Stripe will send a setup_intent_succeeded event to our backend.
We use this event to check if the user already has a payment method attached. If yes, we detach the old one and set the new one as default.

The question is we can't possibly expect when the event will arrive and be fully received by our backend; we also couldn't expect how long the pm swap will take.
What if the user hits checkout during this period (after Stripe.js receives a "success" result and before backend receives/processes the webhook event)? Which card will Stripe use to determine taxes?

#

Therefore, we are looking for a solution that can

Update/add a payment method to the user
Detach the old one if exists
Set the new payment method as default
All in one take

bold orbit Oct 29, 2021, 3:46 PM

#

@dire frost 👋 we're digging into this!

dire frost Oct 29, 2021, 3:47 PM

#

thank you!

bold orbit Oct 29, 2021, 4:08 PM

#

@dire frost haven't forgotten about you, sorry for the delay, talking with my team but making progress!

dire frost Oct 29, 2021, 4:16 PM

#

No problem!

bold orbit Oct 29, 2021, 4:31 PM

#

Ooooookay, sorry

#

So I think the docs are confusing here. You don't need to collect the payment method details upfront. You need to collect the customer's address and ip to help with tax calculation upfront. Then you create the subscription and then you confirm the invoice's payment intent client-side

#

Due to design purposes and requirements for Stripe Tax to work, we absolutely need a user to have a payment method attached to them before they proceed to checkout, therefore we ask the user to enter their payment method before they proceed.
Can you say more about this? I just tested this myself and this flow worked
1/ Create a customer with email, name, address and tax[ip_address]
2/ Confirm tax has tax: { automatic_tax: "supported", ip_address: "192.168.0.1", location: { country: "US", source: "billing_address", state: "CA" } },
3/ Create a Subscription with payment_behavior: 'default_incomplete'
4/ Client-side confirm the PaymentIntent for the subscription's latest_invoice
It seems to just work. Does that not work for you?

dire frost Oct 29, 2021, 4:39 PM

#

let me see

#

so about your test flow (sorry if i didn't specify this earlier)

1/ Create a customer with email, name, address and tax[ip_address]
We don't plan to use address and ip to determine tax regions. We plan to use the card's billing address to determine tax.

Also, we don't collect these info at account creation. We collect them separately before the user hits the purchase button, as stated above.

#

the only information related to billing we collect are

the card
the billing address of the card

#

so using another website as an example ( we have a very similar flow)

#

#

on the left is the only info we collect

#

i understand that we could collect other details to determine the tax regions, it's just that it's not in our design

bold orbit Oct 29, 2021, 4:57 PM

#

We don't plan to use address and ip to determine tax regions. We plan to use the card's billing address to determine tax.
What's the difference? Why wouldn't you put that address on the customer instead?

dire frost Oct 29, 2021, 4:58 PM

#

Well, if the user changes the card, wouldn't that address change as well?

bold orbit Oct 29, 2021, 4:58 PM

#

sure but you'd change the customer's address and it will change the tax on future invoices too

dire frost Oct 29, 2021, 5:00 PM

#

plus honestly... we're in a tight schedule and we prefer making as little changes to the flow as possible

bold orbit Oct 29, 2021, 5:01 PM

#

Okay so back to your real question, what's blocking you?

dire frost Oct 29, 2021, 5:01 PM

#

bold orbit sure but you'd change the customer's address and it will change the tax on futur...

i lost you there. using SetupIntent changes the customer's address? I thought it changes the payment method's address?

dire frost Oct 29, 2021, 5:02 PM

#

dire frost Therefore, we are looking for a solution that can 1. Update/add a payment method...

this. We want a one-call solution (from front-end to back-end) to ensure concurrency

bold orbit Oct 29, 2021, 5:27 PM

#

There isn't a solution that does that in one call!

#

Unfortunately you'll have to do the back and forth with your server and do multiple separate API requests if it's about changing the card

#

I'm sorry I'm still struggling to grasp what you're blocked on

#

Earlier on you were asking about Webhook and delays. You don't have to wait for the webhook. Use the webhook as a way to catch missed data. But you can go through the SetupIntent confirmation and after it succeeds you submit to your server and update the customer and/or its subscription

bold orbit Oct 29, 2021, 6:22 PM

#

@dire frost wanted to check in and see if that made sense

dire frost Oct 29, 2021, 6:32 PM

#

Sorry! notifications didn't pop

#

yeah. We noticed that there is a stripe.confirmCardSetup available that returns the succeeded SetupIntent. We're planning on sending that object to the backend to complete the card swap. This way from the front-end's pov it's one call, and keeps the concurrency.

bold orbit Oct 29, 2021, 6:34 PM

#

In theory your back end knows the SetupIntent since you already have a "session" ongoing

#

and we recommend webhooks because people lose connections or close the page, though it's less likely to happen on your end since they haven't yet paid, just a SetupIntent

#

so the flow is

1/ Create SetupIntent server-side, remember that id in a session/cookie
2/ Confirm SetupIntent client-side, do 3DS if needed
3/ Promise completes, check if success, if so submit back to your server
4/ Create Customer + attach PaymentMethod to it + make it the default (or optionally change the default after attaching to an existing one)
5/ Create Subscription and expand latest_invoice.payment_intent
6/ If the subscription is incomplete, get the PI confirmed client-side

dire frost Oct 29, 2021, 6:37 PM

#

Basically this flow, yep.

#

(Nvm, my bad, i forgot my own code)

bold orbit Oct 29, 2021, 6:40 PM

#

Earlier when you started the thread you were worried about the delay with the webhook right? With my explanation does that unblock you?

dire frost Oct 29, 2021, 6:41 PM

#

Yep! This totally solves the issue.

#

Thank you so much for the help!

bold orbit Oct 29, 2021, 6:51 PM

#

Of course! I'm sorry it took me so long to grasp that was your issue

#Gesundheit-payment-method-setup