Skip to main content
POST
cURL

Authorizations

Authorization
string
header
required

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.

Body

application/json

Request body for POST /v1/transactions/purchase.

Atomic sale: authorise then immediately capture in a single API call. Idempotent via request_id scoped to the authenticated merchant.

amount
MoneyAmount · object
required

Amount to charge for this sale, as a {currency, value} money object.

card
CardToken · object
required

Card group carrying the network token (no raw PAN).

channel
enum<string>
required

Transaction channel -- the source/manner of the payment. Shapes routing candidate selection and the capability/operation constraints applied downstream (acquirer_channel + acquirer_channel_operation gating).

Available options:
CARD_PRESENT,
ECOMMERCE,
MOTO,
PAYMENT_LINK,
IN_APP,
RECURRING
request_id
string
required

Merchant-supplied idempotency key; replays return the original response.

Required string length: 8 - 64
auto_capture
boolean
default:true

Purchase always auto-captures. Must be true (v1).

emv

EMV chip data read from the card, for card-present sales. Send it either as the hex string your terminal produced or as a map of EMV tag to hex value. Omit it for online payments made with a token.

loyalty
LoyaltyRedemptionRequest · object

Redeem loyalty points as part of a purchase.

Include this on a purchase to pay for part (or all) of the sale with loyalty points, optionally naming the pools to draw from and any vouchers to apply. It is accepted on purchase only -- not on authorization or capture -- and the sale must be routed to an acquirer that has a loyalty programme linked, otherwise the request is rejected before any payment is attempted.

metadata
Metadata · object | null

Optional merchant-supplied metadata (max 10 KB, max 5 depth levels).

order_reference
string | null

Merchant's order/cart reference for this payment (common in ecommerce). Stored, searchable via the transaction list filter, and forwarded to the acquirer for reconciliation. Capture/void/refund inherit it from this transaction, so one acquirer-side lookup returns the whole order. Acquirers impose their own limits and character rules (commonly 20 characters, alphanumeric) and will shorten the value to fit, so prefer short references using letters, digits, '-', '.' and '_', and put the varying part LAST -- values are shortened from the front.

Maximum string length: 128
three_ds
ThreeDsPurchaseInput · object | null

3DS result (one of {ref} | {mode:non_payer_auth} | {cavv,...}); absent == non-payer-auth.

Response

Successful Response

Standard success envelope. Every successful response has this shape, with the operation's own payload under data.

data
TransactionResponse · object | null

The operation's result. Its shape is documented per operation; omitted on responses that carry no payload.

message
string | null

Optional human-readable note. Omitted from the response when not set, which is the case for every payment operation today. Never parse it.

request_id
string | null

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.

status
string
default:ok

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.

Last modified on September 15, 2026