Confirm an online-gateway top-up: credit wallet + accrue reload bonus
Confirms a paid online-gateway top-up session and credits the customer’s wallet, the second step of the two-step online top-up flow. On confirmation, the customer’s cashable balance is credited and any configured reload bonus is accrued as a promotional grant in the same atomic operation, so the two effects either both apply or neither does.
The credited amount is server-authoritative: it is derived from the finalized provider settlement event, never from POS-submitted totals.
The cashable credit (balance) is the customer’s actual, spendable money. The reload bonus is accrued as a RELEASED promotional grant: promotional balance that can expire and is never cashable. Because the customer is already identified at top-up time, the gateway reload bonus accrues directly to RELEASED with no register-to-claim gate.
This endpoint credits exactly once. Confirmation flips the deposit transaction from PENDING to COMPLETED atomically, so concurrent confirmations (for example a duplicate provider webhook and a partner poll arriving together) still credit a single time. Idempotency is enforced on two axes: the Idempotency-Key header and, defensively, the provider settlement reference (provider_payment_ref). A fresh partner_request_id that reuses a prior Idempotency-Key replays the original credit without double-crediting. A reused Idempotency-Key paired with a different request payload returns IDEMPOTENCY_KEY_REUSED.
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
Body for POST /topup/confirm. Idempotent on the Idempotency-Key header and defensively on provider_payment_ref.
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.
Provider that processed the charge.
SADAD, STRIPE The provider's settled payment reference (Stripe PaymentIntent id / Sadad trans_no). Secondary idempotency anchor.
3"QAR"
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.
The prepared provider session reference.
Expected amount; the credited amount is derived server-side from the finalized provider event and reconciled against this.
x >= 1Response
Wallet credited (or idempotent replay of a prior credit). meta.idempotency_replayed is true on a replay.
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.
Result of a completed top-up credit (confirm or SKU sale). Carries both money classes after the credit.
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.