TransactionsCopy Anchor Link

A Transaction represents the financial movement, authorization, or pending provider flow captured during a Checkout session.

You can monitor payment volume under the Transactions section.

Transaction LifecycleCopy Anchor Link

The Transactions list and detail views use these labels: Initiated, Pending, Completed, Failed, Canceled, Refunded, and Disputed. The Admin API, exports, and outbound IPN payloads use integer status codes instead of these display names:

Transactions flow through several definitive states:

1. Initiated (-1): The customer has opened the Checkout page and the gateway has created the local transaction or provider payment object, but the payment is not final.
2. Pending (0): Used for asynchronous payment methods such as bank transfers, mandates, redirects, or provider flows that settle later.
3. Completed (1): The funds have been captured or the provider has confirmed successful settlement. For receipt-backed payments this means that receipt settled; the canonical order is paid only when eligible allocations cover its receivable. Extra funds remain held.
4. Failed (2): The provider rejected the payment attempt.
5. Canceled (-2): The customer, operator, timeout, or provider flow canceled the attempt before completion.
6. Refunded (3): The original successful transaction has been fully refunded. Partial refunds keep the transaction linked to refund events and settlement totals.
7. Disputed (4): A chargeback or dispute was recorded against a completed payment. Operators see this status in the Admin Panel; linked invoices can show dispute state separately.

Analyzing Transaction LogsCopy Anchor Link

By clicking a specific transaction, you can inspect:

• Timeline events: Provider interactions and status changes.
• Tax evidence: Stored buyer location proof and tax decision data used for EU VAT OSS and reporting.
• Provider raw data: The unstructured JSON payload or provider response used for debugging webhook and settlement issues.
• Outbound IPN: On the gateway release with versioned delivery, transaction details retain the aggregate ipnResponse and also show durable delivery state, selected version, attempt counts, failure diagnostics, and last/next attempt times. Filter deliveries by state, inspect paged attempt history, and request an authorized retry.
• Failed construction: Accepted IPN work is visible even if no delivery could yet be built. Correct the reported cause and retry that command; do not create a replacement notification to bypass it.

A manual retry is queued for the main backend; acceptance does not mean delivery has succeeded. Pending or scheduled work is advanced within its current retry budget, while a terminal delivery starts a new bounded replay cycle. An already active attempt is reported without queuing another attempt. Retry preserves the original delivery identity, body, version and destination. The gateway applies payment-reconciliation and tenant permissions before replay. Detailed attempt history expires after 30 days; durable receipts retain the information needed for safe replay.

Existing sites remain on signed v1 after upgrade, while new sites default to v2. See Migrating to IPN v2 for compatible published receiver releases and the support period through 30 June 2027.

Use the Transactions list's IPN needs attention checkbox (Admin API query ipnNeedsAttention=true) to find historical transactions with any unresolved exhausted or terminal delivery, or a failed construction command without its matching delivery. Combine it with organization, site and provider filters and pagination; inspect transaction history for the precise cause. A recovered construction command does not keep the transaction in the filter after its matching delivery exists. A retry accepted with HTTP 202 is queued, not delivered. Compact ordering and effect receipts remain available for later manual replay.

When the transaction is linked to a stored Client, the detail view also provides a direct Client profile link so operators can jump into the full relationship history.

Operational ActionsCopy Anchor Link

See Receipts and allocation for recording a missing historical bank receipt, partial payments, extra customer funds and safe retries.

Legacy refund, chargeback, and financial-status mutations are unavailable. Historical refund and dispute events remain read-only. Normal non-financial transaction editing and eligible pre-settlement cancellation remain separate from return processing.

Receipt-backed completed Stripe payments can use Process Refund. The screen first loads server-owned held and sale capacity, currency, provider capability, and receipt version. It then initiates one immutable provider operation. An Invoice action routes to this same transaction screen; it does not submit a separate refund.

Uncertain, reserved, pending, and unknown operations keep their original identity and version until direct readback proves a matching terminal result. See Refunds and Returns for the UI, API, provider, retry, and recovery contract.

Return amounts use the displayed currency's supported precision. For example, 50 JPY, 0.50 EUR and 0.050 KWD each represent 50 minor units. Payment confirmation uses the payout currency when conversion occurred. See Entering Amounts for the distinction from invoice line-item prices and invalid-input handling.