How to handle the checkout session success URL?

[Dashiell Bark-Huss]

   When we make a stripe checkout session we include a success_url:

 session = await this.stripe.checkout.sessions.create({

payment_method_types: ['card'],

line_items: lineItems,

payment_intent_data: {

transfer_data: {

amount: 9999999,

destination: someaccountId,

},

},

success_url: `http://localhost:4000/api/checkout/success?true&session_id={CHECKOUT_SESSION_ID}&alias_id=${aliasId}`, 

cancel_url: `http://localhost:4000/api/checkout/canceled?session_id={CHECKOUT_SESSION_ID}`,

});

The success URL is where stripe sends the user after a successful payment. It's a GET request since stripe is redirecting the user. Many apps using stripe will need to take actions after a successful checkout- sending an email receipt, notifications, sending paid content, updating the order in the database etc. But it's suggested not to do these actions in  GET requests because GET requests are supposed to be idempotent  and safe. 

For example an unsubscribe link in an email should not unsubscribe a user but instead the "proper approach for unsubscribe links is to lead to a page where the user can click a button to unsubscribe (where the button click triggers a POST request)."src This is because "Many, many, many tools, utilities, web crawlers and other thingamajiggies assume that GET will never be a destructive action (rightly so, since it's specified this way). If you now break your application by breaking that specification, you'll get to keep both parts of your application." src

So I was wondering what is the proper way to handle the stripe success url? If we follow the suggested advice above, then the success url would link to a page where the user clicks a button that updates the order, emails a receipt, etc. But then we are relying on customer to finish the order that has already been paid for. If they don't press that button then important actions aren't completed. What is the proper way to do this? Or does the suggestion to not change the database on a GET request not apply for some reason to these type of actions?

[Remi J.]

Hey Dashiell,

We usually recommend handling operations like sending email receipts or recording authorized access to your product from within the webhook handler. The idea is that your code will receive the `checkout.session.completed` event and handle sending the email receipt at that point for example. This is important as your customer could close the browser before being sent back to your website or they could simply lose the connection during the redirect.

If you do it this way, the redirect should simply be checking the state of the payment either in your database or by retrieving the Session via the API [1] and then displaying a success message which would be idempotent and not break the design patterns you are mentioning.

Ultimately though, I would say those design patterns are more guidelines than strict rules. If I were building this myself I would check the record in my database during the redirect and if I haven't yet processed the event I would run the same operations my webhook handler would before displaying the success. While this is performing a write during the redirect, it's ultimately idempotent and doesn't really go against the spirit of the design!

I hope this helps!

Remi

[1] https://stripe.com/docs/api/checkout/sessions/retrieve

--
To unsubscribe from this group and stop receiving emails from it, send an email to api-discuss...@lists.stripe.com.