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. Connections → API keys — 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/partner/submerchants (Partner API) or Connections → Merchants.
  2. Store Clausum external_id mapped to your ledger — it becomes submerchant_id in assess.
  3. Rule: if your org has registered submerchants, assess must include valid submerchant_id.
3

Phase 2b — Protection template

  1. Open Merchants → Template & propagation — set thresholds, alerts, score adjustment.
  2. Save and propagate to apply to all non-customized children.
  3. Customize individual merchants only when needed — PSP submerchant protection.
4

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. Per-submerchant protection inherits your org template — customize in Submerchant protection.
  4. Return session_id to your ledger for audit.
See Real-time assessment.
5

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 (clm_wh_* — default; no payment-brand catalog). Optional Stripe guide only if you need the native adapter.
6

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 Connections → 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/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

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