/addresses y /payment-intents cae en uno de dos flujos, decidido por si pasas external_ref:
Direct flow (external_ref omitido) | Whitelabel flow (external_ref seteado) | |
|---|---|---|
| Quién es el target del crédito | Tu organización partner | Un “partner profile” per-usuario que minteamos al primer contacto |
| Dónde vive la fila de dirección | organization_addresses | user_addresses (joineado con tu org vía connect_external_refs) |
| Dónde aterriza el crédito | organization_assets | user_assets del perfil partner |
Forma de GET /balances | Agregado por tu org | Agregado AND per-usuario al filtrar por external_ref |
La respuesta hace echo de external_ref | No (campo ausente) | Sí |
Cuándo usar cada uno
Direct flow es lo correcto cuando estás cobrando para ti — tu dashboard, tu contabilidad, sin atribución de usuario final. El depósito acredita el balance de tu org igual que un depósito vía ui-web o WhatsApp. Whitelabel flow es lo correcto cuando operas un producto multi-tenant y necesitas atribución per-usuario — suministra tu id estable de usuario comoexternal_ref y trackeamos el balance, direcciones, y transacciones de ese usuario por separado. Al primer contacto con un external_ref, minteamos perezosamente un perfil partner-usuario interno; llamadas subsiguientes con el mismo external_ref convergen al mismo perfil (idempotente sobre (organization_id, external_ref)).
Coexisten en la misma clave
Los dos flujos pueden coexistir bajo la misma clave — pasaexternal_ref en las llamadas donde la atribución importa y omítelo donde no. GET /balances devuelve la unión (org-level + cada partner-usuario) para que veas un solo número que es verdad para todo el tenant.