# Queued Payouts

Sometimes you need to submit a payout before the funds that cover it have landed in your balance. By default, Glomo rejects that payout with an insufficient-balance error, and you have to submit it again after you top up.

Payout queueing removes that retry loop. When it is enabled on your account, every payout is accepted with the status `queued`, including one that your balance already covers. Glomo releases each payout automatically once your balance covers it. You do not have to do anything else.

## How a queued payout is released

When payout queueing is enabled, every payout is created with the status `queued`, whatever your balance is at that moment.

Glomo checks the queue every 15 minutes. At each check it compares your balance in the source currency against the payout amount plus fees, and releases the payout if the balance covers it. The payout then continues as any other payout does: it moves to `in_progress`, and then to `success` or `failed`.

Note the following:

- **Queued payouts are released in FIFO order, per currency.** Within a source currency, the payout that was queued first is released first. Each currency has its own order, so a queued EUR payout has no effect on your queued AED payouts.
- **A payout your balance covers is still queued.** It waits for the next check, so it can take up to 15 minutes before processing starts.
- **A payout your balance can't cover holds back the ones behind it.** Within a source currency, release stops at the first payout your balance doesn't cover, and the payouts queued after it wait even if the balance would cover them.


## Fees and FX rate

Fees and the FX rate are fixed when the payout is created, not when it is released. The rate you see at creation is the rate Glomo applies when the payout is released.

## Leaving the queue

A queued payout leaves the queue in one of these ways:

| Outcome | Description |
|  --- | --- |
| **Released** | Your balance covers the payout. The payout moves to `in_progress` and continues to `success` or `failed`. |
| **Expired** | The payout stays queued for 30 days. It moves to `failed` with `error_code` set to `QUEUE_EXPIRED`. No funds were held at any point. |
| **Cancelled** | You cancel the payout. You can do this at any time while the payout is queued. Nothing is reversed, because no funds were held. |
| **Review needed** | Glomo needs more information before the payout can be processed. The payout moves to `action_required`. See [Action Required State](/payout/action-required-state). |


To cancel a queued payout, use the [Cancel a payout API](/api-reference/openapi/payout/cancelpayout) or the Glomo dashboard. See [Cancel a Payout](/payout/cancel).

## What you see in the API

A queued payout has `status` set to `queued`. The status appears in the create response, in [Retrieve a payout](/api-reference/openapi/payout/getpayoutbyid) (`GET /v1/payouts/:id`), and in [List all payouts](/api-reference/openapi/payout/getpayouts) (`GET /v1/payouts`).

To list only your queued payouts, use the `status` filter:

```
GET /v1/payouts?status=queued
```

Glomo sends a payout webhook with `event_type` set to `queued` when the payout enters the queue, and another webhook when it leaves. No new webhook type was added. See [Payout Webhooks](/platform/webhooks/payout).

## If payout queueing is not enabled

Glomo keeps rejecting a payout that your balance does not cover at the time you create it, with this message:

```
Account has insufficient balance to process this transaction. Additional amount required: N.
```

## Testing queued payouts in sandbox

Use your test secret key. The mock endpoints in this section are not available in production.

### Move a queued payout with the mock endpoint

A `queued` payout can't be mocked straight to `success`. [Mock update a payout status](/api-reference/openapi/payout/mockupdatepayoutstatus) (`PATCH /v1/payouts/mock`) returns `400` with `State change not allowed`. Move it in two steps:

1. Mock `pending`. The payout's `status` then reads `in_progress`, not `pending`, so wait for `in_progress` if you poll.

```json
{ "id": "payout_E602dMzgjpDC", "status": "pending" }
```
2. Mock `success` or `failed`.

```json
{ "id": "payout_E602dMzgjpDC", "status": "success" }
```


A payout you moved with the `pending` mock is never sent to a rail, so it always needs the second step, whatever its rail. Only a payout that the queue releases for real completes on its own on a local rail in sandbox (see [Test it in sandbox](/payout/set-up#test-it-in-sandbox)); for those, the `success` mock is needed only on SWIFT.

### Queue a payout with the mock endpoint

To put a payout that is `pending_approval`, `action_required` or under review into the queue, mock `queued`. Mocking `pending` on such a payout also queues it, since that is what a real submission does on an account with payout queueing. Mock `pending` again to move it on.

```json
{ "id": "payout_E602dMzgjpDC", "status": "queued" }
```

The payout then waits for the queue release like any other queued payout.

### Test the real queue release

To test the release itself instead of mocking past it, fund the balance that the payout debits and wait for the queue to release it.

- The queue is released every 15 minutes, at :02, :17, :32 and :47 past the hour. These are the same marks in UTC and IST.
- Release is FIFO per source currency. A payout is released only when the balance it debits covers it, and a payout at the head of the queue that isn't covered holds back the ones behind it.
- A released payout shows `in_progress`.
- A payout that stays queued for 30 days fails with `QUEUE_EXPIRED`.
- A payout debits your Funded Balance if your account has it enabled, and your Primary Balance otherwise. Only Add Balance top-ups (`add_funds` payins, with IDs starting `addfunds_`) credit the Funded Balance. Regular payins credit the Primary Balance. See [Balances](/multi-currency-account/balances).


To release a queued payout for real:

1. Fund the balance the payout debits. For the Funded Balance, go to **My account**, then **Add balance** on the Balances screen, and choose the currency. See [Add Balance](/multi-currency-account/add-balance).
2. Call [Create a mock payment](/api-reference/openapi/payment/createmockpayment) (`POST /v1/payment/mock`) with `payin_id` set to the Add Balance top-up (`addfunds_…`), and with its `amount` and `currency`.
3. If the payment's funds are not yet available, call [Mock funds available](/api-reference/openapi/payment/mockupdatepaymentfundsavailable) (`PATCH /v1/payment/{id}/mock-funds-available`).
4. Wait for the next release, then read the payout. It shows `in_progress`.


The public API doesn't list add-funds payins. [List all payments](/api-reference/openapi/payment/getpayments) with `payment_type=add_funds` (`GET /v1/payment?payment_type=add_funds`) lists add-funds payments only.