PaymentsOperational

Payment states

Understand successful, failed, pending, cancelled, and refunded states and the correct response to each.

Last reviewed: For: Merchant · Cashier · Support team

State directs the next action

A state is not decoration; it is an operational contract. A cashier should not treat pending as failed, finance should not treat created as realized revenue, and a phone message should not override the transaction record.

Common states

  • Created: the request exists but is not confirmed.
  • Requires confirmation: waiting for the customer or authorized operator.
  • Processing: submitted to the financial path without a final outcome.
  • Succeeded: completion conditions are met and the effect is recorded.
  • Failed: not executed, with a safe reason and corrective step when possible.
  • Cancelled or expired: closed before final execution.
  • Partially or fully refunded: value returned through a flow linked to the original transaction.

What to do with pending

Wait for the documented interval, then refresh using the same reference. Do not create a new transaction only because the screen did not change. If the state exceeds its processing window, escalate with safe evidence.

Good messages

They explain what happened and what can be done without exposing security data or irrelevant provider internals. “The payment is being verified; do not pay again before refreshing status” is better than “Error 500.”

For daily cases, use Payment troubleshooting.