The checkout survives 3D Secure redirects

When a client pays with a card that requires 3D Secure, Stripe redirects them to their bank's authentication page. That means the checkout wizard unmounts. The client leaves the site entirely, verifies with their bank, and comes back to a fresh page load. The wizard handles this by reading URL parameters on mount. If step=confirmation and redirect_status=succeeded appear in the query string, the wizard initialises directly into the confirmation step. No intermediate loading screen, no flash of the package selection, no re-render of the payment form. It clears the URL with history.replaceState so the params do not linger, then renders the full-screen confirmation overlay with the consultation booking picker ready to go. The same confirmation flow fires whether the payment succeeded inline or after a 3D Secure redirect. The idempotency key system sits underneath all of this. Every PaymentIntent is created with a UUID. If the client goes back and changes their name or email, the key regenerates so a new intent is created. If the details have not changed, the existing intent and client secret are reused. That means hitting the back button and then forward again does not create a duplicate charge. One wizard component handles the entire four-step flow — package review, detail collection, Stripe Elements payment, and post-payment confirmation with calendar booking — and it survives a full browser redirect without losing state.