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?

Branding runs on themes, which are bundles of design tokens covering colors, typography and interface styling, applied alongside your logo. A theme propagates from your workspace to every company and merchant account that inherits from it, and saving a new one shows you that scope before it applies. Custom themes are available on request when you want an exact match with your visual identity.

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?

Your merchants reach your team under your brand, and your team holds the tools to answer most of what reaches them: contract detail, routing dependencies, fallback configuration, event delivery history with request and response payloads, and matching logs. Technical documentation for integrators sits on the developer portal, and your own escalation path to NORBr covers the infrastructure layer underneath.

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 is the subscription priced?

Through a flat monthly subscription. The amount stays the same as your volume grows, which leaves the margin on each additional transaction with you.

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.

Frequently

Asked Questions