PSP submerchants

Payment service providers (PSPs) process on behalf of many submerchants. Clausum keeps them in a registry under your PSP organization — not as separate tenant accounts.

Requirements

Rule	Detail
Organization type	`psp` (set during onboarding)
Assess	If you have any active submerchant, `submerchant_id` is required on every `POST /api/v1/assess`
Keys	Org-level `clm_sk_` for middleware; optional scoped keys* per submerchant

Discover segment rules: GET /api/v1/assess → field_requirements_by_segment.psp.

Register submerchants

Dashboard

Connections → Merchants — register, issue scoped sandbox keys, open per-merchant protection.

Partner API (recommended for automation)

Requires org clm_sk_* with submerchants:read / submerchants:write:

curl -X POST "$CLAUSUM_API_BASE/api/v1/partner/submerchants" \
  -H "Authorization: Bearer $CLAUSUM_SECRET_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "external_id": "sm_acme_mx",
    "name": "Acme MX Store",
    "country": "MX",
    "issue_keys": { "public": true, "secret": true, "environment": "sandbox" }
  }'

Method	Path	Auth	Purpose
`GET`	`/api/v1/partner/submerchants`	Partner `clm_sk_*`	List + active keys
`POST`	`/api/v1/partner/submerchants`	Partner	Create (+ optional `issue_keys`)
`PATCH`	`/api/v1/partner/submerchants/:id`	Partner	Update, protection overrides
`DELETE`	`/api/v1/partner/submerchants/:id`	Partner	Archive + revoke scoped keys
`GET/POST/DELETE`	`/api/v1/partner/submerchants/:id/keys`	Partner	Scoped keys per child

Dashboard API (session JWT)

Same registry from the dashboard UI — requires logged-in admin:

Method	Path	Purpose
`GET`	`/api/v1/submerchants`	List (optional `?include_keys=1`)
`POST`	`/api/v1/submerchants`	Create
`PATCH`	`/api/v1/submerchants/:id`	Update + protection profile
`DELETE`	`/api/v1/submerchants/:id`	Deactivate

Scoped API keys

Each submerchant can have its own clm_sk_sbx_* / clm_pub_sbx_*. Assess with a scoped key fixes submerchant_id from the key — sending a different id returns 403. Org-level keys must pass submerchant_id on every payment.

Protection per submerchant

After registration, each child inherits your org protection template by default.

Need	Guide
Set template + propagate to all	PSP submerchant protection
Org-wide rules & blocklists	Protection workspace

Quick Partner override example:

{
  "protection": {
    "score_adjustment": 10,
    "min_decision": "review",
    "max_amount_major": 5000
  }
}

Assess with submerchant

{
  "amount": 4500,
  "currency": "USD",
  "email": "buyer@example.com",
  "submerchant_id": "sm_acme_mx",
  "order_id": "ORD-9912"
}

Use stable external_id values from your onboarding — they become the canonical submerchant_id in assess. Response may include submerchant_id and submerchant_name for reconciliation and outbound webhooks.

Configure your protection template once, propagate to all children, then customize only the merchants that need stricter or looser policy.

Get started

Integrate by client type

Solutions & prevention

Capabilities — events & ops

Dashboard

Core concepts

Reference

PSP submerchants

Requirements

Register submerchants

Dashboard

Partner API (recommended for automation)

Dashboard API (session JWT)

Scoped API keys

Protection per submerchant

Assess with submerchant

​Requirements

​Register submerchants

​Dashboard

​Partner API (recommended for automation)

​Dashboard API (session JWT)

​Scoped API keys

​Protection per submerchant

​Assess with submerchant

Requirements

Register submerchants

Dashboard

Partner API (recommended for automation)

Dashboard API (session JWT)

Scoped API keys

Protection per submerchant

Assess with submerchant