CheckoutSession registra o handshake de checkout por QR Code antes da criação do checkout. A sessão nasce sem Customer, expõe um QR Code temporário, é vinculada quando o cliente autenticado escaneia o código e só então pode confirmar uma venda por dinheiro ou crédito corporativo.
Campos
Relacionamentos
- Relaciona-se com Trip por
tripId.
- Relaciona-se com TripItinerary por
tripItineraryId, depois da preparação pelo app do cliente.
- Relaciona-se com Seat por
seatId, depois da preparação pelo app do cliente.
- Relaciona-se 1:1 com CashSettlement quando a sessão é confirmada com
paymentMethod = CASH.
- A sessão não persiste
driverId, customerId ou checkoutId.
- O usuário que cria ou cancela a sessão é auditado por
createdBy e canceledBy, sem transformar a sessão em entidade de Driver.
- O Customer é resolvido pelo User autenticado no Customer API.
- O Checkout criado pela confirmação é retorno do fluxo de confirmação.
Regras de Negócio
- A sessão é criada por um canal autenticado de venda usando o User autenticado.
- O app do cliente deve autenticar o Customer e vincular a sessão antes de qualquer confirmação de compra.
- O canal que inicia a venda seleciona a Trip e
paymentMethod; o app do cliente prepara o contexto necessário para emitir Ticket, como passageiro, itinerário, assento e crédito.
tripItineraryId, seatId, passengerDraft, requestedCreditAmount e preparedAt só são preenchidos depois que o Customer envia o contexto do ticket pelo app.
- A Trip deve estar elegível para venda pelo fluxo de QR Code e o usuário autenticado deve estar autorizado para operá-la.
- A sessão deve expirar em
expiresAt; sessões expiradas ou canceladas não podem criar Checkout.
- Apenas sessões vinculadas, preparadas, não expiradas, não canceladas e ainda não confirmadas podem ser confirmadas.
- Quando
paymentMethod = CREDIT_GRANT, a autorização e a validação de saldo acontecem no app do cliente. O canal de venda não seleciona crédito do Customer manualmente.
requestedCreditAmount é solicitação do Customer; o valor definitivo usado no checkout fica em Checkout, Order, Ticket e CreditLedgerEntry.
- Quando
paymentMethod = CASH, a confirmação significa que o dinheiro foi aceito e cria automaticamente um CashSettlement PENDING, já declarado e enviado.
- A criação do CashSettlement é idempotente por
checkoutSessionId; a mesma sessão não pode originar duas prestações.
- A confirmação cria Checkout, Order, Ticket e as reservas de assento necessárias.
- Depois da confirmação,
confirmedAt é preenchido e o Checkout criado é retornado pelo fluxo de confirmação.
- O QR Code não é estado do Checkout; o estado temporário do QR vive somente na CheckoutSession.
- O status da sessão é calculado a partir dos timestamps e não deve ser persistido.
paymentMethod = CREDIT_GRANT aqui não adiciona CREDIT_GRANT em PaymentMethod. Crédito corporativo continua sendo modelado por CreditGrant e CreditLedgerEntry.
Enums
CheckoutSessionPaymentMethod
CheckoutSessionComputedStatus
Status virtual calculado em repository/query, sem campo persistido.
Example