Skip to main content
Para organization_type = psp: procesas pagos en nombre de muchos comercios. Cada assess pay-in debe identificar a qué subcomercio pertenece la transacción.

​
Módulos que necesitas

​
Fases de integración

1

Fase 1 — Organización y claves

  1. Completa el onboarding PSP en el Panel de Control.
  2. Conexiones → Claves API — clave Secret (clm_sk_*) para orquestación en servidor (middleware PSP).
  3. Claves Publishable opcionales por checkout de subcomercio si expones embeds del SDK.
2

Fase 2 — Registro de subcomercios

  1. Registra cada comercio hijo — Subcomercios PSP:
    POST /api/v1/partner/submerchants (Partner API) o Conexiones → Comercios.
  2. Guarda el external_id de Clausum mapeado a tu ledger — se convierte en submerchant_id en assess.
  3. Regla: si tu org tiene subcomercios registrados, assess debe incluir un submerchant_id válido.
3

Fase 2b — Plantilla de protección

  1. Abre Comercios → Plantilla y propagación — define umbrales, alertas, ajuste de score.
  2. Guardar y propagar para aplicar a todos los hijos no personalizados.
  3. Personaliza comercios individuales solo cuando sea necesario — Protección de subcomercios PSP.
4

Fase 3 — Orquestación Partner API

Tu middleware llama assess por cada intento de pago:
  1. POST /api/v1/assess con clm_sk_*.
  2. Aplica decision antes de liquidar fondos al subcomercio.
  3. La protección por subcomercio hereda tu plantilla de org — personaliza en Protección de subcomercios.
  4. Devuelve session_id a tu ledger para auditoría.
Consulta Assess en tiempo real.
5

Fase 4 — Webhooks e ingest

  1. Configura URL saliente por entorno (sandbox vs producción).
  2. Enruta eventos a backends de subcomercios usando submerchant_id en metadatos del payload.
  3. Canaliza eventos de adquirente/PSP vía Ingest de eventos (clm_wh_* — por defecto; sin catálogo de marcas). Guía opcional Stripe solo si necesitas el adaptador nativo.
6

Fase 5 — Inteligencia y go-live

  1. Claves API separadas por entorno y cargas de trabajo principales.
  2. Resiliencia de assess — reintentos idempotentes con el mismo order_id.
  3. Monitorea actividad de API en Conexiones → Monitor.
  4. Opcional: Red de inteligencia Clausum — contribuye señales de cartera; solicita consumo vía account manager.
  5. Si módulo institucional: evalúa Assess de payout para flujos de tesorería.

​
Campos obligatorios de assess (pay-in)

Catálogo en vivo: GET /api/v1/assess → field_requirements_by_segment.psp.

​
Nota de arquitectura

​
Checklist de go-live

  • Todos los subcomercios activos registrados con external_id estable
  • Cada assess incluye submerchant_id cuando el registro no está vacío
  • Idempotencia vía order_id por intento de pago
  • Enrutamiento de webhooks probado por subcomercio
  • UAT en sandbox en sandbox.clausum.ai antes de promoción a producción

​
Enlaces de capacidades

Protección de subcomercios

Plantilla, propagar, personalizar

Subcomercios

API de registro e interfaz

Assess en tiempo real

Detalles de API pay-in

Webhooks

Eventos salientes

Red de inteligencia

Contribuir y consumir señales

Catálogo de capacidades

Todos los módulos por segmento