Mint a rotating QR / short-code for the customer's wallet app
Generates a rotating, single-use QR nonce (and optional 5-character short code) for the customer to display at the point of sale. The nonce is bound to the customer’s wallet identity and has a 5-minute TTL. The point of sale then submits the nonce to POST /payments as credential.type: qr, or submits the alphanumeric variant as credential.type: short_code.
The underlying QR session uses compare-and-swap status transitions: presenting a QR at the point of sale while a new mint is requested concurrently will not cancel the in-flight payment, and the presented nonce remains valid. Re-minting before the TTL expires returns a new nonce and invalidates the previous one.
Requests are idempotent on the Idempotency-Key header: a retried mint with the same key returns the same nonce while it remains within its TTL. The endpoint is terminal-scoped and can be driven by either the point-of-sale app or the customer’s wallet app. A request scoped to a different tenant returns 403 or 404.
Authorizations
POS terminal JWT minted by /auth/token; carries integrationId + terminal/cashier claims (server-trusted).
Headers
Partner-generated UUID; the ONE dedup key for all mutating endpoints. 24h TTL. Same key + same payload -> byte-identical replay; same key + different payload -> IDEMPOTENCY_KEY_REUSED (422).
Body
Common request metadata shared across all Partner API domains. partner_request_id is a correlation identifier only: it appears in logs and responses for tracing but is never used as the deduplication key. Request deduplication is keyed exclusively on the Idempotency-Key header.
Canonical request context, shared across all partner domains. merchant_id is key-enforced to a merchant the calling credential is authorized for (a platform-scoped credential acts only on its own tenants), so it is never a free-text trust field: a merchant_id outside the credential's authority is rejected rather than honored.
If true, also generate a 5-char alphanumeric short-code alongside the QR payload.
Disambiguate for multi-program customers.
Response
QR nonce minted. Render qr_payload as a QR code and optionally display short_code for manual entry.
The standard response envelope that every enveloped endpoint serializes through. ok is a boolean discriminator: when ok is true, the typed result is carried in data; when ok is false, a typed error object is returned instead. The meta object is uniform across the entire API surface.
The uniform response metadata block returned on every response. data_completeness_score is computed per call and reports the completeness of the returned data. decision_trace_id is present on responses that carry decision or insight output and can be used to correlate the response with its reasoning. capabilities is an additive, response-level array of hints advertising features the caller may use, and may be extended over time without notice.
The typed error object returned with every non-2xx response. code is a string enum (for example WALLET_PROGRAM_AMBIGUOUS, CREDENTIAL_TYPE_UNSUPPORTED, INSUFFICIENT_FUNDS, IDEMPOTENCY_KEY_REUSED, CURRENCY_NOT_SUPPORTED), never a bare HTTP status number. Inspect code for programmatic branching, not the HTTP status. Some codes echo the valid set in details so clients can present or reconcile the accepted values: for example CREDENTIAL_TYPE_UNSUPPORTED lists the supported credential types, CURRENCY_NOT_SUPPORTED lists the supported ISO-4217 currencies, and WALLET_PROGRAM_AMBIGUOUS lists the candidate wallet_program_id values that matched the request.