#ironbeard_best-practices
polar martenBOT
👋 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/1333807945686712350
📝 Have more to share? Add more details, code, screenshots, videos, etc. below.
fluid horizon
Sorry, I hit submit before I finished typing up my questions
rapid yarrow
hi there!
fluid horizon
I suppose I'm trying to understand the ConfirmationToken a bit. Currently, the checkout flow is: 1. Create Account, 2. Contact Info, 3. Payment Info 4. Done!
I generate the client_secret (via creating a Subscription) when they request the "Payment Info" step of my flow and pass it to the CardElement.
So I'm trying to figure out how this would change if i want to add in a "confirmation" page.
rapid yarrow
well, the documentation you shared explains all the steps to create a confirmation page.
are you stuck at a specific step?
polar martenBOT
fluid horizon
Is this the right idea?
- Insert the PaymentElement inside of a
<form>(mounted etc) - when that form is submitted I prevent form submission, call
preventDefault, thencreateConfirmationToken, and then send that to the server - Then it says I can use
stripe.confirmationToken.retrieve()to display information about the payment method on the Confirm page.
But the next step on the docs page is "Create a PaymentIntent". Can I still do this by creating a Subscription and using latest_invoice.payment_intent? Do I still return the client_secret from this PI to the front end and..when they click the final pay button, I pass both the client secret and the confirmation token to stripe.confirmPayment?
balmy socket
👋 stepping in
You wouldn't want to prevent form submission -- you need that submission to create the Confirmation Token.
And yes, you can still use the latest_invoice.payment_intent here
You pass its client secret and Confirmation Token to the frontend to confirm as you noted
fluid horizon
So formerly I would pass clientSecret and e.g {paymentMethod: {card: document.getElementById('card')}} to confirmPayment, but now I send {confirmParams: {confirmation_token: '{{ CONF_TOKEN }}'}} instead (since, the Card/Payment element wont be rendered on the confirm page)
fluid horizon
You wouldn't want to prevent form submission -- you need that submission to crea...
Isn't the confirmation token created on the front end by calling createConfirmationToken? I'd need to prevent form submission to make sure that gets run before the form is submitted and a response loaded?
balmy socket
So formerly I would pass `clientSecret` and e.g `{paymentMethod: {card: document...
correct
balmy socket
Isn't the confirmation token created on the front end by calling `createConfirma...
Yeah okay depends on what you are referring to for your form here -- but sounds like you have a flow where it would make sense for that. Mostly you just need to create the Confirmation Token.
fluid horizon
Okay, final complicated twist:
We offer two types of products, a newsletter which is basically just a PDF that is sent out monthly, and SaaS dashboard. The SaaS part can be upgraded, and to ensure that people always pay for an upgrade up front, we set billing_cycle_anchor=now and proration_behavior=always_invoice. The problem with this is that if someone subscribes to both the newsletter and the SaaS in the same Subscription object on e.g. Jan 1st 2025, and then on Aug 1st 2025 they decide to update their SaaS, the amount they'll have to pay will also include extending the newsletter subscription to Aug 2026, which we want to avoid.
So, our solution has been to actually create two separate Subscription objects anytime someone purchases both, so that the SaaS Subscription can be upgraded without effecting the Newsletter Subscription dates. So I've actually been passing a list of client_secrets to the front end and looping throug them. Is this possible with confirmationToken? Use the same confirmationToken to process two payment intents?
balmy socket
No, you can only use the ConfirmationToken once. But after a successful confirmation on the initial PaymentIntent then you will have a PaymentMethod attached to the Customer here and you could use that PaymentMethod to pay the second Subscription from the backend without needing to confirm on the frontend for that one.
fluid horizon
The confirmationToken only contains info about the PaymentMethod, right? Not e.g. amount that will be charged or the Products/Prices, etc?
balmy socket
Correct, it is a representation of the PaymentMethod.
fluid horizon
No, you can only use the ConfirmationToken once. But after a successful confirma...
Would customer.subscription.updated be a good webhook for that?
fluid horizon
To pay the second Subscription from the backend