1. Processing payments

The Payment operation is the core of the integration. This guide covers the standard sale; the message rules (ServiceID, transaction IDs, error conditions) are in How the message model works and apply throughout.

The request

A minimal payment carries three blocks:

"PaymentRequest": {
  "PaymentData": {"PaymentType": "Normal"},
  "PaymentTransaction": {"AmountsReq": {"Currency": "EUR", "RequestedAmount": "11.99"}},
  "SaleData": {"OperatorID": "Cashier_01", "SaleTransactionID": {"TimeStamp": "2026-07-06T10:01:00.0+02:00", "TransactionID": "1001"}}
}

PaymentType: Normal is a sale. Other types reuse this same operation — Refund (see Refunding a transaction) and FirstReservation / Completion (see Pre-authorisation).

The response — what to check, in order

  1. Response.Result — Success, Failure, or Partial.
  2. PaymentResult.AmountsResp.AuthorizedAmount — compare with the requested amount. See partial authorisation below.
  3. POIData.POITransactionID — persist it. Required for reversal, refund reference, and status queries.
  4. PaymentResult.OnlineFlag — false means offline approval; record it distinctly.
  5. PaymentReceipt[] — print obligations below.

Partial authorisation

The issuer may approve less than requested: AuthorizedAmount < RequestedAmount. Your POS must detect this, settle the difference by another means (or cancel), and never assume full approval. Treat partial approval as a first-class outcome, not an edge case — certification tests it explicitly, and the feature must be activated at checkout level for it to occur.

Signature

When the response requires a cardholder signature, the receipt data carries RequiredSignatureFlag: true on the relevant receipt. Print the signature line and have the cashier validate — the transaction is not complete for your process until that happens.

Receipts

PaymentReceipt[] contains one entry per document (DocumentQualifier: CashierReceipt, CustomerReceipt) with formatted OutputText lines. Print what the terminal provides — receipt content is certified; do not reconstruct it from other fields. Verify UTF-8 handling end to end: accented characters in receipts are part of certification.

Declines

A declined payment is Result: Failure with ErrorCondition: Refusal and a response code identifying the reason (insufficient funds, expired card, and so on). Display the decline reason to the cashier; never automatically retry a refusal. To exercise every decline path against the Dummy Server, see Testing & certification — Dummy Server rules.

Related

  • Payment features: donation, surcharge, cashback, tip, DCC, multi-store, gift cards.
  • Aborting a transaction: cancelling an in-flight payment.
  • Reversing / Refunding a transaction — undoing a completed one.