Stripe Identity vs Sumsub

Stripe Identity

Stripe Identity runs on the Stripe API, with a public OpenAPI spec, idempotency keys, restricted keys for sensitive fields and a redact endpoint. The product page lists £1.25 per document and selfie check, and the first 50 are free. It has no watchlist or business screening, and outside GB, JP and the US it is in public beta.

Sumsub

Per-token permissions, an IP allowlist, HMAC-signed requests and a public OpenAPI spec with Markdown docs suit an agent working on verification cases. No idempotency keys or Retry-After guidance were found, there is no server SDK, and production access needs a browser signup, a bank card and Sumsub's review of the integration.

Stripe Identity

1. Send an Idempotency-Key based on your user reference when creating a VerificationSession, so a retry doesn't make a second session
2. Send the end user the session URL or client secret. The person completes the check, the agent can't. Links expire after 48 hours
3. Use a restricted key for verified_outputs.dob and id_number. Without an IP restriction it reads them only for 48 hours
4. Wait for identity.verification_session.verified or requires_input webhooks instead of polling
5. Treat redact as irreversible, and don't put personal data in metadata

Sumsub

1. Sign every request. X-App-Access-Sig is the lowercase hex HMAC-SHA256 of timestamp, uppercase method, path with query and raw body, and the timestamp must be within one minute of server time
2. Use a sandbox token (prefix sbx) for agent work. Sandbox and production tokens are separate, and Sumsub's own skills refuse any other prefix
3. Stay under 300 GET and 50 POST requests per 5 seconds, and under 500 new applicants per 24 hours in Sandbox
4. Token permissions can't be edited after creation. Generate a new token with the narrower set and delete the old one
5. Subscribe to the applicantReviewed webhook for results and verify x-payload-digest against the raw body before trusting it