Recurring payment

Recurring payment that survives the card lifecycle — across card, ACH and bank rails.

topropay handles recurring payment processing on cards, ACH and bank rails through one unified API — with network-token-by-default, scheme account updaters, smart retries that cascade across acquirers, and cancel flows that don't burn the customer relationship.

Book a renewals review Explore the platform
Billing cycle · monthly · vault token VT-9421 1 2 3 4 5 6 7 31 32 33 34 35 36 37 61 next 62 63 64 65 66 67 Day 1 · Day 31 · Day 61 — recurring auto-charge on vault token Network token persists across re-issuance · cascade on retry
A cycle that survives card re-issuance and routing changes.
Tokens
network-token-by-default for recurring card
Updaters
scheme account updaters wired in
Cascade
across acquirers on retry
1
ledger for renewals, retries, refunds

Key benefits

Why orchestrated recurring payment processing wins on renewals

Four outcomes that show up consistently once renewals run through the orchestration layer instead of a single-provider recurring stack.

  1. Stop losing renewals to card lifecycle events

    Network tokens persist across card re-issuance; scheme account updaters (Visa VAU, Mastercard ABU) refresh the underlying credentials in the background. The merchant runs renewals against the vault token; the platform handles the rest. Recurring revenue stops bleeding on PAN changes.

  2. Smart retries instead of a fixed schedule

    Soft declines fire into a retry policy that picks the next attempt based on decline reason, scheme behaviour and historical recovery curves — not a hard-coded 'try again in 3 days'. The next attempt may also cascade to a different acquirer if that BIN has been clearing better elsewhere.

  3. Cards and bank rails on the same recurring engine

    Recurring card payment, recurring ACH payment and SEPA Direct Debit all share the same vault, scheduling and webhook model. The merchant's billing system doesn't fork per rail; the platform absorbs the per-rail timing differences.

  4. Cancel flows that don't burn the customer relationship

    Cancel recurring payment requests handle gracefully — programmatic cancel through the API, customer-portal cancel through the hosted page, or operator cancel through the dashboard. Token revocation is immediate; outstanding obligations are settled cleanly.

How it works

From set up recurring payment to a clean cancel — six stages

Six stages between the first authorisation and the final cancellation. Engineering integrates once; the recurring lifecycle runs from the platform.

  1. 01 Token issued

    Set up the recurring payment

    First authorisation captures into the PCI DSS Level 1 vault and issues a network token. The merchant stores the vault-token identifier; PAN data never lands in the merchant's systems.

  2. 02 Cycle policy

    Schedule the cycle

    Define the cycle from the dashboard or the API — monthly, annual, weekly, custom — plus the grace window, retry window and dunning policy per plan. The schedule lives in the platform; the merchant doesn't run cron jobs.

  3. 03 Auto recurring

    Auto-charge on schedule

    Each cycle the platform debits the vault token through the routing engine. Auto recurring payment runs entirely server-to-server; the customer sees a normalised statement descriptor and a receipt.

  4. 04 Cascade

    Cascade on soft decline

    Soft declines cascade to the next ranked acquirer inside the same authorisation. If the cascade also fails, the retry engine schedules the next attempt based on decline-reason heuristics — not a fixed wait.

  5. 05 Updater

    Refresh credentials

    Network tokens and scheme updaters refresh expired or re-issued credentials in the background. Renewals continue without a customer-facing 'update your card' loop unless the underlying account is genuinely closed.

  6. 06 Token revoked

    Cancel or finalise

    When the customer or the merchant cancels, the vault token is revoked and any outstanding obligations (final charge, refund, pro-rata credit) settle through the same API. The ledger closes the customer-lifecycle row cleanly.

Lifecycle anatomy

One subscription customer, six months in

What the platform handles for a single subscription over a typical six-month window — from sign-up through retries, updater events and the eventual cancel.

  1. Day 0

    Sign-up

    First authorisation, vault token issued, schedule starts.

  2. Day 30

    Renewal 1

    Cycle auto-debits via vault token; network token unchanged.

  3. Day 60

    Renewal 2

    Auto-charge clean; statement descriptor normalised.

  4. Day 90

    Retry

    Soft decline; cascade to next acquirer; recovery on the same day.

  5. Day 120

    Updater

    Card re-issued; account-updater refreshes credentials; renewal continues.

  6. Day 180

    Cancel

    Customer cancels via hosted portal; token revoked; final pro-rata settles.

Main use cases

Where automatic recurring payment earns its keep

Six merchant shapes that all run on the same recurring engine — SaaS, memberships, utilities, donor relationships, marketplaces and B2B contracts.

  • 01

    SaaS and software subscriptions

    Monthly or annual SaaS billing on recurring card payment with network-token-by-default. The recurring engine handles renewal recovery so the engineering team stops writing per-provider retry scripts.

  • 02

    Membership and continuity

    Membership clubs, online learning, fitness — long-tail recurring relationships where dunning and account-updater behaviour disproportionately affect lifetime value. The same recurring engine that wins authorisations on month one fights for renewals on month thirty.

  • 03

    Telecom, utility and bill pay

    Recurring ACH payment for utility-style debits with mandate management built in (SEPA Direct Debit mandates, ACH NACHA authorisations). Cycles run on the platform; the merchant's billing system stays focused on usage and invoicing.

  • 04

    Donor relationships and nonprofit

    Recurring donor relationships managed through the same recurring payment systems as commercial subscriptions, with gift-aid metadata preserved and donor-portal cancel flows wired out of the box.

  • 05

    Marketplaces with recurring sellers

    Marketplaces that bill sellers a recurring listing or platform fee, or that handle recurring buyer subscriptions for a seller's plan, run them through the same engine — split-payment routing preserves the per-seller economics.

  • 06

    B2B contracts with renewal terms

    Auto-renewing B2B contracts on cards or bank rails with mandate evidence, renewal-notification webhooks and operator-side controls for negotiated changes.

Cancel & non-recurring

How cancel recurring payment requests are handled

Three valid paths for cancelling a recurring subscription, plus the boundary with non recurring payment — straightforward, audited, and immediate.

  • API

    Programmatic cancel

    A single signed API call cancels the subscription, revokes the vault token, schedules any pro-rata settlement and fires a normalised cancel event into the webhook stream.

  • Portal

    Customer-portal cancel

    A tokenised hosted-portal link lets the customer cancel themselves — useful where the merchant wants to satisfy 'one-click cancel' regulatory requirements without building a portal from scratch.

  • Operator

    Operator-side cancel

    From the merchant dashboard, an authorised operator cancels per customer or in bulk — every cancel logs the operator identity, the reason code and the timestamp for audit.

  • Boundary

    Non recurring payment

    Non recurring payment authorisations share the same vault and reconciliation feed but carry no schedule — they're explicitly one-off in the API. The two shapes co-exist cleanly inside the same merchant account.

Platform features

Capabilities behind recurring payment solutions on the platform

What the platform actually ships for recurring traffic — beyond the general orchestration features shared with one-off authorisations.

  1. Vault tokens by default

    First authorisation captures into PCI DSS L1 vault and issues a vault token. The merchant runs every subsequent charge against the token.

  2. Network tokens

    Network-token-by-default for major schemes (Visa, Mastercard, Amex where supported) — credentials persist across card re-issuance.

  3. Scheme account updaters

    Visa VAU, Mastercard ABU and equivalents wired in; cards refresh in the background, recurring keeps flowing.

  4. Smart-retry engine

    Decline-reason-aware retries — not a fixed schedule. Cascade across acquirers on soft declines inside the same authorisation.

  5. Dunning surface

    Configurable dunning copy, email triggers via webhooks, and customer-portal recovery flows for genuine card-update cases.

  6. Cycle scheduling

    Monthly, annual, weekly, custom — defined per plan; grace windows, retry windows and dunning policies live next to the schedule.

  7. ACH & SEPA recurring

    Recurring ACH payment with NACHA mandate handling; SEPA Direct Debit with mandate lifecycle management; both inside the same API as recurring card.

  8. Cancel API

    Programmatic cancel via the API; customer-portal cancel via the hosted surface; operator cancel via the dashboard. Token revocation is immediate.

  9. Pro-rata & partial captures

    Pro-rata credits, partial captures, plan upgrades and downgrades run via the same vault token through the unified API.

  10. Renewal-event webhooks

    Signed events for authorised / declined / retried / updated / cancelled — drop into your warehouse, CRM or in-house tooling.

  11. Operator portal

    One dashboard for every subscription state across every connected acquirer — auth queue, retry queue, dunning queue, cancel queue.

  12. Sandbox parity

    Sandbox that mirrors production retry behaviour, updater events and cancel flows — test against realistic recurring scenarios.

Trust & compliance

Compliance posture for recurring traffic

Recurring traffic inherits the platform's standard posture, with rail-specific mandate-evidence and updater-event handling layered on top.

PCI DSS Level 1
Annual on-site assessment, quarterly ASV scans; sub-merchants inherit the posture for recurring traffic too.
Network token compliance
Network-token usage logged per authorisation; scheme programme metadata preserved end-to-end.
Mandate evidence (ACH / SEPA)
NACHA authorisation evidence for ACH, SEPA mandate IDs and timestamps captured at sign-up and retained per scheme rules.
SCA on first auth where required
Selective 3DS2 on the first authorisation in EU markets to satisfy the PSD2 'merchant-initiated transaction' downstream pattern.
Cancel-record retention
Cancel events retained with timestamp, source (API / portal / operator) and the user/operator who triggered them — surfaceable for audit.

Ready to ship renewals

Run recurring payment that survives the card lifecycle.

A 30-minute renewals review walks through the recurring engine for your traffic shape — cards, ACH or bank rails — and the cancel surface that satisfies your regulatory bar. Sandbox parity for retry and updater scenarios out of the box.

Book a renewals review Read the API docs

Frequently asked

Buyer questions about recurring payment on topropay

Questions buyers ask before committing — covering set-up, retries, updaters, cancel, non-recurring boundaries and the rail mix behind the recurring engine.

  1. 01

    How does topropay's recurring payment processing differ from a single-provider model?

    Recurring payment processing on a single-provider model runs every renewal through one acquirer's appetite and one retry script. topropay runs renewals through the routing engine — soft declines cascade to the next acquirer, retry timing is decline-reason-aware, and account-updater events refresh credentials across the connected provider portfolio. Net: a measurable uplift on renewal-recovery rate.

  2. 02

    How do I set up recurring payment for a new plan?

    To set up recurring payment for a new plan, define the cycle (monthly / annual / weekly / custom), grace and retry windows, and dunning policy from the dashboard or via the API. The first authorisation captures into the vault and issues a vault token; subsequent charges run server-to-server on the schedule.

  3. 03

    What does recurring card payment look like with network tokens?

    Recurring card payment with network tokens uses the scheme-issued token (not the PAN) for every subsequent authorisation. The token persists across card re-issuance, so the renewal stream keeps flowing even when the underlying card changes. Network-token-by-default is on for every connected acquirer that supports it.

  4. 04

    How does recurring ACH payment work on the platform?

    Recurring ACH payment runs on the same API as recurring card — same scheduling, same webhooks, same operator portal. NACHA mandate evidence is captured at sign-up; the recurring engine handles the per-cycle debit, the NSF / R-code retry calendar and the cancel flow with the same primitives as card recurring.

  5. 05

    What is the difference between auto recurring payment and automatic recurring payment as terms?

    Auto recurring payment and automatic recurring payment are interchangeable in industry usage — both refer to server-to-server scheduled debits initiated by the merchant on the customer's saved token. The platform calls them 'merchant-initiated transactions' (MIT) in the API spec, which is the scheme-standard term.

  6. 06

    Can a customer cancel recurring payment from a customer-facing surface?

    Yes — cancel recurring payment can happen from a customer-facing hosted portal (the platform exposes a tokenised cancel link), via the merchant's own UI (calling the cancel API), or operator-side from the dashboard. All three revoke the vault token immediately and surface a normalised cancel event into the webhook stream.

  7. 07

    What is the difference between recurring and non recurring payment in your data model?

    A non recurring payment is a one-off authorisation — no vault token persistence (unless the merchant explicitly opts in for save-card-for-later), no scheduled re-charge, no scheme-updater eligibility. A recurring payment lives inside a subscription record with a cycle, retry policy and dunning policy attached. Both share the same authorisation engine, vault and reconciliation feed.

  8. 08

    Which recurring payment software primitives does the platform expose for an in-house billing system?

    Recurring payment software primitives include the vault, the cycle scheduler, the retry engine, scheme-updater wiring, the dunning policy engine, the cancel flow and the renewal-event webhook stream. The merchant can call them à la carte from an in-house billing system, or use the platform's hosted scheduler for the whole lifecycle.

  9. 09

    How does it compare to off-the-shelf recurring payment apps?

    Recurring payment apps typically bundle a checkout, a CRM and a billing engine for a specific vertical. topropay is the orchestration layer underneath — merchants who pick a vertical-specific app can still run the payment side through the platform; merchants who want their own billing surface use the API primitives directly.

  10. 10

    What recurring payment solutions are typical for cross-border subscription merchants?

    Cross-border merchants typically combine recurring card with regional bank-rail recurring (SEPA Direct Debit in the EU, Open Banking variable-recurring-payments in the UK, ACH in the US) and route them through the platform's regional acquirer set. The recurring engine treats each rail as a lane on the same authorisation engine.

  11. 11

    Are these recurring payment systems suitable for high-volume merchants?

    Yes — the recurring payment systems behind the platform are sized for high-volume merchants. Cycle scheduling runs server-side at the platform; per-second authorisation throughput is on the same path as one-off authorisations. Operator portal and webhook stream are designed to handle high renewal-event throughput without batching delays.

  12. 12

    How does the platform let merchants accept recurring payment in markets where local bank rails dominate?

    Merchants accept recurring payment in local-bank-rail-dominant markets by enabling the relevant rail per market — SEPA in the EU, Bacs / Open Banking in the UK, PIX / Boleto in BR, OXXO in MX where supported as a recurring rail. The platform handles per-rail mandate evidence and per-rail retry calendars under the same API.

  13. 13

    Is the routing engine doing payment gateway recurring payments specifically?

    Yes — payment gateway recurring payments inside topropay run through the same routing engine as one-off authorisations, with one important difference: the merchant-initiated-transaction (MIT) flag is set on every renewal, so the scheme treats it as an MIT for interchange and dispute purposes. The routing engine takes that into account when picking the route.

  14. 14

    What happens when an account-updater event surfaces during a renewal?

    When an account-updater event surfaces (Visa VAU / Mastercard ABU), the platform updates the vault token's underlying credentials in place and proceeds with the renewal. The merchant sees an updated event in the webhook stream; no customer-facing action is needed. Real card closures (vs re-issuance) still trigger a dunning surface.

  15. 15

    How is reconciliation handled across recurring traffic and one-off authorisations?

    Recurring and one-off authorisations share the same unified reconciliation feed. Settlement, fees, refunds and chargebacks normalise into one ledger keyed off vault tokens, with a recurring-flag column for the row so finance can filter by traffic shape if needed.

Related

Related on the topropay platform