# Transaction Queues

When a transaction is created via the API and passes initial validation, it will return a status of `QUEUED`. This
indicates the transaction has been accepted and entered into GrailPay's processing pipeline.

Transactions in a `QUEUED` state are processed in FIFO (First In, First Out) order based on their `queued_at` timestamp.
No priority is applied based on merchant, transaction type, amount, or modality.

In rare cases, a transaction may be re-queued — for example, if an internal processing error occurs that requires the
transaction to be retried. When this happens, the `queued_at` timestamp is overwritten with the new queue time, so
the transaction's position in the queue is determined by the updated timestamp rather than the original submission time.
This means a re-queued transaction may process after transactions that were submitted later.

## How it works

Once queued, GrailPay handles ACH creation and webhook delivery asynchronously. This means your integration receives a
successful response at transaction creation — processing happens in the background as soon as conditions allow.

## Why transactions may remain queued

A transaction will remain in a `QUEUED` state until it can be processed. Common reasons include:

- **Banking partner unavailability** — The transaction will process as soon as the partner comes back online, in FIFO order.
- **Origination limit reached** — If the 24-hour origination limit has been reached, the transaction will process once the limit rolls over.

:::note
Prior to this change, either of the above conditions would result in a transaction creation error.
Transactions are now accepted regardless, eliminating failures caused by partner outages or usage limits.
:::

## Webhooks

You will receive a webhook notification when your transaction moves out of `QUEUED` and begins processing.
See [Transaction Webhook Events](/docs/technical/webhooks/events/transaction/) for details.