It sure will!
1 Like
Is there any need to create a zap for when a subscription has been cancelled if I’ve created the one from the video that includes the next charge date?
If a user pays for a month and cancels immediately, then when that next charge date comes up and new payment isn’t received, the zap doesn’t update and the relationship is broken and the subscription is lost?
No need unless you want to cancel their plan IMMEDIATELY (useful for losing access to premium resources, or the ability to view contact information, etc.).
2 Likes
And the logic is because the subscription zap never gets updated b/c payment is no longer recieved?
Correct. The Subscription canceled event only gets called when a user cancels their subscription or if there’s a failed payment when attempting to resubscribe that term:
Hello @Robert_Petitto . It’s abdulghafor again.
Is there a way to get these videos for free or for a discounted price 
It would be appreciated.
99% of my video content is free. This is the one video series I have behind a paywall because of it’s complexity. It also comes with the template and the Make Blueprint. $49.95 is very reasonable in my opinion.
4 Likes
Hello @Anderel
Did you fix this issue, i just faced it . I tried to find a solution but i did not found.
Can you help?
Has this been updated with any Glide features like the Query column or integrations?
It hasn’t. Query column would improve the conditional relation I make to determine if the recent payment is within the latest payment period.
No integrations yet as none of them improve the UX. If Glide ever gives us a native API column, I’ll certainly provide an overhaul video/post.
3 Likes
Hey all!
I updated the original post with my recommended method to monetize a Glide app. Hoping to continue building out this series as advancements in payment methods, api calls, and automations have become more accessible!
Part 1: The Setup
Parts 2 & 3 will be released over the next couple days. Stay tuned! 
5 Likes
Thank you for the video, Bob. In-app payments has been a little over my head, but I’m ready to have a look.
In Part 1, I understood that content items are free or paid items, and you apply visibility conditions to display them based on if the item is free or paid for. I then understood that you addressed the case of free vs premium content.
I was wondering if you’ve consider the case of in-app credits: a user could purchase credits, say $10 for a credit, and then use in-app credit to unblock content or functionalities within the app?
I’ll need to rewatch part 1 and then parts 2 and 3 to see if a credits system would be covered in your explanation.
Either way, amazing stuff as always. And thank you. The Glide student in me is grateful for your tutorials.
A credit system would work like the “one-off payments” concept from the video. You would have a payments table that would capture the user ID and how many credits they purchased. A simple relation to that table with a Rollup in the users table would allow the user to see how many credits are in their balance!
2 Likes
Part 2: The Payment Link
→ Set up a free Stripe account
→ Connect Stripe to Payhere
→ Create a one-off or subscription payment link fed
My secret: Use a DONATION link to pre-fill a payment link with your app’s user/product information
5 Likes
Part 3: The Automation
→ Set up a free Make account
→ Create an automation that creates new payment records in your app
→ Create an automation that updates the Users table when a customer pays for a new subscription
Note: I prefer Make.com because of the free collaboration and routing functionality, but this can easily be done in Zapier as well.
7 Likes
This one with the new Make Integration is so much easier to implement than the original version! Also I think not using the Call API, it doesnt incur as many updates! Nice job!
Hmm I doubt this is the case. Do you have any proofs for this?
I was under the impression that I would only incur an update when there is an update / webhook received vs the Call API having to check once a day