ironbeard_confirmation-token-flow | Stripe Developers | Page 1

pliant flareBOT Jan 20, 2026, 3:25 PM

#

👋 Welcome to your new thread!

⏲️ We'll be here soon! Typically we respond in a few minutes, but sometimes we might take a bit longer if the server is busy or if you have a particularly tricky question.

⏱️ We close idle threads, which makes them read-only. Once a thread is closed it won't be reopened, but you can always 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/1463192632464511188

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

#

midnight nacelle Jan 20, 2026, 3:48 PM

#

hi there, sorry for the delay, looking into this now

austere crag Jan 20, 2026, 3:49 PM

#

All good 🙂

midnight nacelle Jan 20, 2026, 3:55 PM

#

when you say you're doing a two-step confirmation, you mean you're following something like this guide, correct? https://docs.stripe.com/payments/build-a-two-step-confirmation

Build two-step confirmation

Add an optional review page or run validations after a user enters their payment details.

austere crag Jan 20, 2026, 3:56 PM

#

Correct

#

But idk if I should be create the PaymentIntent, or just creating a Subscription and getting the PI that way

#

all purchases are subscriptions in the end

midnight nacelle Jan 20, 2026, 4:06 PM

#

I've never tried this specific flow before, but you would want to get the client secret off the Subscription by expanding latest_invoice.confirmation_secret and then using that with the Confirmation Token. which means you would likely need to create the Subscription using default_incomplete as the payment behavior, so it doesn't require payment immediately. I can try this out but it might take me a bit, Discord is busy today

austere crag Jan 20, 2026, 4:08 PM

#

I think I can do that. But if someone doesn't end up following through and pushing the final submit payment button, and say they go back and add/change their subscription, would it be best to just delete the incomplete subscription and create a new one, or try to edit it?

midnight nacelle Jan 20, 2026, 4:26 PM

#

you could do either way, I don't think it would make much of a difference since the Subscription wouldnt' be active yet

pliant flareBOT Jan 20, 2026, 4:45 PM

#

slim cape Jan 20, 2026, 4:53 PM

#

Hi there! I'll be taking over for denton if you have more questions

austere crag Jan 20, 2026, 4:57 PM

#

If I create a Subscription with collection_method="send_invoice", when will the invoice be sent to the Customer? After the time elapsed in days_until_due?

slim cape Jan 20, 2026, 4:59 PM

#

The Invoice is sent when the Invoice is finalized. days_until_due affects when the Subscription changes status if the latest Invoice isn't paid

austere crag Jan 20, 2026, 5:18 PM

#

So if the important things for my flow are:

Display a review page separate from the PaymentElement where the user can confirm the purchase, and
Allow some customers to do push payments via bank transfer,

Does the following seem right?

GET /checkout/payment/ : dispay PE with currency, amount, mode=subscription and possibly customerSessionClientSecret. Subscription has not been created yet.

If customer clicks the "Review Order" button, then call createConfirmationToken and send that info to the backend via POST
If customer clicks "I want to pay by bank transfer", don't call anything, just submit a POST to backend

POST /checkout/payment/:

If confirmation token, create the Subscription, using default_incomplete.
If they decided to pay by bank transfer, then pass collection_method="send_invoice", days_until_due to Subscription.
3.GET /checkout/review/: pass latest_invoice's client secret and confirmation token (if it exists) to front end, along with other info for review
If confirmation token exits, use that plus latest_invoice client secret with stripe.confirmPayment when they click the final submit button.
If token does not exist, display a PE with the latest_invoice client secret to only show Bank Transfer info. Submitting the PE will display the modal window with the virtual bank account # for client to send money to.

slim cape Jan 20, 2026, 5:35 PM

#

Yep, that sounds right.

#

Are you aware of test clocks as a feature?

austere crag Jan 20, 2026, 5:38 PM

#

Not really, how are they relevant?

#

Also side note: if I want to support both card payments (via PE) and bank transfers (and the vast majority of subscriptions are paid by card), is it actually important to create the Subscription two different ways (collection_method="send_invoice"), or can I just create the subscription with default_incomplete (don't specify "send_invoice") and pass that client secret to a PE on the /checkout/review/ page with only the bank transfer option enabled?

slim cape Jan 20, 2026, 5:43 PM

#

Because they let you test a subscriptions integration end-to-end without waiting weeks/months for subscriptions to cycle

#

You can't really see the behavior you're programming without them. They'r eessential

#

Yes, it is necessary to do it two different ways if you want most subscriptions to be charge automatically for cards, etc, and some to allow bank transfers

#

charge automatically & bank transfer are mutually exclusive

#

(because bank transfers are a push payment method)

austere crag Jan 20, 2026, 5:48 PM

#

So if I initialize a PE with a client secret that came from a change_automatically Subscription, it wouldn't show the Bank Transfer option?

slim cape Jan 20, 2026, 5:49 PM

#

Yep

austere crag Jan 20, 2026, 5:53 PM

#

If people change their mind on the review page and either want to add to the subscription or change their payment method from bank to card, should I just delete the subscription and create a new one?

slim cape Jan 20, 2026, 5:54 PM

#

You can just update it: https://docs.stripe.com/api/subscriptions/update?lang=curl#update_subscription-collection_method

austere crag Jan 20, 2026, 5:56 PM

#

Is it worth updating the items? if it generated and finalized an invoice with different items etc..

#

(if someone wants to change their items after the Subscription was created)

slim cape Jan 20, 2026, 6:03 PM

#

I'm sorry, could you clarify what you mean?

austere crag Jan 20, 2026, 6:07 PM

#

So someone fills out the PE with card info, and then submits and POSTs the confirmation info to my backend, and I create the Subscription (on POST) before redirecting to GET /checkout/review/. At this point, if they decide to change what's in their cart/change their subscription, then they come back through the checkout flow with a different package, should I just delete the existing Subscription (which has finalized an invoice at this point) and create a new one with the new items, or try to update that Subscription?

slim cape Jan 20, 2026, 6:13 PM

#

It is likely easier to delete the existing Sub and create a new one, but I would strongly recommend building the version you want to try out and testing it end-to-end

austere crag Jan 20, 2026, 6:15 PM

#

Okay, thanks so much!

pliant flareBOT Jan 20, 2026, 6:16 PM

#

austere crag Jan 20, 2026, 6:27 PM

#

I'm finally wrapping my head around all this. The last uncertainty I have is this: if my PE is initialized with amount: 1000, currecy: "usd", mode: "subscription" (e.g. no client secret) and then pass a return_url to stripe.createConfirmationToken()...when is the return_url used? the return value of that is { error, confirmationToken }. Is return_url redirected to when I call stripe.confirmPayment(subscription.latest_invoice.payment_intent.client_secret, { confirmParams: confirmatonToken.id })?

digital tree Jan 20, 2026, 6:32 PM

#

Hey there,
taking over for my colleague who had to step away.
The return_url is needed for payment methods that redirect you away from the payment element to make sure it gets you back to your application/integration. Does that make sense?

austere crag Jan 20, 2026, 6:38 PM

#

Hmm, I think so. But if I'm calling createConfirmationToken() and Stripe decides it needs to redirect for some reason, I guess it would pass the confirmation token id as a URL param to the GET of return_url? If so, then it's probably not a good idea for me to create the Subscription on a POST of the endpoint with the PE. 🤔

Is it possible for me to avoid return_url if i restrict my payment methods to cards only?

digital tree Jan 20, 2026, 6:46 PM

#

The redirect happens automatically because of the payment method you choose. That has nothing to do with the Confirmation Token per se. You define the return url for example if you have a multi step checkout, and after the step for the payment method you want to be redirected to the cart or order summary before actually confirming the payment. So using a POST request is totally fine.

Normally their shouldn't be a return url necessary only for cards.

austere crag Jan 20, 2026, 6:49 PM

#

Does the redirect only happen during confirmPayment, or can it happen during createConfirmationToken?

digital tree Jan 20, 2026, 6:55 PM

#

If you create a PaymentIntent using the vconfirmation token, you would need a return url again, https://docs.stripe.com/payments/build-a-two-step-confirmation?client=js#submit-the-payment

austere crag Jan 20, 2026, 6:58 PM

#

I'm not sure I follow. Would it be correct to say that calling createConfirmationToken() will never cause a redirect? The only time a redirect might occur is when calling confirmPayment()?

digital tree Jan 20, 2026, 7:07 PM

#

I just double checked, because stripe.createConfirmationToken() is more the legacy approach than the recommended approach (still working though). So what I was saying was actually mixing up things between the legacy and the current approach. You can provide the return_url either on the token creation or payment intent confirmation. If you alreayd provided it during token creation you wouldn't have to do it again when creating and confirming the payment intent, since you are using the confirmation token to confirm the payment intent

austere crag Jan 20, 2026, 7:10 PM

#

Oh, I'm confused: I thought confirmation tokens were a newer approach. If I want to use a Payment Element to collect payment details and display them on a /checkout/review/ page so they can review their PM and Subscription info before pressing confirmPayment(), don't I have to use ConfirmationTokens?

digital tree Jan 20, 2026, 7:11 PM

#

No, confirmation token are the right thing...

austere crag Jan 20, 2026, 7:11 PM

#

My payment intent is coming from Subscription.latest_invoice.payment_intent which is created on the POST before the redirect to GET /checkout/review/

#

Okay, thanks! Have a great one 🙂

digital tree Jan 20, 2026, 7:12 PM

#

Maybe I am just a bit confused today. Sorry (busy day).

#

You are on the right path. That's for sure. And you only need the return_url either on the confirmation token creation or the payment intent confirmation request. BUT the return_url is only needed for payment methods or thid party integrations that require action on their website. Card payments normally don't need a return url. So if you limit the payment_mmethod_types to only cards, then you should be fine.

austere crag Jan 20, 2026, 7:15 PM

#

no worries, I understand 🙂

digital tree Jan 20, 2026, 7:15 PM

#

Cool. I know I can be confusing sometimes. So I just wanted to make sure you got the information you need.

#ironbeard_confirmation-token-flow