Payment states
A payment can have several States. It can change states when a Modification is made.
This diagram shows all the states of a payment:
PAYMENT STATES
🚩 Even if the merchant (partially) captures, (partially) refunds, or cancels the payment, the state will remain AUTHORIZED.
When a payment is initiated, it has the state CREATED.
Once a payment is confirmed by the user, the payment state is AUTHORIZED.
You can see history of the payment events with the Get payment event log endpoint.
To track status in real-time, use both Webhooks and polling Get payment details, according to the polling guidelines.
Here is a description of each state:
| State | Description | Example |
|---|---|---|
CREATED | The payment has been initiated. The user has not yet acted upon the payment. | The user has received a push message, but not yet opened it. Or: The user has been sent to the landing page, but has not done anything in the app. |
AUTHORIZED | The user has accepted the payment in the app. This is a final state. | The payment has been reserved, (partially) captured or (partially) refunded. A payment that has been captured (either fully or with one or more partial captures), or that has been refunded, will have one or more events, but the state would be AUTHORIZED. |
ABORTED | The payment has been actively stopped by the user. The user has aborted the payment before authorization. This is a final state. | The user cancelled instead of accepting the payment. |
EXPIRED | The payment has expired. The user did not act on the payment within the payment expiration time. This is a final state. | The user received a push message, but did nothing before the payment request timed out. By default, a user has a total of 10 minutes to accept a payment. |
TERMINATED | The merchant has cancelled the payment before authorization. The merchant has terminated the payment via the cancel endpoint. This is a final state. | The merchant was not able to provide the product or service, and has cancelled the payment. |
| Other states | A payment will not change state after becoming AUTHORIZED. This is because a payment can be partially captured, and also partially refunded. It is therefore not practical to have states like "captured" or "refunded", since it is not possible to give all the information with just the state. | A payment can be partially captured, partially refunded, cancelled, but it will not change the state. |
Payment modifications
The following modification actions can be made to AUTHORIZED payments:
| State | Description |
|---|---|
| Capture | The merchant captured part or all of an authorized payment. |
| Refund | The merchant refunded part or all of an authorized payment. |
| Cancel | The merchant has cancelled the uncaptured amount of an authorized payment. |
While you can capture, cancel and refund a payment after authorization, this does not change the state of the payment.
A payment will remain in the state: AUTHORIZED.
To get all the details about the payment, including the captured and refunded amounts:
Use
GET:/epayment//v1/payments/{reference},
which will give you the aggregate.
You can see history of the payment events with the
GET:/v1/payments/{reference}/events.
Read about this more under Get payment event log.
To track status in real-time, use both Webhooks
and polling GET:/epayment//v1/payments/{reference}, according to the
polling guidelines.
The following diagram shows the modification actions for a payment.
Payment actions