Turns out, you can trigger a server-side Checkout Session in Stripe from Glide, pass customer data (or any other data you want), and have it work in Mobile Safari with the pop-up blocker on 
See demo!
9 Likes
Hi Evgeny! Your demo on Glide x Stripe Checkout looks stunning. Could you share more details about the setup process? And, if possible, would you consider providing a template? Thanks!
Button = Fire a webhook - add customer details as parameter
- When Webhook is received (use the URL they provide in the step above)
- Make custom Stripe API call to create a checkout session: Sessions | Stripe API Reference
- Set the Webhook Response to 302 and the destination URL that you get from Step 2 as the destination. That will open the checkout window.
Bonus tips:
- You will need to set up a workflow for when the Checkout Session is completed.
3 Likes
Thank you for the detailed implementation guidance!
I’d like to allow my app users to manage their subscription plans directly, accessing the Stripe Customer Portal (Customer self-service with a customer portal | Stripe Documentation) seamlessly. Ideally, this integration would be as smooth as the Checkout solution (screenshot reference: Stripe Checkout | Stripe Documentation).
However, another topic is syncing the subscription status with Glide’s User Table, reflecting purchases, modifications, etc.
What would be the most effective way to set this up without having to configure numerous webhooks? Is there a way to establish a controller that can handle various events, triggering the appropriate synchronization updates?
Any insights or best practices would be greatly appreciated!
Webhooks.
Use Make to reflect changes to user subscriptions by creating a webhook in stripe that fires on subscription events and reflect the changes in the user table.
2 Likes
You can do a single webhook and allow multiple events. Then filter those events in Make.
However, if you’re having multiple scenarios, I would advise having multiple webhooks so you can use those separately in Make, it’s easier to debug. Not even sure if Make allows having same Stripe webhooks in different scenarios.
2 Likes
I have my subscriptions through the Stripe Customer Portal and then had to create three different webhooks in Zapier to cover my use cases. One for checkout completed, one for updates to subscriptions and one for blocking subscriptions (payment fails, retries, etc…). It has seemed to cover majority of the use cases
3 Likes
this. I think it is just best practice to have one dedicated webhook for an event, because you don’t want one failed event to break your automations for all other events.
1 Like