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

Integration phases

1

Phase 1 — Organization & keys

  1. Complete PSP onboarding in Dashboard.
  2. Conexiones → Claves APISecret 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:
  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 — Intelligence & 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. Optional: Clausum intelligence network — contribute portfolio signals; request consume via account manager.
  5. If institutional module: evaluate Payout assessment for treasury flows.

Required assess fields (pay-in)

Live catalog: GET /api/v1/assessfield_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

Intelligence network

Contribute & consume signals

Capability catalog

All modules by segment