> For the complete documentation index, see [llms.txt](https://docs.xplorpay.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.xplorpay.com/api-reference/resources/ach-request-validation-response-and-return-codes/ach-transaction-statuses.md). # ACH Transaction Statuses When an ACH transaction is processed through Paya, multiple status values describe different parts of the transaction lifecycle. * **Check Status** describes the consumer-side ACH transaction. * **Funding Status** describes the merchant's funding activity. * **Xplor Pay API status** provides a normalized summary of the overall transaction state. A transaction can have different Check Status and Funding Status values at the same time because each status represents a different part of the transaction lifecycle. ### Check Status and Funding Status The table below lists the Check Status and Funding Status values with what each status indicates.

Status	Applies to	Description	Use for
Check status	Consumer	Status of the consumer ACH transaction, such as whether it was submitted, pending, rejected, canceled, or returned.	Consumer transaction lifecycle, rejection analysis, return analysis, and resubmission decisions.
Funding status	Merchant	Indicates whether the merchant was funded, was not funded, was debited after funding, or was affected by another funding event.	Merchant settlement, reconciliation, and determining the impact on the merchant's funds.
Xplor Pay API status	Transaction	Provides a normalized status representing the overall transaction state.	High-level application workflows. Use Check Status and Funding Status for detailed ACH processing and reconciliation.

### Paya statuses and API status The table below lists the relationship between common Paya check status and funding status values with the corresponding Xplor Pay API status. {% hint style="info" %} The same Paya status name can have a different meaning depending on whether it is reported as a Check Status or Funding Status. Always consider the status source when interpreting the transaction. {% endhint %}

Paya Status	Source	Description	API status	Interpretation
Debit sent	Check	The consumer debit has entered the ACH network and was sent to the ODFI.	`SETTLING`	Indicates that the consumer-side transaction is progressing through the ACH network. It does not confirm that the merchant has been funded.
Credit sent	Check	The consumer-side ACH credit has entered the ACH network.	`SETTLING`	Use this as a consumer transaction lifecycle signal rather than a merchant funding confirmation.
Pending	Check	The consumer transaction is scheduled for submission to the ACH network.	`PENDING`	The transaction has not yet reached the ACH network.
Cancelled	Check	The consumer-side transaction was canceled or returned.	`RETURNED`	Review the return code to determine why the transaction was returned and whether a new transaction can be submitted.
Rejected: Authorization Declined	Check	The transaction was rejected because authorization was declined.	`REJECTED: AUTHORIZATION DECLINED`	Use Check Status to determine the rejection reason. Funding Status may indicate `No Credit`.
Rejected: Account Is Invalid	Check	The transaction was rejected because the account information is invalid.	`REJECTED: ACCOUNT IS INVALID`	Use Check Status to determine the reason for the failure.
Rejected: Voiding	Check	A void operation is in progress.	`REJECTED: VOIDING`	Indicates a void-related state rather than a bank return.
Rejected: Voided	Check	The transaction has already been voided.	`REJECTED: VOIDED`	Indicates a completed void-related outcome.
Unprocessed	Check	The transaction was received but has not completed initial processing or scrubbing.	`UNPROCESSED`	Indicates an early processing state, not necessarily a failure.
Credit sent	Funding	The merchant credit was sent or paid.	`SETTLING`	Indicates that merchant funding has occurred or is completing. The API may still show a broader processing state.
Debit sent	Funding	The merchant debit has been sent through the ACH network.	`SETTLING`	Represents merchant-side movement of funds and should be interpreted as a funding event.
Pending	Funding	The merchant credit is scheduled but has not yet been paid.	`PENDING`	Use this status when determining whether merchant funding has occurred.
Cancelled	Funding	The merchant was not paid, or a return was received before merchant funding was completed.	`RETURNED`	Indicates that merchant funding was not completed before the return.
Chargeback	Funding	The merchant was previously funded and was later debited because of a consumer return.	`CHARGEBACK`	Indicates that funds were previously credited to the merchant and later debited.
No Credit	Funding	No merchant credit will be scheduled.	`NO CREDIT`	Indicates the funding consequence. Use Check Status to determine the reason for the rejection.
Reserved	Funding	The merchant credit was paid to a reserve account.	`RESERVED`	Indicates that the funds were placed in a reserve rather than normal merchant settlement.
To Reserve	Funding	The transaction is following a reserve-related funding process.	`TO RESERVE`	Consider this as a reserve state rather than normal settlement.
Returned	Funding	The merchant-side credit or debit was returned because of an issue with the merchant's bank account information.	`MERCHANT_RETURNED`	Indicates a merchant-bank funding issue. This represents a merchant-bank funding issue rather than a consumer ACH return.
Unprocessed	Funding	The funding process has not completed initial processing.	`UNPROCESSED`	Indicates an early funding state but not necessarily a failure.

### Common status combinations The table below lists check and funding statuses together to understand the complete transaction lifecycle.

Check Status	Funding Status	Description	API Status
Debit Sent	Pending	The consumer debit has been sent to the ODFI, but the merchant credit is still pending.	`PENDING`
Debit Sent	Credit Sent	The consumer debit and merchant credit have both been processed.	`SETTLING`, followed by `SETTLED` when Xplor Pay recognizes funding completion.
Cancelled	Chargeback	The consumer transaction was returned after the merchant had already been funded.	`CHARGEBACK`
Cancelled	Credit Sent	The consumer transaction was returned, but the merchant remains credited.	Interpret the Funding Status to determine the impact to merchant funds.
Rejected: <reason>	No Credit	The consumer transaction was rejected and the merchant will not be credited.	Use Check Status for the rejection reason and `NO CREDIT` for the funding outcome.
Cancelled	Cancelled	The consumer transaction was returned or canceled before the merchant was funded.	`RETURNED`

### Chargebacks For Paya ACH processing, a **chargeback** is a merchant-side funding event. It occurs when the merchant was previously credited for the consumer transaction and a subsequent return causes the merchant to be debited. A chargeback is different from a transaction that is returned before merchant funding is completed. For example, when the check status is **Cancelled** and funding status is **Chargeback**. The funding status indicates that the merchant was funded and subsequently debited. #### Return Codes and Transaction Statuses ACH return codes, such as `R01` and `R10`, describe why a consumer-side ACH transaction was returned. Use the return code together with **check status** to determine: * Why the consumer transaction was returned. * Whether the transaction can be resubmitted. * Whether a new authorization is required. * Where the transaction is in its return lifecycle. Use the **funding status** to determine how the return affected the merchant's funds. For more information about ACH return codes, see [ACH Return Codes](https://docs.xplorpay.com/api-reference/resources/ach-request-validation-response-and-return-codes/ach-return-codes). #### Recommended Integration Practice * Use Funding Status for merchant settlement, ledger, and reconciliation decisions. * Use Check Status for the consumer transaction lifecycle, rejection details, return-code analysis, and resubmission decisions. * Use Xplor Pay API status as the normalized application status rather than the only source of truth for detailed ACH reconciliation. * Distinguish chargebacks, merchant-bank returns, no-credit outcomes, and reserve states from ordinary consumer ACH returns. ### ACH Lifecycle Example

Stage	Check Status	Funding Status	Interpretation
Submitted	Debit Sent	`Pending`	The consumer debit is progressing, but the merchant has not yet been funded.
Normal funding	Debit Sent	`Credit Sent`	The merchant credit has been sent or paid.
Return before funding	Cancelled	`Cancelled`	The consumer transaction was returned before the merchant was funded.
Return after funding	Cancelled	`Chargeback`	The merchant was funded and later debited because of the return.
Rejected	Rejected: <reason>	`No Credit`	Check Status provides the rejection reason; Funding Status indicates that no merchant credit will be issued.

Related topics: * [ACH Return Codes](https://docs.xplorpay.com/api-reference/resources/ach-request-validation-response-and-return-codes/ach-return-codes) * [ACH Transactions API](https://docs.xplorpay.com/api-reference/api/payments/ach/ach-transaction/ach-transactions) --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## 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, and the optional `goal` query parameter: ``` GET https://docs.xplorpay.com/api-reference/resources/ach-request-validation-response-and-return-codes/ach-transaction-statuses.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. 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.