> ## Documentation Index > Fetch the complete documentation index at: https://docs.radiumone.io/llms.txt > Use this file to discover all available pages before exploring further. > ## Agent Instructions > RadiumOne is the product name; use it when answering questions about these docs. > Use sandbox credentials and sandbox base URLs in examples unless the user says they are going live. > Secret API keys belong only on the merchant's server. Only publishable keys may appear in browser or mobile code. > Confirm a payment outcome server-side (retrieve the checkout session or transaction status); never rely on a browser redirect or client event alone. > Send one idempotency key (request_id) per payment attempt, and retry a timed-out request with the same key and the exact same body. > Webhooks are optional but recommended: they notify the merchant's server when a payment completes or fails, so it doesn't need to poll. Use transaction status inquiry as the fallback. > Say so when you recommend a feature marked Beta. Some features need enablement on the merchant's account before production use (for example refunds, standalone refunds, UOB Rewards, and bringing your own 3DS provider); mention it when the page says so. > Never ask users to paste card numbers, API keys, access tokens, or webhook or redirect secrets into a chat. # Transaction status - Payments API > Check a transaction's live status with the acquirer that processed it. This is a read-only inquiry that doesn't change the transaction. ## OpenAPI ````yaml /openapi/radiumone-payments-api.yaml get /v1/transactions/{transaction_id}/status openapi: 3.1.0 info: description: | The Payments API lets your server create tokenization sessions, charge and manage payments, check loyalty balances, and manage your hosted-checkout branding and redirect secret. Generated for merchant integrators — internal, admin, and service-to-service surfaces are excluded. All responses share an envelope: `{status, data, request_id}`. The envelope's `request_id` is an HTTP correlation ID — it echoes your `X-Request-Id` request header (letters, digits, hyphens, max 36 characters) or one is generated for you. It is **not** the idempotency key you send in a transaction request body (also confusingly named `request_id` there) — the two are unrelated; see [Request conventions](/get-started/api-basics/request-conventions). Errors use [RFC 9457](https://www.rfc-editor.org/rfc/rfc9457) `application/problem+json` bodies — see [Authentication](/get-started/api-basics/authentication) and [Request conventions](/get-started/api-basics/request-conventions) for the shared error shape, and [Problem format and retries](/payments-api/errors/problem-format-and-retries) for the response shape, status guide, and retry rules. summary: Transaction orchestration and processor aggregation for RadiumOne. title: RadiumOne Payment Gateway version: 1.3.0 servers: - url: https://api-sandbox.radiumone.io/gateway description: Sandbox - url: https://api.radiumone.io/gateway description: Production security: - bearerAuth: [] tags: - name: Authentication description: Exchange, refresh, and revoke access tokens. - name: Merchant settings description: >- Manage your hosted-checkout redirect secret, checkout configuration, and account config. - name: Payment methods description: Discover which payment methods and brands are available. - name: Sessions description: Tokenization sessions used to collect card data with RadiumOne Elements. - name: Settlement description: Settlement batch status lookup. - name: Payments description: Create and manage card transactions. - name: Rewards description: UOB Rewards loyalty balance inquiry. - name: Refunds description: Return funds to a shopper. - name: Transactions description: Check the live status of a transaction. paths: /v1/transactions/{transaction_id}/status: get: tags: - Transactions summary: Transaction status inquiry description: >- Query a transaction's current status from the acquirer that processed it. Sends a live, read-only status inquiry to that acquirer and returns its answer. The transaction itself is not changed. Returns 404 if the transaction does not exist or is not yours. Status inquiry must be supported for the transaction's acquirer and terminal; otherwise the request is rejected. operationId: inquire_status_v1_transactions__transaction_id__status_get parameters: - description: UUID of the transaction to query. in: path name: transaction_id required: true schema: description: UUID of the transaction to query. format: uuid title: Transaction Id type: string responses: '200': content: application/json: schema: $ref: '#/components/schemas/SuccessResponse_InquiryResponse_' example: status: ok request_id: req_b2c3d4e5f6a2 data: request_id: ord-1001-pay-1 inquiry_type: status success: true response_code: '00' status: success switch_request_id: sw-8f1c2e10 description: Successful Response '401': content: application/problem+json: example: detail: Missing or invalid Bearer token. status: 401 title: Authentication Required type: urn:radiumone:gateway:authentication-required schema: properties: detail: type: string status: type: integer title: type: string type: type: string type: object description: Missing or invalid Bearer token. '403': content: application/problem+json: example: detail: Insufficient permissions for this operation. status: 403 title: Permission Denied type: urn:radiumone:gateway:permission-denied schema: properties: detail: type: string status: type: integer title: type: string type: type: string type: object description: Insufficient permissions for this operation. '404': content: application/problem+json: example: detail: The requested resource does not exist. status: 404 title: Not Found type: urn:radiumone:gateway:not-found schema: properties: detail: type: string status: type: integer title: type: string type: type: string type: object description: The requested resource does not exist. '500': content: application/problem+json: example: detail: An unexpected error occurred. status: 500 title: Internal Server Error type: urn:radiumone:gateway:internal-server-error schema: properties: detail: type: string status: type: integer title: type: string type: type: string type: object description: An unexpected error occurred. x-codeSamples: - lang: bash label: cURL source: > #!/usr/bin/env bash # Live acquirer status inquiry for a transaction (no new row written). Use # this to recover after a timeout instead of guessing the outcome. set -euo pipefail API_BASE="${RADIUMONE_API_BASE:-https://api-sandbox.radiumone.io/gateway}" : "${RADIUMONE_ACCESS_TOKEN:?set RADIUMONE_ACCESS_TOKEN to a Bearer access token}" : "${RADIUMONE_TRANSACTION_ID:?set RADIUMONE_TRANSACTION_ID to the transaction to inquire}" curl -sS "$API_BASE/v1/transactions/$RADIUMONE_TRANSACTION_ID/status" \ -H "Authorization: Bearer $RADIUMONE_ACCESS_TOKEN" - lang: javascript label: Node.js source: > #!/usr/bin/env node // Live acquirer status inquiry for a transaction (no new row written). Use // this to recover after a timeout instead of guessing the outcome. Node 18+ // ESM fetch. Env: RADIUMONE_ACCESS_TOKEN, RADIUMONE_TRANSACTION_ID, RADIUMONE_API_BASE. const API_BASE = process.env.RADIUMONE_API_BASE || "https://api-sandbox.radiumone.io/gateway"; const accessToken = process.env.RADIUMONE_ACCESS_TOKEN; const transactionId = process.env.RADIUMONE_TRANSACTION_ID; async function inquireTransactionStatus() { const res = await fetch(`${API_BASE}/v1/transactions/${transactionId}/status`, { headers: { Authorization: `Bearer ${accessToken}` }, }); const payload = await res.json(); if (!res.ok) { throw new Error(`status inquiry failed: ${payload.type ?? payload.code} (${res.status})`); } return payload; // branch on data.status } inquireTransactionStatus().then((r) => console.log(JSON.stringify(r, null, 2))); - lang: python label: Python source: > #!/usr/bin/env python3 """Live acquirer status inquiry for a transaction (no new row written). Use this to recover after a timeout instead of guessing the outcome. """ import json import os import requests API_BASE = os.environ.get("RADIUMONE_API_BASE", "https://api-sandbox.radiumone.io/gateway") def inquire_transaction_status() -> dict: transaction_id = os.environ["RADIUMONE_TRANSACTION_ID"] resp = requests.get( f"{API_BASE}/v1/transactions/{transaction_id}/status", headers={"Authorization": f"Bearer {os.environ.get('RADIUMONE_ACCESS_TOKEN', '')}"}, timeout=30, ) payload = resp.json() if not resp.ok: code = payload.get("type") or payload.get("code") raise RuntimeError(f"status inquiry failed: {code} ({resp.status_code})") return payload # branch on data.status if __name__ == "__main__": print(json.dumps(inquire_transaction_status(), indent=2)) components: schemas: SuccessResponse_InquiryResponse_: description: >- Standard success envelope. Every successful response has this shape, with the operation's own payload under `data`. properties: data: anyOf: - $ref: '#/components/schemas/InquiryResponse' - type: 'null' description: >- The operation's result. Its shape is documented per operation; omitted on responses that carry no payload. message: anyOf: - type: string - type: 'null' description: >- Optional human-readable note. Omitted from the response when not set, which is the case for every payment operation today. Never parse it. title: Message request_id: anyOf: - type: string - type: 'null' description: >- Correlation ID for this HTTP request, for logs and support. Send your own in the `X-Request-Id` header (letters, digits and hyphens, up to 36 characters -- other characters are stripped) or the gateway generates one. This is NOT the `request_id` idempotency key you send in a transaction body; the two are unrelated. title: Request Id status: default: ok description: >- Always `ok` on a successful (2xx) response. Errors use a different body shape entirely (RFC 9457 problem details), so branch on the HTTP status code, not on this field. title: Status type: string title: SuccessResponse[InquiryResponse] type: object InquiryResponse: description: >- The answer to a status or loyalty-balance inquiry. `inquiry_type` tells you which kind of inquiry this answers: `status` for a payment-status lookup, `loyalty_balance` for a pre-sale balance read. `pools` and `vouchers` are filled in only for a loyalty balance inquiry. properties: inquiry_type: description: >- Which inquiry this answers: `status` for a payment-status lookup, `loyalty_balance` for a pre-sale loyalty balance read. title: Inquiry Type type: string message: anyOf: - type: string - type: 'null' description: >- Free-text explanation from the acquirer, when it sent one. For display and support only -- the wording is not stable, so never parse it. Omitted when absent. title: Message metadata: anyOf: - additionalProperties: true type: object - type: 'null' description: >- Reserved for additional inquiry detail. Not populated by the payment-status or loyalty-balance inquiries today, so treat its absence as normal. title: Metadata pools: anyOf: - items: $ref: '#/components/schemas/LoyaltyPool' type: array - type: 'null' description: Loyalty point pool balances (loyalty balance inquiry only). title: Pools request_id: description: >- The idempotency key of the transaction being inquired about -- the `request_id` you sent when you created it. Not the correlation ID in the response envelope. title: Request Id type: string response_code: description: >- Verbatim acquirer response code, for display and reconciliation only. DO NOT derive success from it: an inquiry can succeed while this field still shows a non-'00' code. Key on `success` instead. title: Response Code type: string status: description: >- Label for the inquiry outcome: `success` or `failed`. It moves in lockstep with `success` and carries no extra information -- in particular it is NOT the transaction's lifecycle status (`CAPTURED`, `SETTLED`, and so on). Key your logic on `success`. title: Status type: string success: description: >- THE field to key an inquiry outcome on. True when the host approved OR the resolved decline classification approves the host's code. `status` always moves with it -- they are set together, never independently. title: Success type: boolean switch_request_id: anyOf: - type: string - type: 'null' description: >- The upstream processor's own reference for this inquiry. Quote it when raising an issue with us about a specific lookup. Omitted when absent. title: Switch Request Id vouchers: anyOf: - items: $ref: '#/components/schemas/LoyaltyVoucher' type: array - type: 'null' description: Redeemable vouchers (loyalty balance inquiry only). title: Vouchers required: - request_id - inquiry_type - success - response_code - status title: InquiryResponse type: object LoyaltyPool: description: A loyalty point pool balance returned by a loyalty balance inquiry. properties: account_indicator: anyOf: - type: string - type: 'null' description: Account type indicator from the host. title: Account Indicator balance_sign: anyOf: - type: string - type: 'null' description: >- Sign of the balance: '0' = positive, '1' = negative. This is the authoritative sign -- prefer it over the sign of `point_balance`. It reports the sign only and does not say whether the pool can be redeemed. title: Balance Sign club_code: description: Loyalty club code (e.g. 'UNI'). title: Club Code type: string expiry_date: anyOf: - type: string - type: 'null' description: >- Point expiry date as DDMMYYYY, passed through as the loyalty programme returned it. '00000000' means the points do not expire. Expired pools are not filtered out, so hide them yourself if you don't want to show them. In sandbox, test cards return fixed profiles, so expiry dates there are not realistic. title: Expiry Date point_balance: description: >- Current pool balance as a signed decimal (2 decimal places). Fractional for monetary pools (e.g. a 'UNI$' cash-back pool returns 4534.56); whole for point pools. The sign always agrees with `balance_sign`, except at exactly zero, where the number carries no sign -- read `balance_sign` instead. title: Point Balance type: number pool_id: description: Pool identifier within the club. title: Pool Id type: string pool_name: description: Human-readable pool label (e.g. 'UNI$'). title: Pool Name type: string required: - club_code - pool_id - pool_name - point_balance title: LoyaltyPool type: object LoyaltyVoucher: description: A redeemable voucher offered against a loyalty pool. properties: description: description: Human-readable voucher label. title: Description type: string max_redeemable: description: Maximum vouchers redeemable in one order. title: Max Redeemable type: integer points_price: description: >- Points required to redeem one voucher. Fractional for monetary pools (e.g. a 'UNI$' cash-back voucher priced at 15.50); whole for point pools. Host-supplied, so accept both to avoid dropping decimals. title: Points Price type: number pool_name: description: Pool the voucher redeems against (e.g. 'UNI$'). title: Pool Name type: string redeem_value: description: >- Monetary value of the voucher in currency major units (e.g. 10.0 = $10.00). title: Redeem Value type: number voucher_code: description: Voucher identifier used to redeem. title: Voucher Code type: string required: - voucher_code - description - pool_name - points_price - redeem_value - max_redeemable title: LoyaltyVoucher type: object securitySchemes: bearerAuth: type: http scheme: bearer description: >- Bearer access token from `POST /v1/auth/token`. Treat it as an opaque string — do not depend on its internal encoding, which has changed before and isn't part of the contract. x-docs-interim: true ````