# Payment flow

## Status overview <a href="#status-overview" id="status-overview"></a>

An online transaction\* progresses through the following states:

<div data-with-frame="true"><img src="https://verifone.cloud/sites/default/files/inline-images/MicrosoftTeams-image%20%2870%29.png" alt="" height="835" width="626"></div>

* INITIATED — The transaction has been successfully created in our system, but hasn't been processed yet.
* AUTHORIZED — The transaction has been authorized by the customer, and can now be processed. One can now void the authorization.
* AUTHORIZATION\_VOIDED — The transaction has been cancelled by the merchant, prior to being queued for processing.
* SETTLEMENT\_REQUESTED — The transaction has been queued for processing. This request can be cancelled.
* SETTLEMENT\_SUBMITTED — The transaction has been submitted to the acquirer for processing. No action is possible when a transaction is in this state.
* SETTLEMENT\_PARTIAL — At least one, but not all, of the transaction's installments have been processed. The transaction can still be refunded.
* SETTLEMENT\_CANCELLED — The transaction has been cancelled by the merchant, after being queued for processing, but before being processed.
* SETTLEMENT\_COMPLETED — The transaction has been successfully processed. The transaction can now be refunded.
* DECLINED — The transaction request has been declined by the payment processor.
* FAILED — The transaction has been rejected by Verifone, or an error has occurred during transaction processing, most likely because the transaction request is malformed or inconsistent.
* UNKNOWN — A critical state meaning that something has gone seriously wrong. The transaction's state cannot be determined at the present time.
* PENDING — When trying to void authorization, there is a chance that it might not be succeeded. If it doesn't succeed, it first goes to PENDING state, then a task runs everyday to do a void authorization action again.

{% hint style="info" %}
\*The payment flow can vary depending on the channel, acquirer, payment method etc.
{% endhint %}

## Payment life cycle & statuses <a href="#payment-life-cycle-__0026-statuses" id="payment-life-cycle-__0026-statuses"></a>

Transactions can have different statuses (only one at a time) based on where they are in the life cycle. The life cycle will vary slightly per payment method.

### Initiated <a href="#initiated" id="initiated"></a>

This is a status that all payment methods will have. It is assigned to a transaction once the transaction has been created, regardless of the outcome. A transaction is not created if there an internal error. An internal error is most often caused by incorrect credentials to submit the transaction to the acquirer. Otherwise it is likely a connection/time-out error.

The transaction has been successfully created but has not been processed yet.

### Authorized <a href="#authorized" id="authorized"></a>

This step indicates that the card issuer has authorized (approved) the transaction for the card holder. An authorization freezes the funds on the credit card. From this stage the transaction can either be captured or voided. Until either action is taken the funds are still frozen on the credit card. However, issuers generally release the funds (void the authorization) automatically within 7-30 days if no action is taken at all.

### Authorization voided <a href="#authorization-voided" id="authorization-voided"></a>

An authorization can be voided if the goods cannot be delivered or the card holder wishes to cancel their order. Only the merchant has the power to void the authorization.

### Settlement requested <a href="#settlement-requested" id="settlement-requested"></a>

A transaction receives this status when it has been captured by the merchant. If a capture request is submitted the previously frozen funds will be captured from the credit card and transferred to the merchant account. In the background acquirers typically generate a batch file for processing with the card networks. The batch file is generated once per day and contains all transactions that the acquirer would like to capture. Cut-off times are used for the generation of the capture file.

### Settlement cancelled <a href="#settlement-cancelled" id="settlement-cancelled"></a>

After the transaction has been captured and before the batch file is generated by the acquirer it is possible to cancel or void the settlement request. This can be done by the merchant by voiding the capture.

### Settlement completed <a href="#settlement-completed" id="settlement-completed"></a>

A transaction will update to settlement completed once confirmation has been submitted by the acquirer that the transaction has been successfully processed. This means that the capture request was accepted by the card issuer and the funds will be transferred to the merchant account.

### Declined <a href="#declined" id="declined"></a>

Transactions can be declined by the card issuer for various reasons. For example if the card holder has insufficient funds in their account. Find a comprehensive list of reason codes [here](/online-payments/api-integration/reason-codes-for-api-transactions.md).

### Unknown <a href="#unknown" id="unknown"></a>

A transaction receives the unknown status as a response to a authorize, void or capture request. This means that something has gone wrong and the state of the transaction cannot be determined at this time.

### Pending <a href="#pending" id="pending"></a>

When trying to void authorization, there is a chance that it might not succeed. If it doesn't succeed, it first goes to PENDING state, then a task runs everyday to do a void authorization action again.


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://docs.verifone.com/online-payments/payment-actions/payment-flow.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.