--- title: "Transaction Types and Statuses" slug: "transaction-types-and-statuses" status: "update" updated: 2026-02-26T16:50:43Z published: 2026-02-26T16:50:43Z canonical: "resource.payrix.com/transaction-types-and-statuses" stale: true --- > ## Documentation Index > Fetch the complete documentation index at: https://resource.payrix.com/llms.txt > Use this file to discover all available pages before exploring further. # Transaction Types and Statuses While processing transactions on the Payrix Pro platform, many statuses will be assigned to transactions based on their type, and progress through processing to capture funds from customer payment methods. This article defines the different transaction types and statuses and also describes secondary statuses and amount fields. For details about the timeline for the movement of authorized payment funds from the customer’s payment method to the merchant’s Payrix Pro account balance, see [Payment Processing Life Cycle and Timelines](/v1/docs/payment-processing-life-cycle-and-timelines). ## Transaction Types This section outlines the various types of transactions processed through the platform, detailing the steps and status updates for each transaction type. See [Transaction Statuses](/v1/docs/transactions-types-and-statuses#transaction-statuses) for more information on each transaction status. ### Sale Transaction Sale transactions refer to credit card payments submitted through the platform. 1. A Sale transaction is created when a credit card payment is submitted through the Merchant. 2. Once authorized, the Sale transaction status is updated to **Approved**. 3. On daily batch close, the authorized payment funds will be included in the batch for settlement and the Sale transaction status is updated to **Captured**. 4. Once settlement of the batch is complete, the funds will be deposited into the Merchant’s available balance and the Sale transaction status is updated to **Settled**. ### Authorization Transaction Authorization (Auth) transactions temporarily hold funds on the customer’s card until a capture transaction is submitted, holding funds on the cardholder's account. The held amount is retained until a Capture transaction is initiated for inclusion in the settlement batch. 1. An Auth transaction is created when a credit card authorization hold is submitted through the Merchant. 2. Once authorized, the Auth transaction moves into an **Approved** status. The authorized funds will be held on the cardholder account, and a subsequent Capture transaction can be processed to collect the funds for settlement. > [!NOTE] > Note > > For authorization timeframes on subsequent Capture transactions, see [Transaction Capture Windows](/v1/docs/payment-processing-life-cycle-and-timelines#transaction-capture-windows). This section outlines card brands’ time limits before revoking authorization for transaction funds, requiring a new Auth and Capture or Sale transaction. ### Capture Transaction A Capture transaction is linked to a previous Auth transaction, acting as the second step in the process of collecting funds that have been approved in a prior **Approved** Auth transaction. 1. A Capture transaction is created when the Merchant initiates capture of Auth transaction funds using the portal or API. 2. Once initiated, the Capture transaction status is updated to **Pending**. 3. On daily batch close, the authorized payment funds will be included in the batch for settlement and the status is updated to **Captured**. 4. Once settlement is complete, the funds will be deposited into the Merchant’s available balance and the Capture transaction status is updated to **Settled**. > [!WARNING] > **Important!** > > A capture transaction that is greater than the original Auth approved might be flagged by Risk to investigate the discrepancy. ### Reverse Transaction Reverse transactions, also known as voids, are used to reverse authorization of an **Approved** Sale or Auth transactions before funds are captured for settlement. 1. A Reverse transaction is created when the Merchant initiates a void using the portal or API. 2. Once initiated, the **Approved** transaction will add a secondary status of **Voided**. The authorization hold is released, and the transaction is effectively voided. ### Refund Transaction Refund transactions are used to return Sale or Capture transactions that have already reached **Captured** or **Settled** status. The captured or settled funds are credited back to the customer by debiting the associated Merchant’s account balance. 1. A Refund transaction is created when the Merchant issues a refund of captured or settled payment using the portal or API. 2. Once initiated, the refund amount is instantly authorized as **Captured**, and the original Sale or Capture transaction shows a secondary status of **Refunded**, displaying the amount returned to the customer. 3. On daily batch close, the refund amount is debited from the associated Merchant’s account and the status is instantly updated to **Settled**. 4. The refunded amount is returned to the customer’s account typically within three to eight business days. ### eCheck Sale Transaction eCheck Sale transactions refer to checking account payments submitted through the platform. 1. An eCheck Sale transaction is created when a checking account payment is submitted through the Merchant. 2. On daily batch close, the status is updated to **Approved**. > [!NOTE] > Note > > The total for an eCheck Sale transaction reflects the approved amount. To modify the payment, the original eCheck sale must be voided and reprocessed. 3. On the following day, the authorized payment funds will be included in the batch for settlement. 4. Once settlement is complete, the funds will be deposited into the Merchant’s available balance and the status is updated to **Settled**. ### eCheck Refund Transaction eCheck Refund transactions are used to return eCheck Sale transactions that have already reached **Captured** or **Settled** status. The captured or settled funds are credited back to the customer by debiting the associated Merchant’s account balance. 1. A Refund transaction is created when the Merchant issues a refund of captured or settled payment using the portal or API. 2. Once initiated, the refund amount is instantly authorized as **Captured**, and the original eCheck Sale transaction shows a secondary status of **Refunded**, displaying the amount returned to the customer. 3. On daily batch close, the refund amount is debited from the associated Merchant’s account and the status is instantly updated to **Settled**. 4. The refunded amount is returned to the customer's checking account typically within four to eight business days. --- ## Transaction Statuses Each transaction will go through different statuses before being completed, failed, or refunded. The following sections describe each status. Each transaction type undergoes several statuses before it is marked as **Settled**, **Failed**, or **Returned**. Understanding these statuses is crucial to knowing the options available to merchants during different stages in each transaction’s life cycle. ### Approved **Approved** is the first status for successful sale, authorization, and reverse transactions indicating that the transaction request was authorized by the processing bank: - Sale transactions - eCheck Sale transactions - Auth transactions - Reverse transactions > [!NOTE] > Note > > An **Approved** transaction will not also have a **Pending** status. ### Pending **Pending** is the first status for Capture transactions that follow previous successful Auth transactions awaiting daily batch close for the capture of funds and settlement. ### Captured **Captured** is a status for a sale, capture, and refund transaction indicating that the authorized and approved transaction has been included in the merchant’s daily batch for settlement and funding: - Sale transactions - eCheck Sale transactions - Capture transactions - Refund transactions - eCheck Refund transactions > [!NOTE] > Note > > All Auth transactions require the submission of a corresponding Capture transaction. This Capture transaction is essential for securing the authorized funds for settlement. ### Settled A **Settled** status indicates that captured funds from a transaction have been settled and deposited to their respective destinations. In the case of Refund transactions, this status indicates that the amount was successfully debited from the Merchant’s account. ### Failed A **Failed** status indicates that the transaction was declined or was not approved for another reason. ### Returned A **Returned** status indicates that an eCheck transaction has been returned due to insufficient funds, stop payment, or for another reason. ## Secondary Statuses In addition to the primary transaction statuses, transactions can have a secondary status related to delaying, reversing, and refunding payments: - **Canceled:** The transaction was temporarily removed from settlement batching. - **Voided:** The transaction was permanently de-authorized and stopped. - **Refunded:** The transaction was refunded by debiting the merchant’s account balance. For more details on these secondary statuses, see [Reverse and Refund Payments](/v1/docs/reverse-and-refund-payments). ## Amount Fields When processing a transaction, reviewing the different fields showing each amount related to various transaction statuses is crucial. These amounts can significantly impact the funding that will be captured for deposit to the Merchant's account: - **Total:** The originally requested transaction amount. - **Approved:** The actual amount authorized for capture and settlement. - **Refunded:** The approved amount to be returned to the customer. A PayFac-as-a-service platform. Software companies can act as payment facilitators without taking on the associated risks, compliance burdens, and investment. The process of transferring funds from a customer's bank to a merchant's account after a transaction has been authorized. The movement of funds between a customer (cardholder or eCheck account holder) and a merchant to purchase a good or service. An entity that can process transactions and has been onboarded through a Payrix Pro partner. A group of captured transactions that are processed collectively by the acquiring bank for streamlined clearing and settlement of funds. The final stage of batch processing, where transaction funds are successfully processed and deposited from the acquiring bank and its processor to the merchant’s Available Balance for withdrawal to their bank account. The balance of an entity account recorded on the Payrix Pro platform identifying the total balance of the entity’s platform-hosted account balance. The process of placing funds on hold with a customer's bank to verify the availability of the amount required for a transaction. The process of a captured merchant transaction being settled and the amount of the settled transaction being deposited into the merchant’s available balance (minus fees and profit shares).