Pular para o conteúdo principal

Failure scenarios

Um marketplace real esbarra em mais do que o caminho feliz. Todo cenário abaixo é código real, executado ao vivo — npm run test:scenarios em examples/marketplace-mercatto/ roda os 11 contra uma instância real e reporta passou/falhou para cada um, não apenas um status HTTP.

Onboarding​

Um vendedor sem uma Account autorizada é rejeitado, não aceito silenciosamente. Criar um pedido que nomeia uma Account de vendedor não autorizada/inexistente falha com 422 PARTICIPANT_NOT_AUTHORIZED — verificado antes mesmo da Transaction ser criada. examples/marketplace-mercatto/scenarios/onboarding-seller-without-account.ts

A alternativa a um vendedor self-service: uma Account anônima, de propriedade da Organization. Para um pagador avulso que nunca precisa do próprio login — accounts.create, sem convite, sem senha. Contraste com Seller onboarding. examples/marketplace-mercatto/scenarios/onboarding-anonymous-account.ts

Payment​

O Payment Intent de um pedido não pago expira sozinho. Um worker real de background muda o status para EXPIRED; a Transaction nunca é financiada, nunca é reservada. examples/marketplace-mercatto/scenarios/payment-intent-expires.ts

Um Late Deposit — dinheiro que chega depois que o Payment Intent já havia expirado. A Ishtaran nunca finge que isso refinancia o pedido original: o saldo Available do comprador é creditado como um evento real e separado (PaymentIntentLateDepositReceived) — a Transaction expirada nunca é reaberta nem auto-reservada. examples/marketplace-mercatto/scenarios/payment-late-deposit.ts

Um depósito menor do que o total do pedido. O PaymentIntent vai para PARTIALLY_PAID e a Transaction nunca se auto-reserva — um pagamento parcial nunca é tratado como se o pedido tivesse sido pago por completo. examples/marketplace-mercatto/scenarios/payment-partial-deposit.ts

Workflow​

Um evento de entrega registrado a partir do estado errado é rejeitado. Enviar "entregue" duas vezes — a segunda vez a partir de um estado já terminal — é negado, não aceito ou processado duas vezes silenciosamente. examples/marketplace-mercatto/scenarios/workflow-event-rejected.ts

O Settlement é bem-sucedido mesmo sem nenhum evento de entrega ter sido registrado. Prova diretamente o ponto central de Confirming delivery: esse é comportamento real e atual da plataforma, não um bug — confirmar a entrega antes de liquidar é responsabilidade do integrador, não um portão imposto pela Ishtaran. examples/marketplace-mercatto/scenarios/settlement-without-delivery-event.ts

Settlement​

Um único beneficiário recebe 100% sem nenhum Split explícito declarado. O irmão mais simples do 90/10 explícito de Creating an order — com exatamente um Participant não-pagador, BR-SPL-004 dá a ele o Distributable Amount inteiro implicitamente. examples/marketplace-mercatto/scenarios/settlement-implicit-split.ts

As duas formas reais de Split inválido, rejeitadas na criação. 90% + 20% (não soma 100%), e dois beneficiários sem split algum declarado — nenhum dos dois chega a alcançar o Settlement. examples/marketplace-mercatto/scenarios/settlement-invalid-split.ts

Uma Account de vendedor congelada no momento do Settlement. O dinheiro de um beneficiário cuja Account não pode receber no momento nunca é perdido, nunca é redistribuído silenciosamente para outra pessoa: a alocação dele é marcada RETAINED, o resto do Settlement ainda assim completa normalmente, e a liberação é reverificada do zero — rejeitada enquanto ainda congelada, bem-sucedida assim que a Account volta a ficar ativa. examples/marketplace-mercatto/scenarios/settlement-frozen-seller-account.ts

Partial Settlement, do início ao fim. Três Settlements parciais reais sobre um mesmo pedido, cada um com sua própria Fee, as transições corretas de remaining/status, e a rejeição assim que não sobra mais nada a liquidar — o exemplo completo, trabalhado, é Partial Settlement. examples/marketplace-mercatto/scenarios/settlement-partial.ts

Não construído — uma limitação real da plataforma, não um esquecimento​

Dois cenários do catálogo original de caminhos alternativos não são executáveis contra nenhum ambiente hoje sem uma espera real de 24h+ ou um bypass inseguro — ambos explicitamente descartados:

  • Cooldown de mudança de destino de saque (168h). Exige que já exista um destino Active, o que por sua vez exige que o cooldown real de ativação de 24h já tenha passado.
  • Nova tentativa de falha de broadcast de saque. Exige que um saque de fato alcance Broadcasting, mesmo bloqueio real.

O cooldown de ativação de 24h em si é coberto ao vivo — veja Withdrawal.