Skip to main content
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