Payment Lifecycle

Every payment has a status. The table below lists the customer-visible statuses; these values appear in the status field and in webhook event types.

Statuses

Status	UI label	Meaning
initiated	Created	Cardless payment created; the buyer has not yet been redirected to the handoff / 3D is not yet complete. Card-bound fields (maskedPan, cardFamily, commission) are null at this stage.
capture_pending	Verifying transaction	Result inconclusive; the system resolves it. Not counted as failed automatically.
captured	Successful	Capture approved.
failed	Failed	3D rejection or capture rejection.
expired	Expired	The payment/3D window elapsed or 3D was abandoned.
voided	Voided	Cancelled on the same day.
partially_refunded	Partially refunded	Cumulative refund < sale amount.
refunded	Refunded	Cumulative refund = sale amount.

Inconclusive is not automatic failure

Do not treat a payment in capture_pending as failed on your own. The system resolves the result and notifies the final status (captured or failed) via a webhook.

Card/commission fields are null at INITIATED

For a payment in initiated, the card has not yet arrived via handoff, so the query response returns card-bound fields such as maskedPan, cardFamily, appliedRateBps, commissionAmount, and netToPartner as null. These values are determined after the 3D relay starts. No webhook is sent at this stage; the first webhook is typically payment.captured/payment.failed/payment.expired.

Transition summary

initiated ──► captured ──► (voided | partially_refunded ──► refunded)
   │              ▲
   │              │
   └► capture_pending (inconclusive; system resolves)
   │
   ├► failed      (3D or capture rejection)
   └► expired     (window elapsed / 3D abandoned)

Voids and refunds are started via Refunds & Void; the resulting status is voided, partially_refunded, or refunded.

Webhook event ↔ status mapping

Webhook event type	Status(es) you will see in the query
payment.captured	captured
payment.failed	failed
payment.expired	expired
refund.approved	voided, partially_refunded, or refunded
refund.declined	(payment status unchanged; the refund’s status is declined)

Refund/void outcomes are reported via refund.approved / refund.declined; since a single refund.approved can lead to three different payment statuses, learn the exact status via GET /v1/payments. See Webhooks.

Note

Transient statuses corresponding to internal verification steps are not surfaced to the customer; you will not see a status value outside the table above.