Subscription Payments

What Are Subscription Payments?

Subscription payments are recurring charges that a merchant processes automatically on a regular schedule in exchange for ongoing access to a product or service. When a customer signs up for a streaming platform, a SaaS tool, or a meal-kit delivery, they authorize the merchant to charge their payment method at each billing cycle without requiring manual approval for every transaction.

The subscription model differs from one-time purchases in a fundamental way: the customer grants standing permission to pull funds from their account. This pull-payment authorization is what makes the entire system work, and it is also what creates most of the complexity around failed payments, regulatory requirements, and the challenge of adapting the model to crypto payment rails.

The subscription economy has grown significantly as businesses across software, media, fitness, and e-commerce have shifted from one-time sales to recurring revenue models. Understanding how the underlying payment mechanics work is essential for anyone building or evaluating payment infrastructure.

How It Works

A subscription payment lifecycle involves several stages, from the initial customer authorization through ongoing automated billing and eventual cancellation.

Initial Authorization and Credential Storage

The lifecycle begins when a customer enters their payment details and agrees to recurring charges. This first transaction is classified by card networks as a cardholder-initiated transaction (CIT): the customer is actively present and authenticating the payment. In regions subject to Strong Customer Authentication (SCA) requirements, the customer completes 3-D Secure verification during this step.

After authorization, the merchant stores the payment credential. Rather than retaining the raw card number, the payment processor or gateway converts it into a token: a reference value that can be charged later without exposing the original card data. This tokenization process satisfies PCI DSS requirements and reduces the merchant's data-breach risk.

Scheduled Billing

At each billing interval, the merchant's billing system submits a charge against the stored token. These subsequent charges are classified as merchant-initiated transactions (MITs): they happen without the cardholder's active participation. The merchant must include a reference to the original CIT so the issuing bank can verify that the customer previously authorized recurring charges.

Because the customer is not present, MITs are exempt from SCA in regulated jurisdictions, but only when properly flagged. If a merchant fails to tag a transaction correctly as an MIT, the issuer may decline it, raising the decline rate and potentially triggering chargebacks.

Retry on Failure: Dunning

When a scheduled charge fails, the merchant enters the dunning process: a structured sequence of retries and customer notifications designed to recover the payment before canceling the subscription. Modern dunning systems use a layered approach:

1. Silent retries: the system automatically reattempts the charge after a short delay, often with optimized timing based on historical success rates
2. Account updater check: the system queries the card network's updater service to see if the card has been reissued with new details
3. Backup payment method: if the customer has a secondary card or bank account on file, the system falls back to that
4. Customer notification: emails or in-app messages prompt the customer to update their payment information

Card networks impose strict limits on retries. Visa allows approximately 15 reattempt transactions within a rolling 30-day window for soft declines (temporary failures like insufficient funds). Hard declines, such as a closed account or stolen card, should not be retried at all: each attempt incurs a penalty fee. Mastercard applies excessive-retry fees starting around the eighth failed attempt per card per calendar month and caps total failed attempts at 35 within any continuous 30-day period.

Cancellation

Subscriptions end either through voluntary cancellation by the customer or involuntary churn from repeated payment failures. Involuntary churn, where the customer still wants the service but their payment method fails, accounts for a significant share of subscription losses. The primary causes are card expiration, card reissuance by the bank, and insufficient funds.

Regulatory frameworks increasingly require that cancellation be as easy as enrollment. In the United States, the FTC's Restore Online Shoppers' Confidence Act (ROSCA) requires clear disclosure of subscription terms and a simple cancellation mechanism. The EU's Consumer Rights Directive imposes similar transparency requirements on auto-renewal contracts.

CIT vs. MIT: How Card Networks Classify Recurring Charges

The distinction between cardholder-initiated transactions (CIT) and merchant-initiated transactions (MIT) is central to how subscription payments are processed. Card networks use this classification to determine authentication requirements, liability assignment, and interchange pricing.

Merchants must correctly flag each transaction type. Mis-tagging an MIT as a CIT, or failing to include the network transaction reference linking back to the original authorization, can result in higher decline rates, scheme fines, or chargeback liability shifts. For a deeper look at how payment infrastructure handles these distinctions, see the research on subscription billing infrastructure.

Account Updater Services

One of the biggest threats to subscription revenue is involuntary churn from expired or reissued cards. When a bank replaces a customer's card (due to expiration, fraud, or a product upgrade), the old card number stored by the merchant stops working.

Account updater services solve this by automatically refreshing stored card details when the underlying card changes. Visa's Account Updater (VAU) and Mastercard's Automatic Billing Updater (ABU) push new card numbers, expiration dates, and status information to merchants and their processors.

Traditional account updaters operate in batch mode, running periodic checks (often weekly). Real-time account updaters query the network during the transaction itself, eliminating the gap between card replacement and credential refresh. Network tokens provide an even more seamless solution: because network tokens are maintained by the card network rather than mapped to a specific card number, they update automatically when the underlying card changes.

Use Cases

• SaaS and digital services: software platforms, cloud storage, and productivity tools bill monthly or annually for continued access
• Media streaming: video, music, and news platforms use subscription billing to deliver content on demand
• Physical goods: meal kits, beauty boxes, and replenishment services ship products on a recurring schedule
• Infrastructure and APIs: cloud computing, payment processing, and developer tools often charge based on usage metered at each billing cycle
• Insurance and memberships: recurring premiums and dues that maintain coverage or access over time

Subscription Payments in Crypto

Traditional subscription payments depend on the pull-payment model: the merchant pulls funds from the customer's account using stored credentials. Cryptocurrency payment rails, by design, use a push-payment model where only the account holder can initiate transfers. This architectural difference creates a fundamental challenge for recurring crypto billing.

Smart-Contract Approaches

On smart-contract platforms like Ethereum, developers have built workarounds for recurring payments:

• Prepaid escrow: the customer deposits funds (for example, a year of payments) into a contract, and an operator triggers periodic releases. This requires locking capital upfront and introduces custodial risk.
• Pre-signed transaction batches: the customer signs a set of future transactions off-chain, and the merchant submits one per billing period. The contract validates each signature and releases funds. The customer retains the ability to revoke unused authorizations.
• Token approvals: on ERC-20 compatible chains, a customer can approve a contract to spend up to a specified amount from their wallet. The merchant calls the contract each period to transfer the subscription fee, provided funds and approval remain available.

High gas fees on Ethereum mainnet make small, frequent subscription charges impractical. Layer 2 networks like Arbitrum, Optimism, and Base reduce costs to a fraction of mainnet fees, making recurring charges more viable. The proposed ERC-1337 standard attempted to formalize recurring blockchain payments, though adoption remains limited.

Bitcoin and Lightning

Bitcoin's UTXO model has no concept of standing payment authorization, making native recurring billing impossible. On the Lightning Network, BOLT 12 offers introduce a potential path toward recurring payments. A merchant can issue an offer that the customer's wallet fetches and pays on a schedule. For more on this approach, see the research on BOLT 12 recurring subscription payments and recurring stablecoin payment infrastructure.

In Spark's model, recurring payments could leverage the protocol's instant settlement and low fees to process scheduled push payments, though the customer's wallet must actively participate in each billing cycle rather than authorizing a passive pull.

Risks and Considerations

Involuntary Churn

Failed recurring charges are one of the largest sources of revenue loss for subscription businesses. Card expiration, bank-initiated reissuance, and insufficient funds all cause payments to fail without the customer intending to cancel. Effective dunning strategies and account updater services can recover many of these, but some percentage of customers are inevitably lost to payment friction.

Chargeback Exposure

Subscription merchants face elevated chargeback risk because customers may forget they subscribed, dispute charges after free-trial conversions, or find cancellation difficult. Card networks impose chargeback ratio thresholds, and merchants who exceed them face monitoring programs, increased fees, or loss of processing privileges.

Regulatory Compliance

Subscription billing is subject to consumer protection regulations in most jurisdictions. Requirements typically include clear disclosure of recurring terms before enrollment, confirmation of consent before billing, and a straightforward cancellation process. In the United States, ROSCA and state-level auto-renewal statutes govern these obligations. The EU's Consumer Rights Directive and Payment Services Directive 2 impose additional requirements on how merchants handle stored credentials and recurring mandates.

Crypto-Specific Risks

Smart-contract-based subscription systems introduce risks not present in traditional card billing. Prepaid escrow models lock customer funds with custodial risk if the contract is exploited. Token-approval approaches require the customer to maintain both sufficient balance and an active approval, and a compromised or malicious contract could drain the full approved amount. Unlike card payments, there is no built-in dispute or reversal mechanism on most blockchains, leaving customers without recourse if something goes wrong.

This glossary entry is for informational purposes only and does not constitute financial or investment advice. Always do your own research before using any protocol or technology.