Accept more.

Configure once.

Every merchant has a different stack. One configuration surface covers all of them.

Provider, methods, channels. NORBr gives you one surface to configure each merchant's stack precisely, test it before it goes live, and activate with confidence. What you configure is exactly what your merchant sees in production.

Book a demo
Hero image
Configure precisely. Activate with confidence.
Connecting a provider takes minutes. Configuring it correctly is what takes judgment. For each provider contract on a Merchant Account, you decide which payment methods are active, on which sales channels, in which currencies. You add exclusion rules when a contract should not apply in a specific context. What you configure here is exactly what your merchant can accept at checkout. No gap between configuration and reality.
The methods your merchant actually needs
Enable the methods the provider supports, one by one.  Assign sales channels to each: e-commerce, recurring, MOTO, POS. Set the authorization currencies. Each method is configured independently, so a merchant running both online and in-store gets exactly the right setup for each context.
Exclusion rules that protect your routing
Some contracts should not apply in every context. A provider that doesn't cover a specific country. A method that shouldn't trigger on transactions above a certain amount. Exclusion rules let you define exactly when a contract steps aside. The contract stays active. It just doesn't apply where it shouldn't.
Advanced services, linked where they belong
Authentication, risk assessment and network tokenization are configured as separate provider contracts and linked at the payment contract level. Each service keeps its own configuration. You choose which authentication provider covers which payment contract, which risk provider scores which flow. The connections are explicit. Nothing is assumed.
Deactivate without breaking history
Need to take a contract offline? Deactivate it. Transactions already processed against it remain fully visible. The configuration is preserved. Reactivate when you're ready. Nothing is lost, nothing breaks downstream.
Test before you activate. Always.
A contract in Draft is a contract that still needs to prove itself. Before anything goes live on a Merchant Account, the platform runs a test against the actual staged configuration. Not a simulation. A real test, against the real provider, with real results. If it fails, you know before your merchant does.
A test built for what the contract actually does
Each contract type gets its own test. A payment contract runs a test checkout: it creates an order, a transaction, a provider response. An authentication contract tests the 3DS flow. A risk contract tests the scoring output. A network tokenization contract tests the token request. The test matches the contract. The result tells you exactly what's working and what isn't.
Activate straight from the result
When a test succeeds, activation is one click away. The result modal surfaces the "Activate contract" CTA directly. No back-and-forth. No second screen. The test validates, the activation follows. If something blocks activation, a missing certificate, an unconfigured currency, it's listed explicitly before you confirm.
Know what blocks you before it blocks your merchant
Activation has prerequisites. Missing credentials, no payment method enabled, an Apple Pay certificate not yet linked. Every blocking issue surfaces explicitly before you try to activate. Each item is named. Nothing is vague. You fix what needs fixing, you run the test again, you activate.

Your merchants stay autonomous.  You stay in control.

Your merchants will ask: "Why is this method not processing in GBP?”, “Why can't we add recurring on this contract?", "Why is Wero not working for this currency?" The answer is always in the configuration. NORBr makes it readable at a glance, for you and for them. The payment methods view gives every merchant a clear picture of what they can accept right now, and flags what isn't working before they have to ask.

No support ticket for a configuration question
Your merchants can see their own payment stack without contacting you. Every active method, every sales channel, every currency, in one consolidated view. When something is misconfigured or inactive, it's visible there, not in an error log three days later. You spend less time explaining. They spend less time waiting. The gap between "it should work" and "it does work" closes before it becomes a conversation.
Catch it before your merchant does
A method available but not enabled. A contract active on one channel but not another. A currency gap that will surface at checkout. NORBr surfaces these states before your merchant hits them. You see what's configured, what's available but inactive, and what's missing. You fix it once. It propagates immediately. Your merchant never knows there was a gap.
The complexity is ours. The uptime is yours.
Certificate management is one of those things that runs silently until it doesn't. An expired merchant certificate takes Apple Pay offline. A missing Google Pay gateway ID blocks the method at checkout. Your merchant notices before you do. NORBr handles the certificate lifecycle centrally, so the problem never reaches your merchants in the first place.
Apple Pay without the certificate overhead
Apple Pay requires two certificates: a Merchant Certificate to validate your domain with Apple's servers, and a Payment Processing Certificate to decrypt payment tokens. Each has its own lifecycle. Each needs renewal. For a PSP running hundreds of merchants, managing this per contract is not an option. NORBr is a certified Apple Pay platform. You configure both certificates once at the Company level, validate the domain once, and every Merchant Account under that Company that enables Apple Pay picks them up automatically. One renewal covers everyone.
Google Pay, ready in the contract.
Google Pay doesn't need a certificate exchange. It needs a gateway merchant ID and a merchant name, entered directly in the contract when Google Pay is enabled as a payment method. No separate setup screen. No back-and-forth with your team. The fields appear at the right moment, inside the contract, when the method is activated. Fill them in, run the test, activate. If something's missing, the activation checklist catches it before your merchant does.
Better auth rates. Zero integration work.
Scheme tokens outperform PANs on every metric that matters. Higher auth rates. Fewer declines on expired cards. Lower fraud exposure. Activated at the contract level. No API change required.
Activate on the contract. Everything else is automatic.
Network tokenization is configured in the Advanced settings of a payment contract. Select the tokenization provider. Confirm the supported card networks. Activate. From that point, every eligible transaction on that Merchant Account uses a scheme token automatically. If the token is unavailable, the platform falls back to PAN without interrupting the transaction. Silent. Logged. Your merchants never know. Your auth rates do. The full performance impact of network tokenization is covered in Payment Intelligence.

Your merchants accept more.  
Your stack is always ready.

Contracts configured precisely. Tested before they go live. Certified infrastructure behind every transaction.

Book a demo