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.

If the maximum retry limit is reached while the transaction is still PENDING, PROCESSING, or CUSTOMER_VERIFICATION, do not fulfill the order. Keep the order pending, wait for the webhook, and contact support with the transactionId if there is still no final status after your internal timeout.

Was this helpful?