ITP - Máquina de Estados - Pix ITP

Visão Geral

O Pix ITP possui duas máquinas de estados independentes:

1. Máquina de Estados do Consentimento — ciclo de vida da autorização do usuário
2. Máquina de Estados do Pagamento — ciclo de vida de cada transação Pix

1. Máquina de Estados do Consentimento

O consentimento representa a autorização única que o usuário concede para um pagamento específico.

Diagrama

stateDiagram-v2
    direction LR

    [*] --> AWAITING_AUTHORISATION : POST /payment-initiation\n(criação)

    AWAITING_AUTHORISATION --> AUTHORISED  : Usuário aprova\n(callback recebido)
    AWAITING_AUTHORISATION --> REJECTED    : Usuário rejeita\nou timeout
    AWAITING_AUTHORISATION --> EXPIRED     : Expiração sem\ninteração

    AUTHORISED --> CONSUMED : Pix executado\n(POST /pix chamado)
    AUTHORISED --> EXPIRED  : Expiração sem\nexecução do Pix

    REJECTED --> [*]
    CONSUMED --> [*]
    EXPIRED  --> [*]

    classDef terminal fill:#f5c6c6,stroke:#c0392b,color:#333
    classDef active   fill:#c6e2f5,stroke:#2980b9,color:#333
    classDef initial  fill:#d5f5d5,stroke:#27ae60,color:#333

    class REJECTED,CONSUMED,EXPIRED terminal
    class AUTHORISED active
    class AWAITING_AUTHORISATION initial

Descrição dos Estados

Transições Válidas

2. Máquina de Estados do Pagamento

Cada transação Pix gerada via POST /pix possui seu próprio ciclo de vida no SPB (Sistema de Pagamentos Brasileiro).

Diagrama

stateDiagram-v2
    direction LR

    [*] --> PDNG : POST /pix\n(pagamento criado)

    PDNG --> ACSP : Enviado ao SPI\n(validação OK)
    PDNG --> RJCT : Falha na validação\n(consentimento, dados)

    ACSP --> ACSC : Liquidação confirmada\npelo SPI
    ACSP --> RJCT : Falha durante\na liquidação

    ACSC --> [*]
    RJCT --> [*]

    classDef terminal   fill:#f5c6c6,stroke:#c0392b,color:#333
    classDef success    fill:#d5f5d5,stroke:#27ae60,color:#333
    classDef inprogress fill:#fef9c3,stroke:#f39c12,color:#333
    classDef initial    fill:#c6e2f5,stroke:#2980b9,color:#333

    class RJCT terminal
    class ACSC success
    class ACSP inprogress
    class PDNG initial

Descrição dos Estados

Transições Válidas

Relação entre Consentimento e Pagamento

flowchart TD
    A["🔐 POST /payment-initiation\nConsentimento criado\n[AWAITING_AUTHORISATION]"]
    B["✅ Usuário aprova\n[AUTHORISED]"]
    C["💸 POST /pix\nPagamento submetido\n[PDNG → ACSP → ACSC]"]
    D["🔒 Consentimento\n[CONSUMED]"]
    E["❌ Usuário rejeita\n[REJECTED]"]
    F["⏱️ Timeout\n[EXPIRED]"]

    A --> B
    A --> E
    A --> F
    B --> C
    C --> D

    style A fill:#d5f5d5,stroke:#27ae60,color:#333
    style B fill:#c6e2f5,stroke:#2980b9,color:#333
    style C fill:#fef9c3,stroke:#f39c12,color:#333
    style D fill:#f5c6c6,stroke:#c0392b,color:#333
    style E fill:#f5c6c6,stroke:#c0392b,color:#333
    style F fill:#f5c6c6,stroke:#c0392b,color:#333

Pontos de Atenção

⚠️

Consentimento CONSUMED ≠ pagamento ACSC: O consentimento vai para CONSUMED quando o POST /pix é chamado e o pagamento é submetido, não necessariamente quando liquida. O pagamento ainda pode ser rejeitado (RJCT) mesmo com consentimento CONSUMED.

⚠️

Estados terminais são irreversíveis: Consentimentos REJECTED, CONSUMED ou EXPIRED não podem ser reativados. Um novo POST /payment-initiation e nova autorização são necessários.

⚠️

EXPIRED no consentimento: Se o usuário não completar a jornada de autorização dentro do prazo, ou se o Pix não for submetido dentro do prazo de validade do consentimento AUTHORISED, o estado vai para EXPIRED automaticamente.