Recurring billing β the process of automatically charging a customer every month or every year β rests on a far more complex technical infrastructure than most people assume. Once a user activates a subscription a single time, every subsequent charge must happen without their involvement, and that gives rise to a whole set of problems: storing the card securely, computing the charge at exactly the right time, and handling failed attempts gracefully. In this article we look not at the business model of subscriptions but at the billing mechanics underneath it β what a developer actually needs to build and how. The goal is to give you the knowledge required to construct a reliable recurring payment system inside your own website or application.
You store a token, not the card
The first and most important rule of recurring billing is that you never store the customer's card number on your own server. Instead, the payment provider (Stripe, Payme, Click or another gateway) keeps the card inside its secure environment and returns to you a special identifier called a token. By itself this token cannot pull money from the card, but it lets you issue a command to your provider that says "charge this much from that saved card." Thanks to this approach your system is freed from the heaviest part of the PCI DSS requirements, because the real card data never touches your server at all.
Technically this process usually unfolds in two stages. On the first payment the customer enters card details into the provider's secure form, and the provider β through an operation such as a setup intent β confirms and stores the card. Then your database saves this token and the provider-side customer identifier alongside the user record. For every subsequent payment you simply use this token to send a request to the provider's API, and it charges the card. An important nuance is that a token may expire or a card may be reissued, which is why providers frequently offer a card updater service that automatically refreshes outdated card details behind the scenes.
The charge schedule and billing cycle
Every subscription has its own billing cycle: monthly, yearly, or an arbitrary interval. The system must track the next charge date for each active subscription and trigger the payment when that date arrives. There are two main ways to implement this. The first is to lean on the provider's own billing system (such as Stripe Billing), where Stripe manages the schedule itself and notifies you through a webhook when the time comes. The second is to run your own cron process daily that finds subscriptions whose charge date falls on today and sends a charge request to the provider for each of them.
Managing your own schedule raises several subtle questions. For example, which day of February does a monthly subscription that began on January 31st land on? Most systems push the charge to the last day of the month in such a case, then return to the original date when possible. Time zones matter too β the charge should run at a fixed time on your server rather than at midnight in the customer's zone, otherwise daylight saving transitions or differing zones will create confusion. An idempotency key is also required, since when a cron job re-runs the same subscription must not be charged twice.
Dunning: retrying failed charges
In real life a noticeable share of recurring payments fails on the first attempt β the card has insufficient funds, has expired, or the bank temporarily declines the transaction. The process of handling such situations is called dunning, and it plays a decisive role in preserving your revenue. Poorly built dunning logic loses customers who are in fact able to pay and merely hit a one-off error, while well-built logic can recover more than half of failed payments.
The foundation of a dunning strategy is a smart retry schedule. An immediate retry right after the first failure is often useless, since the underlying cause has not changed. Instead the system retries the charge at intervals of several days β for instance on day 1, day 3, day 5 and day 7 β because within that window the customer may top up their card or receive their salary. With each attempt the customer should receive an email or SMS notification: "your payment failed, please update your card details." If all attempts are exhausted, the subscription is paused or moved into a restricted mode. Some systems apply smart retry, where machine learning picks, for each card, the time with the highest probability of success.
Proration: changing plans mid-cycle
Proration is the mechanism for fairly recalculating a charge when a customer changes their plan in the middle of a billing cycle. For example, a customer subscribes on the 1st to a plan costing 100,000 sum, but on the 15th wants to move to a 200,000 sum plan. In that case they should receive a credit for the unused portion of the old plan covering the remaining half-month and pay the difference for the remaining portion of the new plan. Proration automates this calculation and determines exactly how much to charge the customer or how much credit to add to their future invoice.
Technically proration is calculated at the day level: the number of remaining days is divided by the total days in the billing cycle, and that ratio is multiplied by the price. On an upgrade to a more expensive plan the difference is usually charged immediately, while on a downgrade it is more often kept as credit and applied to the next invoice. An important decision here is whether to perform the proration immediately as a separate transaction or to fold it into the next regular invoice. Many providers support both variants, but from the standpoint of tax and receipt structure this choice carries real significance.
Invoices, receipts and taxes
For every successful payment the system must create an invoice or receipt that records who paid, when, for which service, and how much. This is needed not only for transparency toward the customer but also for accounting and tax reporting. An invoice usually carries a unique number and must be generated in a sequential order, because tax law in many countries requires gap-free numbering. In Uzbekistan there are fiscal receipt requirements, and each payment may need to be transmitted to the tax authorities' online cash-register system.
Tax calculation introduces a distinct complexity into recurring billing, especially when the service is sold to customers in different jurisdictions. The VAT or sales tax rate changes depending on the customer's location and must either be accounted for as part of the price or added on top. While services like Stripe Tax automate this process, local conditions β that is, adapting to Uzbekistan's tax system β frequently require additional manual integration. The best approach is to separate tax logic from billing logic and build it as a standalone module, so that when rates change you do not have to rewrite the entire system.
Chargebacks and disputes
A chargeback is the situation where a customer contacts their bank and demands a reversal of a completed payment. In recurring payments chargebacks are especially common, because customers sometimes forget to cancel a subscription or, seeing an unexpected charge, mistake it for fraud. Each chargeback causes you to lose not only the transaction amount but also an additional fee charged by the bank, and if your chargeback ratio is high the payment provider may block your account entirely.
The best way to reduce chargebacks is transparency. The statement descriptor should be recognizable, a reminder should be sent to the customer before each charge, and the process of cancelling a subscription should be simple. Technically your system must listen for chargeback webhooks and, when they arrive, automatically pause the subscription, restrict the customer's access and update internal records. In some cases a chargeback dispute requires, as evidence, logs showing the user actually used the service along with delivery confirmations, so keeping this data on hand is worthwhile.
Synchronizing state through webhooks
One of the most critical technical parts of a recurring billing system is keeping state in sync. Your database and the payment provider must always agree on the true state of a subscription. The tool for this is webhooks β HTTP requests the provider sends to your server in real time when important events occur (a payment succeeded, a payment failed, a subscription was cancelled, a chargeback was opened). If you rely on your own database alone, you may remain unaware of a subscription cancelled on the provider's side and keep serving the customer.
Handling webhooks correctly requires following several rules. First, verify the signature of every webhook, otherwise someone could send a forged event and deceive your system. Second, make webhook handling idempotent β the same event may arrive several times, so before processing it check whether it has already been handled. Third, accept the webhook immediately and perform the heavy processing in the background through a queue, because the provider expects a fast response and will resend on delay. Account for out-of-order delivery as well: events may not arrive in the order they were sent, so determine the current state by the timestamp on each event.
Tools and the Uzbekistan reality
Globally, Stripe Billing is considered the de facto standard for recurring payments, since it solves a substantial share of the proration, dunning, tax and webhook work straight out of the box. As alternatives there are specialized billing platforms such as Chargebee, Recurly and Paddle, which are particularly convenient for businesses with complex pricing models or global tax requirements. These tools spare you the need to build billing infrastructure from scratch, but they work primarily with international cards and currencies.
In the Uzbekistan context the situation is specific. Local payment systems β Payme, Click, Uzum and others β are oriented mainly toward one-off payments, and their capabilities for recurring charges and stored cards (tokenization) are not as developed as those of international providers. Some systems let you store a card token and run a repeat payment later, but high-level functions such as proration or automatic dunning you will often have to build yourself. Therefore, when constructing recurring billing in Uzbekistan, the most practical approach is to write the core of the billing logic β scheduling, retries, proration, state management β yourself, and use the payment provider only as a money-charging layer. This gives you independence from provider limitations and the ability to plug in new payment systems in the future.