POS QR REST API (1.0)

Verifies HTTP Basic credentials and returns a JWT Bearer token used to authorize the QR API. Pass credentials in the Authorization: Basic [base64_encode(user:password)] header. A merchant identifier mid is REQUIRED in the JSON body (400 without it) — it is baked into the token and all subsequent QR API operations are restricted to that merchant (requests for another merchant or payments of another merchant return 403).

Liveness probe of the Auth API. Returns HTTP 200 with an empty body.

Liveness probe of the QR API. Returns HTTP 200 with an empty body.

Returns the QR payment methods available for the given terminal and currency (bank-specific QR methods and the generic QR transfer), including bank names and logos. For EUR the offer follows the merchant's establishment country (SK → the SK QR method, otherwise the EU QR method); with bothEurQr both SK and EU QR methods are returned. Methods are also filtered by supported amount and instant-payment limits based on the mandatory amount.

Creates a new QR payment. On success it returns the transaction identifier transId and the payment data needed to render the QR code.

Returns the current state of the payment. Poll until status reaches a final value (PAID / CANCELLED).

<span class='cg-lang cg-lang-en'>Rewrites the payment method on an EXISTING pending payment and restarts its expiry, so that going back to the bank list does not create a second payment for one purchase. The response has the same shape as creating a payment, plus the new expiry. Nothing is written until every check passes, so a rejected request leaves the payment usable with its ORIGINAL method - pick another bank and call again. The number of changes is not limited and the expiry is never shortened. Amount limits are not re-checked here: the amount does not change, so the list from /methods still applies.<span class='cg-lang cg-lang-cs'>Přepíše metodu na EXISTUJÍCÍ rozdělané platbě a spustí její expiraci znovu, aby návrat k seznamu bank nevyrobil na jednu útratu druhou platbu. Odpověď má stejný tvar jako založení platby plus novou expiraci. Dokud neprojdou všechny kontroly, nezapisuje se nic, takže po odmítnutí platba dál platí s PŮVODNÍ metodou - stačí vybrat jinou banku a zavolat znovu. Počet změn omezený není a expirace se nikdy nezkrátí. Limity částky se tu znovu nekontrolují: částka se nemění, takže platí seznam ze /methods.<span class='cg-lang cg-lang-sk'>Prepíše metódu na EXISTUJÚCEJ rozrobenej platbe a spustí jej expiráciu znova. Po odmietnutí platba ďalej platí s PÔVODNOU metódou.

Extends the expiration of an unconfirmed payment to 7 days, for the case where the merchant released the goods even though we have not confirmed the payment. The payment stays pending and matchable, so once the money arrives it flips to paid the usual way. The length is a server-side policy and cannot be chosen by the caller. The call is idempotent and never shortens the expiration. A paid payment returns 200 unchanged (the money arrived in the meantime); a cancelled one returns 400 — it is not resurrected, and late money goes through the standard refund process.

Cancels the payment. The response contains the resulting state (CANCELLED).

Creates a refund request for the payment. Only a paid (PAID) payment can be refunded. Both partial and full refunds are possible; the total of all refunds must not exceed the payment amount. The request is processed asynchronously — track the result via GET /pos/qr-api/payment/{transId}/refund/{transRefundId}.

Returns the refund status. Possible states: PENDING (in processing), REFUNDED (money sent back), CANCELLED (refund rejected/cancelled).