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
- Complete PSP onboarding in Dashboard.
- Connections → API keys — Secret key (
clm_sk_*) for server orchestration (PSP middleware). - Optional Publishable keys per sub-merchant checkout if you expose SDK embeds.
2
Phase 2 — Submerchant registry
- Register each child merchant — PSP submerchants:
POST /api/v1/partner/submerchants(Partner API) or Connections → Merchants. - Store Clausum
external_idmapped to your ledger — it becomessubmerchant_idin assess. - Rule: if your org has registered submerchants, assess must include valid
submerchant_id.
3
Phase 2b — Protection template
- Open Merchants → Template & propagation — set thresholds, alerts, score adjustment.
- Save and propagate to apply to all non-customized children.
- Customize individual merchants only when needed — PSP submerchant protection.
4
Phase 3 — Partner API orchestration
Your middleware calls assess for each payment attempt:
POST /api/v1/assesswithclm_sk_*.- Enforce
decisionbefore settling funds to the sub-merchant. - Per-submerchant protection inherits your org template — customize in Submerchant protection.
- Return
session_idto your ledger for audit.
5
Phase 4 — Webhooks & ingest
- Configure outbound URL per environment (sandbox vs production).
- Route events to sub-merchant backends using
submerchant_idin payload metadata. - Pipe acquirer/PSP events via Event ingestion (
clm_wh_*— default; no payment-brand catalog). Optional Stripe guide only if you need the native adapter.
6
Phase 5 — Intelligence & go-live
- Separate API keys per environment and major workloads.
- Assess resilience — idempotent retries with same
order_id. - Monitor API activity in Connections → Monitor.
- Optional: Clausum intelligence network — contribute portfolio signals; request consume via account manager.
- If institutional module: evaluate Payout assessment for treasury flows.
Required assess fields (pay-in)
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_idwhen registry is non-empty - Idempotency via
order_idper payment attempt - Webhook routing tested per sub-merchant
- Sandbox UAT on
sandbox.clausum.aibefore production promotion
Capability links
Submerchant protection
Template, propagate, customize
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