A payout page moves through a set of statuses from creation to completion. These statuses (and sub-statuses) let you track where the payout is in its lifecycle and handle events appropriately.

For webhook payload examples for each status change, see Webhook Events for Payout Pages.

Statuses

Status	Meaning	Example Trigger
`CREATED`	Payout page has been created successfully.	Merchant calls Create Payout Page API.
`PENDING`	Awaiting action before processing can start.	Customer has opened the payout page but hasn’t finished all steps.
`PROCESSING`	Breeze is interacting with third-party providers to send funds.	Funds are being routed through bank or blockchain.
`PROCESSED`	Funds have been successfully sent to the customer’s crypto wallet, or accepted by the bank and are in transit, or the payout is in a transitional state leading to`REFUNDED`.	Crypto transaction confirmed, or bank partner accepted the transfer, or bank partner responded that payout cannot be processed and will be refunded.
`REFUNDED`	Funds rejected by third-party provider, and credited back to merchant's payout balance.	Bank account closed or details invalid.
`CANCELLED`	Payout page cancelled by the merchant before processing.	Merchant calls Cancel Payout Page API.
`EXPIRED`	Payout page was never processed and is no longer available.	Customer did not act before expiry time.
`REJECTED`	Payout request is rejected by Breeze.	Required risk checks are not met.

flowchart TD
    A[CREATED] --> B[PENDING]
    B -.-> H[REJECTED*]
		B --> C[PROCESSING]
    C --> D[PROCESSED]
    D -.-> E[REFUNDED]
    B --> F[CANCELLED]
    B --> G[EXPIRED]

Sub-Statuses (for PENDING status only)

While in the PENDING status, a payout page can be in one of the following sub-statuses:

Sub-Status	Meaning	Example Trigger
`PENDING_USER_CONFIRMATION`	Waiting for the customer to provide payout method and details.	Customer has opened the page but hasn’t submitted payout info yet.
`PENDING_USER_ONBOARDING`	Waiting for the customer to complete the KYC verification required for this payout.	Customer is routed to the identity verification flow whenever this payout requires a higher KYC tier than they currently hold.
`PENDING_MERCHANT_RELEASE`	Waiting for merchant to call the Release Payout Page API.	Merchant created the page with manual release setting enabled.

CustomerPENDING_USER_CONFIRMATION

Customer has opened the payout page but hasn't submitted their payout method and details yet.

Webhook: PAYOUT_PAGE_PENDING_STATUS_UPDATE · pendingStatus: PENDING_USER_CONFIRMATION

CustomerPENDING_USER_ONBOARDINGwhenever KYC is required

Customer is completing KYC verification. This is not limited to a customer's first payout: a returning customer re-enters this sub-status whenever the payout they confirm requires a higher KYC tier than they currently hold.

Webhook: PAYOUT_PAGE_PENDING_STATUS_UPDATE · pendingStatus: PENDING_USER_ONBOARDING

MerchantPENDING_MERCHANT_RELEASEMANUAL releaseMethod only

Waiting for merchant to call POST /v1/payout_pages/:id/release.

Webhook: PAYOUT_PAGE_PENDING_STATUS_UPDATE · pendingStatus: PENDING_MERCHANT_RELEASE

Not all three sub-statuses appear for every payout — PENDING_USER_ONBOARDING fires whenever the payout needs KYC the customer hasn't completed yet, PENDING_MERCHANT_RELEASE only when releaseMethod is MANUAL. Treat these sub-statuses as a set of possible states rather than a strict sequence.