> ## Documentation Index
> Fetch the complete documentation index at: https://docs.wepayout.co/llms.txt
> Use this file to discover all available pages before exploring further.

# Automatic Pix Status Flow

> Lifecycle of authorizations, schedules, and payments in Automatic Pix

Automatic Pix has three interconnected lifecycles: the **authorization** (the payer's consent), the **schedule** (each individual billing cycle), and the **payin** (the actual money movement). Understanding how they relate is essential for a correct integration.

***

## Authorization Lifecycle

The authorization represents the payer's ongoing consent to be debited. It is the parent of all schedules — every schedule belongs to one authorization.

```mermaid theme={null}
graph TD
    A[Create Authorization] --> B[PENDING]
    B -->|Payer confirms via banking app| C[CONFIRMED]
    B -->|Payer declines or authorization expires| D[REJECTED]
    C -->|First schedule is automatically created| E[Schedule lifecycle begins]
    C -->|Merchant cancels via API| F[CANCELED]
    C -->|Payer cancels via their banking app| F
    F -->|All pending schedules are canceled in cascade| G[No more schedules]
    D -->|All pending schedules are canceled in cascade| G
```

<Warning>
  Both **CANCELED** and **REJECTED** are terminal states. In both cases, all pending schedules linked to the authorization are automatically canceled and no new schedules will be created.
</Warning>

### Authorization Status Reference

| ID | Status    | Webhook | Description                                                         |
| -- | --------- | ------- | ------------------------------------------------------------------- |
| 1  | Confirmed | ✅ Yes   | Payer approved — first schedule is created automatically            |
| 2  | Pending   | ✅ Yes   | Authorization created, waiting for payer confirmation via QR Code   |
| 3  | Canceled  | ✅ Yes   | Canceled via merchant API or by the payer through their banking app |
| 4  | Rejected  | ✅ Yes   | Payer declined during QR Code flow, or authorization expired        |

<Note>
  **Canceled vs Rejected**: CANCELED means an intentional termination — either by the merchant via API or by the payer revoking consent in their banking app after the authorization was already confirmed. REJECTED means the payer did not approve during the initial QR Code flow, or the authorization request expired.

  Both behave identically at the schedule level: all active schedules are canceled in cascade.
</Note>

<AccordionGroup>
  <Accordion title="1 - Confirmed">
    **Active status.**

    The payer scanned the QR Code and approved the recurring authorization via their banking app. The system automatically creates the first schedule using the `start_date` and `amount` configured in the authorization.

    **Next possible statuses**: Canceled
  </Accordion>

  <Accordion title="2 - Pending">
    **Initial status.**

    The authorization was created and the QR Code is ready for the payer to scan. No charges occur while in this status.

    **Next possible statuses**: Confirmed, Rejected
  </Accordion>

  <Accordion title="3 - Canceled">
    **Terminal status.**

    The authorization was canceled in one of two ways:

    * **Merchant via API**: Using the [Cancel Authorization](/api-reference/automatic-pix/authorizations/cancel) endpoint.
    * **Payer via banking app**: The payer revoked the authorization directly in their bank's interface.

    In both cases, all pending schedules linked to this authorization are immediately canceled and no future schedules will be generated.
  </Accordion>

  <Accordion title="4 - Rejected">
    **Terminal status.**

    The payer did not approve the authorization — either by explicitly declining the QR Code or by allowing it to expire without action. All pending schedules are canceled in cascade.
  </Accordion>
</AccordionGroup>

***

## Schedule Lifecycle

Each schedule represents one billing cycle. Schedules are created **one at a time** — the next cycle is only generated after the current one reaches a definitive state.

```mermaid theme={null}
graph TD
    A[Authorization CONFIRMED] --> B[PENDING]
    B -->|Dispatched to payment system| C[SENT]
    C -->|Payment system confirms| D[SCHEDULED]
    D -->|Next cycle schedule is created here| N[New PENDING schedule for next cycle]
    D -->|Debit executes on due date| E[PAID]
    D -->|Payment attempt fails| F[ON RETRY]
    D -->|Merchant cancels via API| G[CANCELED REQUESTED]
    F -->|Retry succeeds| E
    F -->|Retry exhausted| H[CANCELED]
    G -->|External system confirms| H
    H -->|Next cycle schedule is still created| N
    B -->|Merchant cancels via API| H
```

<Warning>
  Canceling a **schedule** does not stop future billing. The system automatically creates the next cycle schedule whenever a schedule reaches SCHEDULED or CANCELED status — as long as the authorization is still active. To permanently stop all future charges, you must **cancel the authorization**.
</Warning>

<Note>
  The schedule amount can only be updated when status is **PENDING**. Once the schedule moves beyond PENDING, only the authorization amount can be changed — and it will apply to the next cycle. See [Update Schedule](/api-reference/automatic-pix/schedules/update) for details.
</Note>

### Schedule Status Reference

| ID | Status             | Webhook | Description                                                          |
| -- | ------------------ | ------- | -------------------------------------------------------------------- |
| 1  | Pending            | No      | Created, waiting to be dispatched to the payment system              |
| 2  | Sent               | No      | Dispatched — cancellation is not possible at this point              |
| 3  | Scheduled          | ✅ Yes   | Confirmed by payment system — next cycle schedule is created         |
| 4  | On Retry           | ✅ Yes   | Attempt failed, system will retry automatically                      |
| 5  | Canceled           | ✅ Yes   | Canceled — next cycle schedule is created if authorization is active |
| 6  | Paid               | ✅ Yes   | Payment collected successfully                                       |
| 7  | Canceled Requested | No      | Cancellation sent to external system, awaiting confirmation          |

<AccordionGroup>
  <Accordion title="1 - Pending">
    **Initial status.**

    The schedule was just created. The system dispatches pending attempts up to 3 days before the due date. The amount can still be updated via API at this stage (if the authorization is variable-amount type).

    **Can be canceled**: Yes — cancellation is immediate, no external call required.

    **Next possible statuses**: Sent, Canceled
  </Accordion>

  <Accordion title="2 - Sent">
    **Intermediate status.**

    The schedule was dispatched to the external payment system. Cancellation via API is **not allowed** while in this status.

    **Next possible statuses**: Scheduled
  </Accordion>

  <Accordion title="3 - Scheduled">
    **Active status.**

    The payment system confirmed the schedule for the due date. At this point, the system automatically creates the next billing cycle's schedule (as long as the authorization `end_date` has not been reached).

    **Can be canceled**: Yes — via API, which sends a cancellation request to the external system and transitions to Canceled Requested.

    **Next possible statuses**: Paid, On Retry, Canceled Requested
  </Accordion>

  <Accordion title="4 - On Retry">
    **Intermediate status.**

    The payment attempt failed (e.g., insufficient funds) and the system is retrying automatically.

    **Next possible statuses**: Paid, Canceled
  </Accordion>

  <Accordion title="5 - Canceled">
    **Terminal status.**

    The schedule was canceled. This can happen in three scenarios:

    * **Merchant cancels a PENDING schedule via API**: immediate cancellation, next cycle schedule is created.
    * **External system returns CANCELLED or ERROR**: same behavior, next cycle schedule is created.
    * **Authorization is canceled or rejected**: cascade cancellation — no next cycle schedule is created.

    **Next possible statuses**: none (terminal)
  </Accordion>

  <Accordion title="6 - Paid">
    **Terminal status.**

    The payment was successfully collected by the payment system. The `metadata.amount` in the webhook reflects the exact charged amount.

    The next cycle schedule was already created when this schedule reached SCHEDULED status.

    **Next possible statuses**: none (terminal)
  </Accordion>

  <Accordion title="7 - Canceled Requested">
    **Intermediate status.**

    The merchant requested cancellation via API for a schedule that was already SCHEDULED or ON RETRY. The cancellation request was sent to the external payment system and is awaiting confirmation.

    **Next possible statuses**: Canceled
  </Accordion>
</AccordionGroup>

### Schedule cancellation constraints

Cancellation via API is blocked in the following conditions:

* Schedule is in **Sent** status
* Schedule is already in a final status (Paid or Canceled)
* Current time is **22:00 or later** (Brazil timezone)
* There is an **active payment attempt scheduled for today**

***

## Payin Lifecycle

When a schedule is paid, the actual money movement is tracked as a payin. Intermediate statuses are not notified — your endpoint only receives a webhook on final events.

```mermaid theme={null}
graph TD
    A[Schedule PAID] --> B[Payin created by payment system]
    B --> C[CREDITED]
    B --> D[CANCELED]
    B --> E[REJECTED]
    C -->|Webhook fired| F[Funds available]
    D -->|Webhook fired| G[No funds — payment returned]
    E -->|Webhook fired| H[No funds — rejected]
```

### Payin Status Reference

| Status   | Webhook | Description                                 |
| -------- | ------- | ------------------------------------------- |
| Credited | ✅ Yes   | Payment received and funds are available    |
| Canceled | ✅ Yes   | Payment was canceled — no funds transferred |
| Rejected | ✅ Yes   | Payment was rejected — no funds transferred |

***

## End-to-End Overview

```mermaid theme={null}
graph TD
    A[Merchant creates authorization] --> B[PENDING]
    B -->|Payer confirms QR Code| C[CONFIRMED]
    B -->|Payer declines or expires| Z[REJECTED — billing stops]
    C --> D[Schedule: PENDING → SENT → SCHEDULED]
    D -->|Due date reached| E{Payment result}
    E -->|Success| F[Schedule: PAID]
    E -->|Failure| G[Schedule: ON RETRY → PAID or CANCELED]
    F --> H[Payin: CREDITED — webhook fired]
    D -->|Next cycle pre-created on SCHEDULED| I[New Schedule: PENDING]
    I --> D
    C -->|Merchant or payer cancels| Y[CANCELED — all schedules canceled, billing stops]
```

***

## Webhook Summary

| Event                                                   | Trigger            | Webhook type          |
| ------------------------------------------------------- | ------------------ | --------------------- |
| Any authorization status change                         | All statuses       | Authorization webhook |
| Schedule reaches Scheduled, On Retry, Canceled, or Paid | Status transition  | Schedule webhook      |
| Payin credited, canceled, or rejected                   | Final payin status | Payin webhook         |

See [Webhooks](/cash-in/automatic-pix-webhooks) for full payload details and signature verification.