Recurring billing

Recurring billing charges a stored payment credential (a vaulted card or ACH token) on a schedule the customer agreed to: monthly SaaS seats, quarterly memberships, annual licenses, or metered usage billed in arrears. The merchant initiates each charge without the customer present, which makes it a form of card-not-present processing with its own card-network rules for cardholder consent, receipt delivery, and cancellation.

The mechanics involve more than a cron job. Each cycle the biller must resolve the amount (plan price, proration for mid-cycle changes, taxes, credits on the customer’s balance), charge the stored token, generate an invoice, and handle the failure path. Failures are common in recurring portfolios (cards expire, get reissued, or hit limits), which is why serious recurring systems pair billing with dunning (structured retry and escalation) and with account-updater services that refresh reissued card numbers before they decline.

When evaluating a processor for recurring volume, three details matter. First, where the tokens live: if the vault belongs to a third-party gateway, migrating means re-collecting cards. Second, how failures are handled: retry schedules, escalation stages, and auto-cancel rules should be configuration, not custom code. Third, whether billing and processing share a ledger: a billing layer bolted onto a separate processor means two margins, two reconciliation surfaces, and two support queues.

QorCommerce Recurring is QorPay’s subscription billing module. It runs directly on the QorCommerce processing stack (same vault, same settlement ledger) and is available now.