## How it works

The payment status is shared by the API, dashboard and webhook payload. Authorization, capture and settlement-related updates are distinct stages; a browser return is not a payment result.

## Implementation

Waiting states include requires_payment_method, requires_confirmation, requires_customer_action, requires_merchant_action and processing. Manual capture pauses at requires_capture; partial authorizations and captures have their own states. Fulfil once when the current payment is succeeded and its amount and currency match your order. A failed, declined, expired or cancelled attempt can later be followed by success, so reconcile subsequent events. Refund captured funds; cancel only the remaining uncaptured authorization.

## In this area

- Payment states
- Waiting
- Authorised, not fully captured
- Succeeded
- Not successful (yet)
- Other
- Capture
- An unsuccessful payment can still succeed

## Related guides

- [Refunds](/docs/payment-api/refunds/)
- [Webhook events](/docs/payment-api/webhooks/)
- [Accept payments](/docs/payment-api/accept-payments/)

## Status paths

```text
requires_payment_method → requires_confirmation → processing → succeeded
                                           ↘ requires_customer_action ↗
processing → requires_capture → capture → succeeded
processing → declined / failed → a later successful attempt may follow
```

## Capture choices

| Value | Purpose |
| --- | --- |
| `automatic` | Authorization and capture in the normal payment flow |
| `manual` | Hold an authorization for one later capture |
| `manual_multiple` | Capture supported authorized funds in parts |
| `sequential_automatic` | Follow authorization with an automatic capture step |

Processor support determines which choices are valid for a connector.