Security & best practices

Blink KYC is designed so that a compromised device cannot fake a verification. These practices keep your integration that way.

The trust boundary

Your backend  ── client key + secret ── POST /api/blink/session/create ──▶  Blink
      │  ◀── { sessionId, sessionToken }
      └── sessionToken only ──▶  App / page / hosted link  ── capture ──▶  Blink
Your backend  ── GET /api/blink/session/{id}/result ──▶  the decision you act on

• The client secret never reaches a device. Sessions are created server to server.
• Every capture step is replay-resistant. Each has a fresh single-use nonce.
• Act on the result your backend reads. The device's copy is for display.

Credentials

• Keep the client key and secret in a secret manager or environment variables — not in code, images, config files shipped to devices, or source control.
• Use separate credentials for testing and production.
• If a secret may have leaked, contact Blink to replace it.

Sessions

• Create a session only for an authenticated customer, when they start verifying.
• Store sessionId against that customer, and check ownership before reading or acting on a result.
• Don't log session tokens or hosted links; treat both as secrets while valid.
• For the Web SDK, register only the origins you serve it from.

Decisions

• Only change account state after your backend reads result from the Result API.
• Give REVIEW a real manual path; don't auto-approve it.
• Keep an audit record of the sessionId, status, result and time for each decision.

Personal data

• Blink does not return extracted identity fields through the client API.
• If you download documents with the Documents API, or capture your own copies, you are responsible for encrypting them at rest, limiting access, and deleting them on schedule.
• On Android the capture screens block screenshots and screen recording by default.
• The SDKs never log document text or personal data in progress events.

Go-live checklist

• Client key and secret exist only in your backend's secret store.
• A new session is created for every attempt.
• Your backend reads /result before changing any account state.
• REVIEW has a manual path; REJECTED tells the customer what to do next.
• A background job re-reads results for sessions left IN_PROGRESS.
• Tested on real Android and iOS devices with a real document.