The Engineering of Payments: Subscriptions

Recently, Yogini Bende tagged me on a post where Shobhit Nagpal asked the following question:

Link to post.

The question is critically important for anyone thinking of building a SaaS or even a D2C Subscriptions business. Yet few talk about these. It is surprising how well the question encompasses the various aspects of building a Payment System - especially with Subscriptions in the mix! Thought I'd respond, but my thoughts kept growing beyond the comment text size limitation, so I wrote an article instead...

Handling payments, especially for subscriptions, can get tricky, and there are a few key things to consider. Let me break it down for you.

1. Choosing the Right Payment Provider for Subscriptions

Your thought process is on the right track, but subscriptions require a slightly different approach when it comes to payment handling. First, you absolutely need to select a payment provider that supports webhooks. In today’s world, webhooks are the standard for real-time updates on payment status (success, failure, or renewal). They allow your system to listen for events and update the user’s subscription tier accordingly. I’d strongly recommend avoiding any payment gateway that doesn’t offer webhooks in its ecosystem, as manual checks or delayed callbacks can lead to a poor user experience and potential errors. Look for providers like Stripe, DodoPayments, Razorpay or Paddle; they’re built for subscriptions and handle webhooks well.

2. Synchronous vs. Asynchronous Systems and Grace Periods

Most subscription systems operate asynchronously, meaning payment confirmations don’t always happen instantly. To handle this, you’ll need a queue system (like Kafka, RabbitMQ or Redis) to process payment success or failure events reliably. A common practice to delight customers is to offer a grace period. For example, Netflix might let you watch for a couple of minutes even if the payment confirmation is pending; assuming the payment will go through. This is because their systems are sometimes asynchronous or slow, and they don’t want to interrupt your experience. If the payment fails or the success callback doesn’t arrive within a set period, you can gracefully downgrade the user to their previous tier (or a free tier, if applicable). This approach ensures the user isn’t abruptly cut off while giving your system time to confirm the payment status.

3. Handling Expired Subscriptions and Renewals

Expired subscriptions are another critical aspect. Often, renewals need to be initiated by the merchant (you), especially if the user has a saved payment method. This means you’ll need to run batch jobs to check for upcoming renewals, say, every 4 hours or daily. During this window, it’s best to let the user continue accessing content until the renewal status is confirmed. Why? The user might have canceled their subscription directly with the payment provider (e.g., through their bank), and you’ll only find out when you attempt the renewal. Most businesses offer a few hours of grace period for entitlements to avoid a jarring experience for the user. If the renewal fails (e.g., the user canceled or their card declined), you can downgrade their access at that point. This balance ensures a smooth user experience while keeping your system in sync with the payment provider.

4. Access to Content After Subscription Expires

Whether an expired user can still access content they created while subscribed depends on the context of your service. For example, if your subscription is for something like event tickets, it makes sense to let users see their tickets even after the subscription ends since they paid for those, after all. But for a service like Google Drive, it’s different. Let’s say a user paid for 1TB of storage, uploaded 800GB, and then stopped paying. If the free tier only offers 100GB, they can’t keep storing 800GB, they’d need to delete or move the excess data to stay within the free tier’s limits. In this case, you’d typically notify the user and give them time to manage their data before restricting access. The key is to define clear policies based on your service’s nature and communicate them to users upfront.

Is Your Approach Right?

Your current thought process, using webhooks to listen for payments and update tiers is solid, but you’ll need to add layers for handling asynchronous delays, grace periods, and expired subscriptions, as I mentioned. Storing user info in a context or store and applying feature guards is a good practice, but make sure your system checks the subscription status periodically (via batch jobs or real-time webhook updates) to avoid showing outdated data. If a user doesn’t pay for the next period, you don’t want to keep showing their old (paid-tier) data indefinitely. Downgrade them after a reasonable grace period to reflect their current status.