1. Taking a payment

The core operation: POST /process-transaction/PAX:{serialNumber}?waitTime=N with transactionType: "PURCHASE".

The request

{
  "transactionType": "PURCHASE",
  "amount": 1199,
  "currency": "EUR",
  "ecrTransactionId": "SALE-2026-07-06-0042",
  "cashierId": "Cashier01",
  "ecrParams": {"ecrId": "ECR-001", "notificationUrl": "https://ecr.example.com/callback", "printerAvailable": true, "operatorLanguage": "EN"}
}

Field rules that bite: ecrTransactionId and cashierId are ≤ 35 characters (UUIDs are 36 — see Troubleshooting: response code 90001); the amount format and full field contract are in the ecr-api specification on api-hub.

The response — what to check, in order

  1. status — OK, NOK (read responseCode), or PARTIAL.
  2. terminalTransactionId — persist it; cancellation requires it.
  3. Authorised amount on PARTIAL — the response carries the approved amount; your POS settles the difference by other means or cancels. Treat partial approval as a first-class outcome.
  4. Receipts / cardholder data per the specification — print what is returned.

The HTTP code is not the outcome — 200/201 accompanies declines too.

If the synchronous window expires

A transaction that outlasts waitTime completes on the terminal regardless. The result reaches you on the webhook, or via Checking the last transaction. Never re-send the payment — the platform and terminal do not deduplicate, and a re-send is a second charge.

Related

  • Payment features and conditional capabilities apply per your configuration — confirm scope with Market Pay; the Nexo-side feature descriptions in the Local API section describe terminal behaviour (donation prompts, surcharge on receipts) that is method-independent.
  • Aborting / Reversing a transaction (Cloud API) — stopping or undoing.