Skip to content
API DocsDocs

Checking Payment Status

Check a card transaction's status and retrieve full details — including declineCode on failure

3 min readUpdated Jul 25, 2025

The info endpoint returns a card transaction's current status together with full transaction detailsdeclineCode on failure, card mask, processed amounts, billing details, and more. Use it when:

  • Your webhook was not received (network issue, server downtime)
  • You need to verify status before fulfilling an order
  • You need more than the status — reconciliation, customer support lookup, order history

Prefer webhooks

Polling adds latency and load. Use this endpoint as a fallback, not the primary status mechanism. See Webhook Best Practices for the recommended pattern.

Always use /info — not /status

The /info/{id} endpoint is the only endpoint that returns declineCode. If a transaction is FAILED, /info/{id} tells you why; a status-only response does not.

#Key Response Fields

FieldDescription
transactionIdUnique transaction identifier
requestIdYour original request ID (useful for reconciliation)
transactionStatusCurrent status (SUCCEED, FAILED, PENDING, etc.)
declineCodeDecline code — present when transactionStatus is FAILED
cardMaskMasked card number (e.g. 411111******1111)
cardHolderCardholder name
orderCurrencyCurrency you requested
processedCurrencyCurrency the transaction settled in
orderAmountAmount you requested
processedAmountAmount actually processed (may differ if FX conversion occurred)
conversionRateExchange rate applied, if any

#Status Values

StatusTerminal?Meaning
NEWNoTransaction created, not yet processed
PENDINGNoSent to processor, awaiting result
PROCESSINGNoActively being processed
CUSTOMER_VERIFICATIONNoAwaiting 3DS challenge completion by the customer
SUCCEEDYesPayment successful
FAILEDYesPayment declined or errored — check declineCode
REFUNDEDYesFull refund issued
CHARGEBACKYesChargeback filed by cardholder
CANCELLEDYesTransaction cancelled

Stop polling once you receive a terminal status.

#Polling Strategy

Use exponential backoff starting at ~2 seconds, capping at 30 seconds. Stop after reaching a terminal status or a maximum retry limit. Avoid polling more frequently than every 2 seconds.

Was this helpful?