Payment flow

Figures below are illustrative. Your own rates are on the pricing page and in your dashboard.

Send the full price you quoted the traveller, markup included. Norba withholds your own commission and tenders the remainder — the airline’s amount — to the carrier. You do not subtract your markup yourself.

Your commission rules live on Commissions in the dashboard. With no rule configured, nothing is withheld and what you send is what the carrier is asked to charge.

Whether a carrier accepts an agency’s own card, and whether it adds a charge for paying that way, is the carrier’s rule and not ours. It differs by carrier and it can change. Check the integration page for the carrier you are selling before you assume a form of payment works, and treat the payment rail as a per-carrier capability rather than something NDC guarantees everywhere.

Sending no card object at all settles the order offline instead — the method string is carried through to the carrier as a settlement remark. See Orders Lifecycle for that path.

Norba never authenticates a cardholder. There is nobody present on a server-to-server booking call to answer a challenge, and the authentication tokens are bound to one transaction — one amount, one merchant, one directory-server exchange — so they can be neither minted here nor reused from another authentication.

That has a consequence worth stating plainly: you cannot authenticate the traveller once on your checkout and reuse those tokens for the carrier’s charge. They are different transactions. This is the main reason the model on this page pays the carrier with your own card rather than the traveller’s — the traveller’s authentication belongs to your charge, at step 1, where their bank can actually challenge them.

The block covers both protocol versions. Version 1 carries xid and cavv_algorithm; version 2 carries ds_transaction_id and channel. The rest — authentication_value, eci, transaction_status — are common to both, whatever the carrier’s own schema happens to call them.

{
  "payment": {
    "method": "CARD",
    "currency": "EUR",
    "amount": 550.00,
    "card": {
      "number": "4111111111111111",
      "holder": "Acme Travel SL",
      "expiry_month": 11,
      "expiry_year": 2030,
      "brand": "VISA"
    },
    "authentication": {
      "version": "2",
      "authentication_value": "AAACBhZHkQICA0kAMkeREMAAAgE=",
      "eci": "05",
      "transaction_status": "Y",
      "ds_transaction_id": "9682ed54-9bba-4f33-8e44-0f6f9dfdc9f2"
    }
  }
}

Whether a carrier accepts an agency card, exempts a commercial one, or requires the tokens is per carrier and can change — check its integration page. The cryptogram and the xid are credentials: they are redacted from request logs and never persisted. The status codes beside them are not, because they are what a disputed authentication is traced with.

The carrier can accept an order and still fail to issue the document. Until the API returns a ticketed status and at least one ticket number, no ticket exists, and you should not tell the traveller otherwise or treat the sale as complete.

{
  "order_id": "AA001U8DY61A3",
  "pnr": "KBKYAY",
  "status": "confirmed",
  "total_amount": 500.00,
  "currency": "EUR",
  "ticket_numbers": ["0012386549871"]
}

A timeout is not an answer either: read the order back before retrying, and use an idempotency key on every write. Retrying a booking blind is how duplicate tickets — and the debit memos that follow them — get made.

Everything we accrued against your account through the month — the share of each confirmed booking, each seat and extra sold, each servicing operation, and your metered requests beyond the free allowance — is totalled into one invoice and charged to the card on your account. Sandbox activity is metered but raises no booking fee, because a sandbox booking is not a sale.

The mechanics of that invoice, the standing checks that gate a booking on having a card on file, and what happens when one goes unpaid are all on Billing & Payments.