Payment subscription
topropay runs the payment side of your subscription programme on one unified API. Network-token recurring billing, smart retries that learn per segment, account updaters that refresh credentials behind the scenes, and one reconciliation feed across every connected acquirer and method.
The short version
Most subscription businesses already have a billing engine that knows the plan catalogue and the invoicing rules. What they keep rebuilding is the payment side: the authorisation against the right route, the cascade past the soft decline, the smart retry on the right day, the account updater, the SCA exemption logic. None of that is billing — it's orchestration.
topropay handles the orchestration. Renewals authorise through one API. The routing engine picks the route most likely to clear. The vault holds network tokens that survive card re-issuance. Smart retries pick the right recovery window for each decline code. One reconciliation feed lands subscription-aware data in your finance stack. Your billing engine still owns pricing and plans. The payment subscription layer just gets the money in cleanly.
The rest of this page walks through the benefits, the renewal cycle, the use cases, the platform features and the buyer questions we hear most often.
Key benefits
Four outcomes show up consistently once orchestration sits underneath the billing engine — across recovery, approvals, compliance and reporting.
Network tokens and scheme account updaters live in the platform, not in your billing code. When a card is re-issued, lost or replaced, the next renewal authorises against the updated token automatically. Smart retry policies — by decline code, time-of-day, currency and segment — replace the per-provider scripts most teams accumulate over time.
Recurring authorisations go through the same routing engine as fresh-card transactions: every renewal is scored against BIN, scheme, currency, country and risk signals, and sent down the route most likely to clear. The route that won Q1 may not be the route that wins Q4 — the engine adjusts continuously.
Initial mandates capture under 3DS2 with the recurring agreement flagged correctly per scheme. Subsequent renewals run as merchant-initiated transactions inside the exemption framework, so European subscribers don't see a step-up on every monthly charge while you stay PSD2-compliant.
MRR, churn, refund and dispute data roll up against the underlying vault token — same subscriber across providers, schemes and re-issuance events. The reconciliation feed groups by subscription identifier and exposes the lifecycle, not just per-authorisation rows.
How it works
Four lanes — sign-up, renewal, recovery, settle — that every subscription transaction flows through. The platform handles each one through the same unified API.
Initial authorisation captured under 3DS2 with the recurring agreement flag. The vault stores the network token, not the PAN.
Card, SEPA Direct Debit, ACH, Bacs, Open Banking or wallet — selected per subscriber and reused on every renewal.
Each renewal scored against every connected acquirer. The route most likely to clear at the lowest cost wins.
Soft declines fail over to the next ranked route inside the same request — no shopper-side error, no failed renewal email.
Decline-code-aware retry windows replace fixed N-day schedules. The engine learns which patterns recover by segment.
Network-token re-issuance and scheme updaters refresh credentials behind the scenes, before the next renewal fires.
Settlements, fees, refunds and chargebacks normalise into one reconciliation feed across every connected provider.
Subscription identifiers carry through to the reconciliation feed so finance closes from a subscriber-grouped view.
Main use cases
Same orchestration layer, different shapes of recurring revenue. From low-ticket high-volume streaming to high-ticket B2B SaaS, the same four lanes apply.
Monthly and annual plans, seat-based pricing, mid-cycle upgrades, proration and dunning all run on the same orchestration layer. Network-token recurring authorisations win on approval. Smart retries reduce involuntary churn without a separate dunning vendor.
High-volume, low-ticket renewals are the most cost-sensitive segment of subscription processing. Cost-weighted routing across the connected acquirer set compresses landed cost. Reconciliation rolls up by title, region and subscriber cohort.
Recurring physical-goods subscriptions add inventory and address-change considerations on top of payment. The platform handles the payment side cleanly — vault token + smart retry — so the ops team focuses on fulfilment, not failed renewal queues.
Recurring donations and membership dues benefit from patient retry policies (longer windows, lower per-attempt aggressiveness) and from method-mix that includes account-to-account rails for cost-sensitive donor flows.
Hybrid billing — a recurring base fee plus a metered usage component — runs through one authorisation per billing window with the metered figure read from your own usage feed. Refunds, true-ups and credit notes share the same reconciliation timeline.
Bill-on-fixed-date renewals with a wide method mix (cards, bank rails, top-ups) ride the orchestration layer with per-segment routing policies — minimising involuntary churn on the long tail of saved cards.
Platform features
What the platform actually ships for subscription processing — grouped so an engineering, ops or compliance reader can find the row that matters.
Industry relevance
Recurring revenue spans verticals with very different shapes. The orchestration layer fits where the cost of an extra recovered renewal outweighs the cost of comparing providers against each other.
topropay works with licensed and regulated operators only. Adult, gaming and similar verticals are onboarded where a current operating licence exists in a permitted jurisdiction. Grey and black-market verticals are out of scope.
Trust & compliance
Every renewal runs through a single, audited environment. Merchants integrate as sub-merchants and inherit the platform's PCI DSS, SCA and operational posture rather than carrying separate certifications per provider.
Vault, tokenisation and authorisation paths covered under an annual on-site assessment and quarterly ASV scans. Merchants integrate as sub-merchants and inherit the posture.
Initial mandate captured under 3DS2 with the correct scheme flag. Later renewals run as merchant-initiated transactions inside the exemption framework.
Per-renewal routing decisions return inside the per-authorisation budget — even at peak renewal-cycle volume.
Redundant acquiring zones and automatic failover keep the renewal cycle running through outages, holiday peaks and end-of-quarter spikes.
Billing models
The same orchestration layer runs three billing shapes. The choice of shape sits with the merchant. The routing, recovery and reconciliation work the same way underneath.
The classic monthly or annual renewal on a fixed date. Network-token billing, smart retries on soft declines, account updaters in the background. Most SaaS and consumer subscriptions sit here by default.
Per-window authorisation based on a usage figure read from your own meter feed. The platform handles the authorisation, mandate and reconciliation. The metered figure stays in your system of record.
A fixed base fee plus a metered component on the same renewal — the model most B2B platforms gravitate to. Both components reconcile against one ledger entry per subscriber per billing cycle.
Ready to recover more renewals
Run your renewal cycle against a real routing engine.
A 30-minute review walks through your current approval and recovery curves, the connected acquirers most likely to lift them, and a sandbox to test against before any commercial commitment. Existing billing engine and PSP contracts stay in place.
Frequently asked
The questions buyers actually ask before they commit — covering mandates, recovery, methods, architecture, migration, pricing and compliance.
topropay is the orchestration layer that runs underneath your billing engine. We focus on the authorisation, vault, routing, retry and reconciliation parts of subscription payments — the bits that decide whether a renewal clears, how cleanly it recovers when it doesn't, and how cleanly it lands in finance. The billing logic (plans, proration, invoicing) stays in your billing engine. topropay is the payment side of the stack.
Yes. From your code, the platform looks like a unified payment gateway for subscription billing — one API, one vault, one webhook stream. Underneath, the payment gateway subscription services include connections to multiple acquirers, the routing engine and the reconciliation feed, so what behaves like one gateway is actually a portfolio of connected providers.
Payment and subscription mandates are captured at sign-up under 3DS2 (cards), SEPA mandate flow (SDD), Bacs DDIC (UK direct debit) or NACHA (US ACH). The initial transaction carries the recurring agreement flag so subsequent renewals run as merchant-initiated transactions inside the SCA exemption framework where it applies.
Subscribers can pay subscription fees on a different method by adding it through the merchant's account-management UI — the platform's hosted method-update endpoint captures the new mandate, links it to the same subscription identifier, and the next renewal authorises against the new method. The vault keeps the historical tokens for chargeback evidence. The routing engine uses the current one.
Declined subscription payments go through two layers of recovery. First, in-request cascading: a soft decline from the initial route fails over to the next ranked acquirer inside the same authorisation, before the shopper or your billing system sees an error. Second, scheduled retries: decline-code-aware retry windows replace fixed N-day schedules, learning per-segment what actually recovers.
Yes — both. Visa and Mastercard account updaters run on the platform's cycle, refreshing saved card credentials behind the scenes. Network-token re-issuance flows through the vault, so when an underlying card is replaced, the token stays valid for renewals without merchant-side scripting.
Pay subscription flows are supported on cards (Visa, Mastercard, Amex, Discover, JCB, RuPay via partners), SEPA Direct Debit, Bacs, ACH, Open Banking variable recurring payments where the scheme supports them, and wallet methods that allow recurring (Apple Pay, Google Pay in supported markets). Crypto recurring is available via partner gateways for stablecoin flows.
A subscriber can pay for subscription products via Apple Pay or Google Pay where the underlying card supports recurring mandates. The mandate flows through the wallet's tokenised pay sheet but reconciles against the network token in the platform vault — same recovery, same routing, same reconciliation as a stored card subscription.
A payment subscription system on topropay is one unified API into the vault and routing engine, plus signed webhooks for the lifecycle events (renewal authorised, renewal declined, retry exhausted, token updated, dispute filed). The billing engine reads from those webhooks and schedules the next renewal. The payment side does not need to know about pricing logic.
Yes — the platform behaves like a dedicated subscription gateway from your billing engine's perspective: predictable webhooks, idempotent renewal endpoints, vault-token-keyed identifiers and a reconciliation feed grouped by subscription. The difference from a single-acquirer subscription gateway is that the routing happens across multiple connected acquirers, not just one.
An existing payment gateway subscription book can be migrated through the scheme-native token portability programs (Visa Token Service, Mastercard Digital Enablement). The platform's migration tooling maps your existing tokens to vault tokens, keeps the recurring mandates intact and switches the next renewal onto the orchestration layer without forcing subscribers to re-enter card details.
There is no flat payment gateway subscription monthly fee on the platform itself. Merchants pay per authorisation on top of the underlying provider economics. Interchange and scheme fees pass through where the underlying provider supports it. The platform's fee is a separate, transparent line item. For high-volume merchants, custom routing-policy + price-card combinations are negotiated against measured outcomes.
Payment gateway subscription services are available for licensed and regulated merchants only — including gaming, ticketing, financial services and adult-entertainment where a current operating licence exists in a permitted jurisdiction. Unlicensed grey-market or black-market verticals are out of scope regardless of integration shape.
Recurring SCA exemptions are applied per-transaction based on scheme, country and risk profile. The initial mandate captures under 3DS2 with the correct recurring flag. Renewals run as merchant-initiated transactions where the scheme's exemption framework allows. The routing engine factors exemption eligibility into route ranking so the renewal goes down the route most likely to clear at the lowest friction.
Related