FAQ | NORBr

Platform and branding

Can I tailor the platform navigation to my merchants?

Menu configuration happens once, at your level. You rename entries, reorder them inside their zone and set which ones stay visible, and that configuration applies to every company and merchant account below you, which holds the experience consistent across your whole portfolio. Roles and permissions then determine what each user reaches inside that menu, and a reset action restores the original names and visibility at any time.

Can my merchants reach the platform on my own domain?

Each interface carries two domains, a primary and a secondary, whose labels follow the environment you run: production and sandbox in production, development and staging in development. You point the merchant interface and the admin interface at addresses you own. Your merchants sign in on your address and stay on it through every operation they perform.

Can one merchant run several brands inside the same structure?

Yes. A company groups the merchant accounts that belong to one legal or operational entity, and each brand, market or channel takes its own merchant account underneath. Configuration such as contracts, routing and matching applies per merchant account, while reporting consolidates across the company, so your merchants read each brand separately and the whole picture together.

How do the scope levels map to my organization?

The structure runs from Meta Program Manager to Program Manager, then Companies, then Merchant Accounts. You use the levels that match your model and keep the structure as flat or as deep as your business calls for. Groups let you gather companies or merchant accounts for access control, reporting and configuration inheritance, and TeamSpaces sit on top for the way your teams actually work.

How far does the branding go?

For an exact match with your visual identity, book a demo and explore custom themes with our team.

Providers and payment methods

Can I keep a contract active while excluding it from specific cases?

Exclusion rules act as a restriction layer on top of the contract configuration, and they take precedence over activation status. Supported parameters include amount, authorization currency, IP country, issuer country, issuer, list, merchant data, merchant store ID, sales channel, payment method name and payment method type. When an exclusion rule matches the operational context, routing, orchestration and execution leave that contract aside. Every change is written to the audit logs.

Do recurring payments survive a card being reissued?

When a card expires, is replaced or is reissued, the scheme updates the corresponding network token, and subsequent charges keep running on it. The token captured on the first customer-initiated payment is stored in the NORBr Vault as a universal token, reusable across every provider configured on the merchant account, so each following charge reuses it directly.

How is a new provider or payment method added for a merchant?

A contract links a merchant account to a connector, whether payment, risk, authentication or network tokenization, and carries the credentials, the mapping and the configuration for that connector. Each contract type shows the sections it needs, from connection settings to provider-specific identifiers. Activation validation is specific to the contract type, so the checks run against what that provider actually requires.

What activates network tokenization?

Selecting a supported tokenization partner in the contract configuration. From that point, the linkage between the network token and the existing NORBr Vault token happens at infrastructure level, in real time, for every eligible transaction under that contract. Existing payment data stays where it is, and the API contract stays as it was.

What does scheme readiness cover for wallets?

Apple Pay certificates live at company level, so every merchant account under that company enabling Apple Pay picks them up, and one renewal covers the whole set. Google Pay works from the contract itself: a gateway merchant ID and a merchant name, entered when the method is activated, with the fields appearing at that exact moment. The activation checklist catches a missing value ahead of your merchant.

Routing and recovery

Can a subscription plan change while past charges stay untouched?

A Plan holds the cadence, the amount, the currency, the renewal mode and an optional trial period, and every subscription referencing it inherits those parameters. Updating the Plan carries the change into future occurrences while past occurrences stay as they were recorded. Your merchants define the template once and adjust it as their offer evolves.

Can retry behavior differ by decline reason?

Yes. Each return code represents a specific failure scenario, and the mapping table sets three things per code: whether a retry happens, whether that retry targets the same provider or another one, and how the attempt behaves. The behavior can inherit the previous transaction, carry a challenge preference, or apply an SCA exemption reason such as low value, corporate, trusted beneficiary, risk analysis or delegated authentication. Each row shows whether it holds a default or a custom value.

Do provider outages consume the retry budget?

That is a setting. Counting attempts made during provider downtime holds the total number of retries in check while a provider is unavailable. Leaving them out of the count lets retries resume once the provider comes back. Your merchants choose the behavior that fits their volume and their tolerance.

How are recurring charges recovered when they fail?

A recurring charge follows the same recovery path as any other transaction: the fallback policy already configured for that merchant account applies, with the same return code mapping and the same retry targets. SCA exemption rules already in place cover merchant-initiated charges. Your merchants configure recovery once, and it covers one-off and recurring flows alike.

What happens after a failed payment attempt?

Each merchant account carries its own fallback policy: an active state, a maximum number of attempts including the first one, a maximum number of retries after the initial failure, and a decision on whether attempts made during provider downtime count toward those limits. When the policy is active, the platform retries according to that configuration and the return code mapping defined alongside it.

Matching and reporting

Can each merchant shape its own views?

Views are built from any object table on the platform, covering transactions, orders, contracts, tokens and operations, with the columns, filters and sort order each merchant chooses. Each view carries its own visibility rule, staying private, shared with named colleagues, or opened to a whole team. Saved searches attach to the view they belong to, so a complex filter combination survives the next refresh.

Can matching and payment data leave the Console?

The Payment Partner and Matcher Engine views export to CSV for sharing, archiving or analysis outside the Console, and an audit file covering matching actions can be generated on demand. Exports built from a merchant view carry the column names, field order, file format and filename pattern defined in that view.

Does matching hold up under a financial audit?

Every action is written to an immutable log with its date and timestamp, the transaction or notification identifier, the user who performed it and the action type, whether match, match later, withdraw, discard or close out. Reasons are stored alongside the actions that require them. Logs filter by date range, identifier, status and user action, register closure logs summarize a full period, and an exportable audit file can be generated at any time.

Does one matching layer cover online and in-store?

Matcher™ applies the same logic across the whole account structure. A common omnichannel setup pairs a dedicated e-commerce tree, with one merchant account per country mirroring how the provider itself is organized, alongside the physical store accounts. Flows from several providers at once resolve into one matching layer rather than one process per provider or per market.

How does Matcher™ match transactions automatically?

Through a cascade running from the most precise strategy to the most tolerant. First by reference, when the notification and the transaction share an exact payment identifier. Then by merchant order reference. Then by data, comparing amount, store, payment method and a date window. Then by pairing, when a transaction is offset by an opposite movement such as a sale and a refund of the same amount in the same store. A transaction becomes Matched once the full amount is covered, and stays Pending while part of it remains.

Integration and events

Can a delivery be traced after the fact?

Event detail keeps the core metadata, the last delivery information, the linked order and transaction references, and the request and response payloads in a JSON viewer. The calls list records each attempt with its creation date, result, signature and timestamp. Resent events live in their own view, so a redelivery stays distinguishable from the original.

Can an endpoint be tested before it goes live?

Activation requires one successful test. Your merchants pick a trigger, the platform sends the matching synthetic payload using the exact signing logic of production deliveries, and an HTTP 2xx response confirms the endpoint accepts the request. The result shows the status badge, the full request preview with headers and payload, the response body, and the recent calls with their signatures. The test confirms reachability and acceptance, and business processing inside the receiving system remains yours to validate.

How does my system verify that a webhook came from the platform?

Each delivery is signed. Your receiving system recomputes the signature from the payload, the timestamp and the Merchant Account Secret Key, using the signature algorithm set on the endpoint, then compares the result with the signature header. Supported algorithms run from MD5 and SHA-1 through SHA-256, SHA-384 and SHA-512. Signature verification is the recommended control, and it stays reliable across delivery infrastructure changes.

What can be shaped in a webhook endpoint?

An endpoint carries a name, a target URL and at least one trigger, with triggers grouped by event family across transaction, checkout and batch. Custom headers and payload configuration are available as optional steps at creation. Webhooks subscribe to the payment events the platform produces, which keeps event generation and event delivery as separate concerns.

Launch and support

How does a platform go from configuration to live traffic?

Define the scope structure, apply domains, themes and menus, grant roles, permissions and TeamSpaces, then connect providers through governed contracts and run their activation tests. Production access opens once the program is cleared for live processing. Each step happens in the Console, and the readiness indicators show what remains.

How do I control access to the production environment?

Production access is a dedicated governance toggle held at the level above a program. While it stays closed, that program works in sandbox, which lets a new operator configure its structure, contracts and branding ahead of live traffic. Opening the toggle is the moment live processing becomes available.

How do I tell whether a program is ready to go live?

The program list carries readiness indicators as columns: merchant domain configured, admin domain configured, theme configured, TeamSpaces enabled, contacts count, active API keys, configured webhook endpoints, and the governance permissions in effect. Creation and update timestamps sit alongside, with the user behind each. The picture is available from the table, ahead of opening any single program.

Where does support sit once my platform is live?

Technical documentation for integrators sits on the developer portal. Book a demo to walk through the support model that backs your team.

Commercial model

Does NORBr act as the merchant of record?

No. Market reach comes through the acquirers and local providers certified in the network, and the commercial relationship with each merchant stays yours. You choose which providers your merchants run on, market by market, and the infrastructure carries the flows across them.

How does pricing work?

Our team walks you through pricing during a demo, with your volumes and your growth plans on the table. Book a demo to see the model applied to your platform.

What stays my responsibility once the infrastructure is in place?

The commercial relationship with your merchants, the onboarding decisions you make about them, the pricing you set, the provider relationships you choose to hold directly, and the support you offer under your brand. The infrastructure covers the platform, the connections and the operational surfaces your merchants work in.

Which parts of a payment platform take longest to build in house?

The parts that stay invisible until they are missing. Provider contract management with per-provider credentials and activation tests. Signed event delivery with verification on the receiving side. A matching engine with an immutable audit trail. Role and scope models that hold across a multi-level structure. Certification cycles renewed every year. The API is the visible layer, and it sits on top of all of that.

Onboarding Workflow

Can we use Onboard without the NORBr payment platform?

Yes. It runs standalone, on the acquiring relationships you already hold. If you also run your platform on NORBr, an approved merchant moves into your payment stack carrying the information you already collected, and starts nothing over.

Can our own clients onboard their merchants in the platform?

Yes. You open a program for a client and they run onboarding inside it, under the brand you agreed on, with their own forms, their own payment partners and their own users. Programs stay sealed from one another.

What happens if a merchant corrects information after submitting?

A submitted application locks read-only. Your team reopens it and the merchant corrects it in place, pre-filled. The file your payment partner reviews stays the file you approved, and every change carries an author and a timestamp.

KYB Forms & Questionnaires

Can we adapt the KYB questionnaire to a merchant's industry?

Yes. You build one form per profile, from a shared library of questions. A travel merchant answers on credit risk and delivery horizon, a retail merchant on stock and locations. Adding, hiding or reordering a question happens in the interface.

Do we have to build our forms from scratch?

A set of ready-made onboarding forms comes with the platform, and standard KYB questions sit in the library from day one. You add what your programs require on top, and a client's program can start from the baseline you seeded.

Can we ask different questions before and after qualifying a merchant?

Yes. Prequalification is a short form, a few questions, enough to decide whether the conversation continues. The full KYB follows once you choose to go further. Programs that sign merchants they already know turn prequalification off in settings.

Document Review & Compliance

How are onboarding documents protected?

Every document is encrypted under a managed key, in transit and at rest, and each merchant's files sit in storage reserved for that merchant rather than a shared pool. The data read out of a document carries the same encryption as the document.

How long are documents and audit logs kept?

Each program sets the retention period: 24, 60 or 84 months. When it ends, documents and audit logs are removed automatically, and the removal is logged like every other action. Set the duration that matches the obligations you answer to.

Does the platform decide whether a document is valid?

Content is extracted on upload and expiry dates are checked as a document lands, so an out-of-date identity document surfaces immediately. The decision stays with your reviewer, who approves, challenges with a reason, or attaches the document to the question it answers.

Applications & Partner Sharing

Does a merchant fill in its KYB again for each payment partner?

The merchant completes one KYB. From it you generate one application per payment partner, each carrying the subset of information you chose to share. Submitting to a second partner creates a second application, and the merchant starts nothing over.

How does a payment partner review an application?

Each partner opens the applications you route to it in its own portal, reads what you shared, and asks for anything missing inside the file. The request reaches the merchant, who answers and attaches the document in the same thread.

Can we hide which payment partner a merchant is submitted to?

Yes. Payment partners are configured per program, and programs that keep their acquiring relationships private can hide partner identity from the merchant view. The merchant follows the status of its application, and the relationship stays your commercial asset.

Chargeback Alerts

What is the difference between RDR, CDRN and Ethoca?

RDR is Visa’s automatic resolution: eligible claims on Visa cards are refunded automatically, and are not counted in the chargeback ratio. CDRN (Verifi) and Ethoca (Mastercard) send you an alert, and you have 72 hours to refund before it becomes a chargeback.

Do our merchants see who provides the alerts?

They see Verifi or Ethoca as the source of each alert, inside your branded portal. The NORBr infrastructure behind it stays out of sight.

What happens when an alert cannot be matched?

It stays in the table with a Pending or Not eligible status and all the data the network sent, so your team can investigate.

How are alerts activated for a merchant?

Alerts are switched on per merchant account. From then on, every alert for that account appears in your console.

Frequently

Asked Questions

The best infrastructure is the one your clients