Failure scenarios
Un marketplace real enfrenta más que el camino feliz. Cada escenario abajo es código real,
ejecutado en vivo — npm run test:scenarios en examples/marketplace-mercatto/ corre los 11
contra una instancia real y reporta pass/fail para cada uno, no solo un código de estado HTTP.
Onboarding
Un vendedor sin una Account autorizada es rechazado, no aceptado en silencio.
Crear un pedido que nombre una Account de vendedor no autorizada/inexistente falla con
422 PARTICIPANT_NOT_AUTHORIZED — verificado antes de que la Transaction siquiera se cree.
examples/marketplace-mercatto/scenarios/onboarding-seller-without-account.ts
La alternativa a un vendedor self-service: una Account anónima, propiedad de la Organization.
Para un pagador ocasional que nunca necesita su propio login — accounts.create, sin invitación,
sin contraseña. Compárese con Seller onboarding.
examples/marketplace-mercatto/scenarios/onboarding-anonymous-account.ts
Payment
El Payment Intent de un pedido sin pagar expira por sí solo.
Un worker real de background lo cambia a EXPIRED; la Transaction nunca se financia, nunca se
reserva.
examples/marketplace-mercatto/scenarios/payment-intent-expires.ts
Un Late Deposit — dinero que llega después de que el Payment Intent ya expiró.
Ishtaran nunca finge que esto refinancia el pedido original: el balance Available del comprador se
acredita como un evento real y separado (PaymentIntentLateDepositReceived) — la Transaction
expirada nunca se reabre ni se reserva automáticamente.
examples/marketplace-mercatto/scenarios/payment-late-deposit.ts
Un depósito por menos del total del pedido.
El PaymentIntent pasa a PARTIALLY_PAID y la Transaction nunca se reserva automáticamente — un
pago parcial nunca se trata como si el pedido se hubiera pagado por completo.
examples/marketplace-mercatto/scenarios/payment-partial-deposit.ts
Workflow
Un evento de entrega ingerido desde el estado equivocado es rechazado.
Enviar "entregado" dos veces — la segunda vez desde un estado ya terminal — es denegado, no
aceptado ni procesado dos veces en silencio.
examples/marketplace-mercatto/scenarios/workflow-event-rejected.ts
El Settlement tiene éxito sin que se haya ingerido nunca un evento de entrega.
Demuestra directamente el punto central de Confirming delivery: esto es
comportamiento real y actual de la plataforma, no un bug — confirmar la entrega antes del
settlement es responsabilidad del integrador, no una compuerta impuesta por Ishtaran.
examples/marketplace-mercatto/scenarios/settlement-without-delivery-event.ts
Settlement
Un único beneficiario recibe el 100% sin ningún Split explícito declarado.
El hermano más simple del 90/10 explícito de Creating an order — con
exactamente un Participant que no es el pagador, BR-SPL-004 le da implícitamente todo el
Distributable Amount.
examples/marketplace-mercatto/scenarios/settlement-implicit-split.ts
Ambas formas reales de Split inválido, rechazadas al crear.
90% + 20% (no suma 100%), y dos beneficiarios sin ningún split declarado — ninguno de los dos
llega jamás al Settlement.
examples/marketplace-mercatto/scenarios/settlement-invalid-split.ts
Una Account de vendedor congelada al momento del Settlement.
El dinero de un beneficiario cuya Account no puede recibir en ese momento nunca se pierde, nunca
se redistribuye en silencio a alguien más: su asignación se marca como RETAINED, el resto del
Settlement igual se completa normalmente, y la liberación se vuelve a verificar en fresco —
rechazada mientras sigue congelada, tiene éxito una vez que la Account vuelve a estar activa.
examples/marketplace-mercatto/scenarios/settlement-frozen-seller-account.ts
Partial Settlement, de principio a fin. Tres Settlements parciales reales sobre un mismo
pedido, cada uno con su propio Fee, transiciones correctas de remaining/status, y rechazo una
vez que no queda nada por hacer settlement — el ejemplo completo trabajado está en
Partial Settlement.
examples/marketplace-mercatto/scenarios/settlement-partial.ts
No construido — una limitación real de la plataforma, no un descuido
Dos escenarios del catálogo original de caminos alternativos no son ejecutables hoy contra ningún entorno sin una espera real de 24h+ o un bypass inseguro — ambos explícitamente descartados:
- Cooldown de cambio de destino de retiro (168h). Requiere que ya exista un destino
Active, lo cual a su vez requiere que haya transcurrido el cooldown real de activación de 24h. - Reintento de fallo de broadcast en un retiro. Requiere que un retiro realmente llegue a
Broadcasting, el mismo bloqueo real.
El cooldown de activación de 24h en sí sí está cubierto en vivo — ver Withdrawal.