Saltar al contenido principal

Architecture

La secuencia completa​

Alice/BobMercatto (SDK)Ishtaran APISandbox1. auth.signUp()OrganizationTenancy — org+app+env+key, una sola llamada2. accounts.createAccountHolderInvitation() ×23. accountHolders.signUpAndClaimInvitation()Accounts — cada uno reclama su propia sesión4. accounts.authorizeApplication() ×3Requiere sesión de Member — GAPS.md §F.95. workflows.create/createVersion/createRule/publishVersionWorkflowRules — AguardandoEntrega → Entregue6. transactions.create(alice, bob 90%, mercatto 10%)Transactions — BR-SPL-004 exige este split explícito7. deposits.createPaymentIntent()Deposits — devuelve una dirección de depósito real8. sandbox.simulateDeposit() + simulateConfirmation()La Transaction se reserva sola — sin llamar a reserve()9. events.ingest("ProdutoEntregue")WorkflowRules — rastro de auditoría, NO una compuerta de Settlement10. settlements.executeSettlement()Se construye el SigningRequest — se firma, se confirma, y luego se registra el Ledger (DEC-037)11. ledger.getBalance(bob)Ledger — Mercatto lo lee en nombre de Bob (GAPS.md §F.10)12. withdrawals.createDestination() + request()422 WITHDRAWAL_DESTINATION_NOT_USABLE — cooldown real de 24h, no se saltaFlechas sólidas = requests · punteadas = respuestas/eventos · código fuente completo en el enlace de SDK de cada paso
Los 12 pasos corrieron de verdad contra una instancia en vivo durante la validación de este Business Case — ver Run it yourself para reproducirlos.

Mapa de métodos​

Cada llamada real que usa este Business Case, y qué módulo de Ishtaran es dueño de ella:

PasoLlamada del SDKMóduloCapítulo
Registroauth.signUp(...)OrganizationTenancySetup
Invitar + reclamaraccounts.createAccountHolderInvitation, accountHolders.signUpAndClaimInvitationAccountsSeller onboarding
Autorizaraccounts.authorizeApplicationAccountsSeller onboarding
Workflowworkflows.create/createVersion/createRule/publishVersion, eventTypes.createWorkflowRulesCreating an order
Pedidotransactions.createTransactionsCreating an order
Pagodeposits.createPaymentIntent/getPaymentIntentDepositsAccepting payment
Fondeo simuladosandbox.simulateDeposit/simulateConfirmationSandboxHolding funds
Evento de entregaevents.ingestWorkflowRulesConfirming delivery
Settlementsettlements.executeSettlement, signingRequests.get/submitSignedTransaction, sandbox.simulateBroadcastConfirmationSettlement → ExecutionCustody → LedgerSettlement and Split
Balanceledger.getBalanceLedgerSeller balance
Retirowithdrawals.createDestination/quote/requestWithdrawalsWithdrawal

Dos reglas reales de autorización que conviene saber desde el principio​

  • Algunas llamadas necesitan la sesión de Member de Mercatto, no su API Key. accounts.authorizeApplication, cada mutación de workflows.*, y events.ingest rechazan hoy una Application API Key (confirmado en vivo). Los ejemplos de Mercatto mantienen dos clientes — owner (Member) y mercatto (API Key) — justo por esta razón. Ver Known Limitations §F.9.
  • Los logins propios de Bob y Alice son solo para identidad. Una vez que reclaman su invitación, su propia sesión no puede llamar a Ledger, Settlement, ni Withdrawals — todo eso requiere las credenciales propias de Mercatto. Mercatto lee el balance de Bob y solicita su retiro en su nombre, de la misma manera que lo haría un backend real de marketplace. Ver Known Limitations §F.10.