Skip to main content
Understanding the transaction lifecycle helps you build robust payment flows, handle edge cases, and provide accurate status updates to your customers.

Transaction States

Transactions progress through several states from creation to completion:

Status Descriptions

Terminal statuses: COMPLETED, FAILED, EXPIREDOnce a transaction reaches a terminal status, it will not change further.

Outgoing Transaction Flow

Your customer/platform sends funds to an external recipient.

Step-by-Step

1

Create Quote

Lock in exchange rate and fees:
Response:
  • Quote ID
  • Locked exchange rate
  • Expiration time (1-5 minutes)
2

Execute Quote

Initiate the payment:
Result:
  • Transaction created with status PENDING
  • Source account debited immediately
  • OUTGOING_PAYMENT webhook sent
3

Processing

Grid handles:
  • Currency conversion (if applicable)
  • Routing to appropriate payment rail
  • Settlement with destination bank/wallet
Status: PROCESSINGWebhook: OUTGOING_PAYMENT with updated status
4

Completion or Failure

Success Path:
  • Funds delivered to recipient
  • Status: COMPLETED
  • settledAt timestamp populated
  • Final OUTGOING_PAYMENT webhook sent
Failure Path:
  • Delivery failed (invalid account, etc.)
  • Status: FAILED
  • failureReason populated
  • Funds automatically refunded to source account
  • Final OUTGOING_PAYMENT webhook sent
Most transactions on Grid are completed in seconds.

Webhook Payloads

On Creation (PENDING):
On Completion:
On Failure:

Same-Currency Transfers

For same-currency transfers without quotes:

Transfer-Out (Internal → External)

Response:
Follows same lifecycle as quote-based outgoing transactions.

Transfer-In (External → Internal)

Only works for “pullable” external accounts (e.g., debit cards).

Monitoring Transactions

Subscribe to transaction webhooks for real-time updates:

Via Polling (Backup)

Query transaction status periodically:
Response:
Poll every 5-10 seconds until terminal status reached.

Listing Transactions

Query all transactions for a customer or date range:
Response:
Use for reconciliation and reporting.

Failure Handling

Common Failure Reasons

Best Practices

Don’t rely solely on polling:
Save transaction IDs to your database:
Use idempotency keys for safe retries:
Translate technical statuses to user-friendly messages: