Skip to main content
For organization_type = psp: you process payments on behalf of many merchants. Every pay-in assess must identify which sub-merchant the transaction belongs to.

​
Modules you need

ModuleRequired?Guide
Prevention — pay-in assessYesReal-time assessment
Submerchant registryYes (if children registered)PSP submerchants
API keysYesAPI keys
Outbound webhooksRecommendedReceiving webhooks
Assess resilienceYes (prod)Assess resilience
Event ingestionRecommendedEvent ingestion
Browser SDKPer sub-merchant checkoutBrowser SDK
Payout assessIf CLM-MOD-INST / treasuryPayout assessment
Fraud networkIf contractedDashboard → Inteligencia

​
Integration phases

1

Phase 1 — Organization & keys

  1. Complete PSP onboarding in Dashboard.
  2. Conexiones → Claves API — Secret key (clm_sk_*) for server orchestration (PSP middleware).
  3. Optional Publishable keys per sub-merchant checkout if you expose SDK embeds.
2

Phase 2 — Submerchant registry

  1. Register each child merchant — PSP submerchants:
    POST /api/v1/submerchants (dashboard JWT) or UI in Conexiones.
  2. Store Clausum submerchant_id (UUID) mapped to your external_id.
  3. Rule: if your org has registered submerchants, assess must include valid submerchant_id — org-level fallback is rejected.
3

Phase 3 — Partner API orchestration

Your middleware calls assess for each payment attempt:
{
  "amount": 150.00,
  "amount_unit": "major",
  "currency": "MXN",
  "submerchant_id": "uuid-from-registry",
  "order_id": "sm-8842-checkout-001",
  "payment_id": "your-ledger-charge-id",
  "email": "payer@example.com",
  "device": { "ip": "203.0.113.5" }
}
  1. POST /api/v1/assess with clm_sk_*.
  2. Enforce decision before settling funds to the sub-merchant.
  3. Scope rules/blocklists per sub-merchant org in Clausum.
  4. Return session_id to your ledger for audit.
See Real-time assessment.
4

Phase 4 — Webhooks & ingest

  1. Configure outbound URL per environment (sandbox vs production).
  2. Route events to sub-merchant backends using submerchant_id in payload metadata.
  3. Pipe acquirer/PSP events via Event ingestion or Stripe webhooks.
5

Phase 5 — Scale & go-live

  1. Separate API keys per environment and major workloads.
  2. Assess resilience — idempotent retries with same order_id.
  3. Monitor API activity in Conexiones → Monitor.
  4. If institutional module: evaluate Payout assessment for treasury flows.

​
Required assess fields (pay-in)

FieldLevel
amount, currencyRequired
submerchant_idRequired when submerchants are registered
order_idRecommended
payment_idRecommended — your ledger charge id
device.ipRecommended on server assess
emailRecommended
Live catalog: GET /api/v1/assess → field_requirements_by_segment.psp.

​
Architecture note

​
Go-live checklist

  • All active submerchants registered with stable external_id
  • Every assess includes submerchant_id when registry is non-empty
  • Idempotency via order_id per payment attempt
  • Webhook routing tested per sub-merchant
  • Sandbox UAT on sandbox.clausum.ai before production promotion

Submerchants

Registry API and UI

Real-time assess

Pay-in API details

Webhooks

Outbound events

Capability catalog

All modules by segment