Skip to main content
For organization_type = comercio: you accept payments on your own behalf (e-commerce, app checkout, subscription billing). Your integration centers on pay-in assess before capture.

​
Modules you need

ModuleRequired?Guide
Prevention — pay-in assessYesReal-time assessment
API keysYesAPI keys
Browser SDKRecommendedBrowser SDK
Outbound webhooksRecommendedReceiving webhooks
Assess resilienceYes (prod)Assess resilience
Stripe / ingest (post-payment)OptionalStripe webhooks · Event ingestion
Report fraudWhen fraud confirmedReport fraud
Cases & operationsIf CLM-MOD-OPSCase management
Payout assessNo—
SubmerchantsNo—

​
Integration phases

1

Phase 1 — Keys & sandbox

  1. Conexiones → Claves API — create Publishable (clm_pub_*) and Secret (clm_sk_*) with Assess permission.
  2. Run Quickstart against sandbox.
  3. Exercise scenarios in Simulación — Simulation guide.
2

Phase 2 — Checkout prevention

Recommended pattern: browser SDK for device signals → server assess with clm_sk_* before PSP capture.
  1. Embed Browser SDK on checkout.
  2. On payment submit, your backend calls POST /api/v1/assess with:
    • amount, currency (decimal major preferred — see assess guide)
    • order_id (stable idempotency key)
    • device.ip from the HTTP request
    • email or customer_id
    • payment_method (BIN/last4 for card rules)
    • session_id from SDK when available
  3. Branch on decision: proceed only on approve (or your policy for review / challenge).
  4. Your server calls Stripe / Mercado Pago / your PSP — Clausum does not capture for you.
See Architecture — protection loop.
3

Phase 3 — Async notifications

  1. Conexiones → Entrada (webhooks) — set outbound URL.
  2. Subscribe to transaction.created and transaction.blocked.
  3. Verify X-Clausum-Signature — Receiving webhooks.
  4. Put clausum_session_id in PSP metadata when capturing.
4

Phase 4 — Post-payment (optional)

Connect provider events for disputes and reconciliation:Post-payment ingest does not replace checkout assess.
5

Phase 5 — Operations & go-live

  1. Configure Protection — rules, blocklists, thresholds.
  2. Implement Assess resilience fail-open policy for 503 / 504.
  3. Train team on Transaction monitor.
  4. On confirmed fraud → Report fraud.
  5. Production keys on https://dashboard.clausum.ai (or your assigned host).

​
Required assess fields (pay-in)

FieldLevel
amount, currencyRequired
order_idRecommended — idempotency and webhooks
device.ipRecommended on server assess
email or customer_idRecommended
payment_methodRecommended (card BIN rules)
submerchant_idNot used
Discover live requirements: GET /api/v1/assess → field_requirements_by_segment.merchant.

​
Go-live checklist

  • Server-side assess with clm_sk_* before every capture
  • Stable order_id per checkout attempt
  • Outbound webhook URL tested in sandbox
  • Resilience policy documented for maintenance / timeout
  • Team roles assigned — Team & access
  • Rate limits understood — Rate limits

​
Next capability deep-dives

Real-time assess

Payload, decisions, amounts

Browser SDK

Device fingerprinting

Webhooks

Signatures and events

All capabilities

Module catalog by segment