NORBr FAQ

Question 1

Who can access the Trust Center?

Accepted Answer

Prospects evaluating NORBr, clients, partners and their auditors or compliance teams. Every access is opened by NORBr; there is no self-service sign-up.

Question 2

What is the difference between RDR, CDRN and Ethoca?

Accepted Answer

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.

Question 3

Can my merchants reach the platform on my own domain?

Accepted Answer

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.

Question 4

How long does access last?

Accepted Answer

Prospects and auditors receive a 7-day invitation. Clients and partners get an account valid two years, then deleted automatically. Access can be reopened on request.

Question 5

Do our merchants see who provides the alerts?

Accepted Answer

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

Question 6

How far does the branding go?

Accepted Answer

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

Question 7

Is NORBr a payment gateway or an acquirer?

Accepted Answer

Neither. NORBr is white-label payment infrastructure that connects and routes the payment providers you activate. Under PCI DSS it is a third-party service provider, listed by Visa as a Merchant Servicer. It does not hold funds or an acquiring licence.

Question 8

What happens when an alert cannot be matched?

Accepted Answer

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

Question 9

Can I tailor the platform navigation to my merchants?

Accepted Answer

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.

Question 10

Can my own auditors or compliance team get access?

Accepted Answer

Yes. Ask your NORBr support team and we send each auditor a personal 7-day invitation on their work email, scoped to the audit period.

Question 11

How do the scope levels map to my organization?

Accepted Answer

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.

Question 12

How often are ASV scans performed?

Accepted Answer

NORBr runs external vulnerability scans every week. Qualys, an Approved Scanning Vendor, certifies the results in line with PCI DSS: quarterly at most, usually monthly. Every certified report is published in the Trust Center as soon as it is issued.

Question 13

Who decides what a program below me can configure on its own?

Accepted Answer

Governance controls sit at the level above. A set of toggles decides whether a program can manage payment partners, create webhook templates, customize hosted payment pages, configure branding and interface options, and customize the menu for the companies and merchant accounts below it. When a toggle stays closed, the corresponding section becomes read-only or hidden, and the configuration remains centrally managed.

Question 14

Can I verify NORBr’s PCI DSS status independently?

Accepted Answer

Yes. Search for “NORBr B.V.” on the Visa Global Registry of Service Providers. The entry lists the validation type, the assessor and the validity date.

Question 15

How do I control access to the production environment?

Accepted Answer

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.

Question 16

What personal data do you keep about Trust Center users?

Accepted Answer

Only your work email address, used to send your access link and to watermark downloads. No password, no name, no company. Accounts are deleted automatically after two years.

Question 17

Can one merchant run several brands inside the same structure?

Accepted Answer

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.

Question 18

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

Accepted Answer

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.

Question 19

What does the activation test check before a contract goes live?

Accepted Answer

The test runs against the staged configuration and returns an execution summary with the provider result. For a network tokenization contract, the available scenarios include a token request, a token status check, a lifecycle event and a cryptogram request, depending on provider support. The test validates the configuration itself, and it creates a payment transaction only when the provider test flow requires one.

Question 20

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

Accepted Answer

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.

Question 21

How are onboarding documents protected?

Accepted Answer

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.

Question 22

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

Accepted Answer

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.

Question 23

Can we use Onboard without the NORBr payment platform?

Accepted Answer

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.

Question 24

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

Accepted Answer

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 and execution leave that contract aside. Every change is written to the audit logs.

Question 25

Where can my merchants explore the full payment method catalogue?

Accepted Answer

A dedicated table lists every payment method available on the platform, selected or not, with its logo and name, its type such as card, wallet, bank transfer or BNPL, its headquarters country, and the countries and currencies it supports. It works as a discovery layer: opening a row leads to the payment method detail, and the breadcrumb returns your merchants to where they started. Selection and configuration remain a separate action, handled inside the contract.

Question 26

What does scheme readiness cover for wallets?

Accepted Answer

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.

Question 27

Who builds the routing rules, my team or my merchants?

Accepted Answer

Each merchant account gets its own Routing Matrix, an ordered set of rules evaluated on every transaction before it reaches a provider. Your merchants build and reorder those rules directly in the Console, on the conditions that match their business. You set the defaults and the boundaries they operate within, which keeps your team available for the cases that deserve attention.

Question 28

Which conditions can a routing rule use?

Accepted Answer

Issuer country, payment method, transaction amount, MCC, BIN and sales channel. A single rule can combine several conditions, and all of them must match for the rule to fire. Rules are ordered, so the first match wins and your merchants keep control of precedence.

Question 29

What happens to routing when a provider contract is revoked?

Accepted Answer

Every contract lists the routing rules that reference it, with the rule conditions, the user who created each one, and the transaction volume each rule sent over the last 30 days. Revocation opens up once those rules are updated or removed, so your merchants keep a working route at every step of the change.

Question 30

What happens after a failed payment attempt?

Accepted Answer

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.

Question 31

Can retry behavior differ by decline reason?

Accepted Answer

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.

Question 32

Do provider outages consume the retry budget?

Accepted Answer

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.

Question 33

How are recurring charges recovered when they fail?

Accepted Answer

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.

Question 34

How does a payment partner review an application?

Accepted Answer

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.

Question 35

How long are documents and audit logs kept?

Accepted Answer

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.

Question 36

Do we have to build our forms from scratch?

Accepted Answer

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.

Question 37

Can our own clients onboard their merchants in the platform?

Accepted Answer

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.

Question 38

Can a subscription plan change while past charges stay untouched?

Accepted Answer

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.

Question 39

What activates network tokenization?

Accepted Answer

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.

Question 40

What happens when a provider handles PANs only?

Accepted Answer

During authorization the platform checks whether a usable network token exists for the payment method. When the selected provider supports network tokens, the transaction carries the token and its cryptogram. When it handles PANs only, the platform falls back to the PAN and the transaction continues. Each transaction records which path it took, so the behavior stays visible in reporting.

Question 41

Do recurring payments survive a card being reissued?

Accepted Answer

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.

Question 42

Which network token fields reach my systems?

Accepted Answer

Order detail and API payloads carry whether a token is associated, whether tokenization was requested, whether the token was used, its expiration month and year, the requestor identifier, the cryptogram and the tokenization partner. These fields appear when they apply, and their values follow provider capability, so integrations should treat them as optional and support the PAN path alongside.

Question 43

How is the impact of tokenization measured?

Accepted Answer

Through the same dashboards and overviews your merchants already use. Dedicated indicators cover network token usage rate, authorized transactions using a network token, transaction success rate on tokenized flows and orders using a network token. Dimensions cover token status, tokenization partner and token expiration data, so a widget combining any indicator with any dimension puts tokenized and non-tokenized performance side by side.

Question 44

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

Accepted Answer

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.

Question 45

Can an endpoint be tested before it goes live?

Accepted Answer

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.

Question 46

What can be shaped in a webhook endpoint?

Accepted Answer

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.

Question 47

Can a delivery be traced after the fact?

Accepted Answer

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.

Question 48

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

Accepted Answer

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.

Question 49

Does the platform decide whether a document is valid?

Accepted Answer

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.

Question 50

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

Accepted Answer

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.

Question 51

What happens if a merchant corrects information after submitting?

Accepted Answer

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.

Question 52

How does Matcher™ match transactions automatically?

Accepted Answer

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.

Question 53

What happens to items that stay unmatched at the end of the day?

Accepted Answer

Two documented paths. Match Later parks a transaction with a reason and a comment while the missing notification is still expected, and it stays visible in the Pending queue until the data arrives. Withdraw removes a transaction from totals and from further matching when a match will never come, and it requires a dedicated permission. Both stay in the logs with timestamp, user and reason.

Question 54

What does Close Out produce?

Accepted Answer

Close Out finalizes matching for a register and locks it against further modification. It generates a summary report showing total revenue, matched transactions, pending matches and withdrawn tickets, the last of which stays visible to authorized users. Registers close one at a time or several at once through multi-selection, which suits centralized operations across many stores.

Question 55

Does matching hold up under a financial audit?

Accepted Answer

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.

Question 56

Does one matching layer cover online and in-store?

Accepted Answer

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.

Question 57

Where do reconciliation files come from?

Accepted Answer

From the provider, retrieved through credentials held in the contract. When a provider requires them, the contract carries a dedicated reconciliation section with the file server host, username and password, the merchant identifier used by that provider for reporting, and the folder path where the files are published. Those values usually sit in the provider back office under settlement or reporting access.

Question 58

Can each merchant shape its own views?

Accepted Answer

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.

Question 59

Can matching and payment data leave the Console?

Accepted Answer

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.

Question 60

How do I see which providers a merchant depends on?

Accepted Answer

Each contract detail shows the routing rules that reference it, the conditions leading to its selection, the user who created each rule and the transactions routed through it over the last 30 days. That view gives you the dependency picture ahead of any lifecycle action, and it surfaces concentration on a single provider early enough to act.

Question 61

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

Accepted Answer

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.

Question 62

Does NORBr act as the merchant of record?

Accepted Answer

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.

Question 63

What stays my responsibility once the infrastructure is in place?

Accepted Answer

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.

Question 64

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

Accepted Answer

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

Still have a question?