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 for details.