The engine behind every

recurring charge.

One setup. Every charge, every retry, every token  handled automatically.

NORBr gives each merchant dedicated recurring infrastructure: Plans for cadence, Subscriptions for the customer relationship, and an engine that charges automatically with stable tokens, retries, and your existing routing and fallback rules.

Book a demo
Hero image

What your merchants

never have to ask again.

Once a customer has paid once and consented to recurring charges, the infrastructure takes over. The token is stored. The Plan drives the cadence. Each subsequent order fires automatically, routed through the same logic as any other transaction on the platform.
icône
Re-enter payment details
icône

Reconfirm consent for each charge

icône

Manually trigger each billing cycle

icône

Handle token expiry mid-subscription

icône

Re-route on provider failure

Plans: define the cadence once.
A Plan is the template for a recurring flow. Merchants create it once: cadence, renewal rules, amount, currency. Every Subscription that references it inherits these parameters. Change the Plan, and future occurrences follow the update. Past occurrences are untouched. Trial period Optional, configurable in days

When a charge fails.

The infrastructure handles it.

A recurring charge is a transaction like any other. When it fails, the same fallback logic applies: retry on the same provider, reroute to another, apply the return-code mapping already defined. The SCA exemption rules already configured for the Merchant Account cover MIT charges automatically. Your merchants configure the recovery logic once. It covers all their payment flows, one-off and recurring alike.
Token reuse across occurrences
The token captured on the first CIT payment is stored in the NORBr Vault as a universal token, reusable across every provider configured on the Merchant Account. Every subsequent MIT charge reuses that token directly. No re-authentication. No re-entry. If the card is reissued or expires, NORBr's Network Tokenization layer updates the token automatically when configured, so recurring payments continue without interruption and without re-collecting card data from the customer.
Retry follows the same rules
A failed recurring charge triggers the fallback strategy already in place. Same provider retry, reroute, or stop, based on the return code. The merchant configures recovery logic once. The platform applies it consistently across all transaction types.

Frequently Asked Questions

Can a subscription plan change while past charges stay untouched?

Can retry behavior differ by decline reason?

Do provider outages consume the retry budget?

How are recurring charges recovered when they fail?

What happens after a failed payment attempt?

Set it up once. It runs from there.

Your merchants define the Plan.  NORBr handles every charge, every retry, every token, automatically.

Book a demo