Retrieve a single payment by its unique ID. Only Bearer token authentication is required — this endpoint is not signed.

Read the status from the body, not the HTTP code. A payment that exists always returns 200, whether it succeeded or failed. The outcome is in result.paymentStatus; treating 200 as success will mark declined payments as paid. (404 means no payment with that id.)

The payment is wrapped in a result object.

Which id to use

Fields that depend on status

Reading a decline

On FAILED, errorMessage carries the reason relayed from the payment processor. Numeric processor codes are translated to human-readable text before storage — for example 4004 becomes an insufficient-balance message, 4001 a CVV error, and 4018 "Payment was canceled by the user". Reasons that arrive without a code pass through verbatim, such as "Payment not funded", which means the order was created but never funded.

errorMessage is not guaranteed on every failure. Do not branch on its presence: the reliable "funds were not delivered" signal is paymentStatus: FAILED together with no crypto_tx_hash. Treat errorMessage as a human-readable explanation, not as a machine-readable status.

Field names and types

Two things here are deliberate, not typos — match them exactly:

• Casing is mixed. camelCase for paymentStatus, paymentType, paymentMethod, cryptoAmount, cryptoCurrency, errorMessage and billingAddress; snake_case for crypto_fx, settled_crypto_amount, crypto_tx_hash and destination_wallet (and timezone_type inside created).
• The two crypto amounts have different types. cryptoAmount is a string ("53.36000000") while settled_crypto_amount is a number (53.35). Parse each accordingly rather than assuming one shape.