Where do I get the scenario secret key?

It is shown in the scenario settings in the dashboard. Keep it on your server only.

Can I rely on successCb?

Use it to update the screen. Decide on the customer from the status that your server reads.

Web SDK integration guide

This guide ties the pieces together. It assumes you have access and a scenario. If not, start with the quick start.

Overview

Where	What happens
Dashboard	You build the scenario, brand the widget, set allowed domains and the callback URL.
Your server	Creates the encrypted client key, receives the webhook, reads the session, decides.
Your page	Opens the widget with the scenario identifier and the encrypted client key.
The widget	Guides the user through the steps and sends everything to the platform.

Step 1: Prepare the dashboard

Build the scenario in the editor and note its identifier. Choose steps, documents and countries. See KYC and AML in the platform user guide.
Brand the widget on the Web SDK tab. See parameters.
Add the domain of your page to the allowed domains. See allowed domains.
In the callback settings, enter the callback URL of your backend and choose the options you need. See webhooks.
Create a permanent API token. See authentication.

Step 2: Create the encrypted client key on your server

Choose the raw client key for this person, encrypt it with the secret key of the scenario, and store the raw value with your user or order. See working with clientKey and the samples for Node.js, Python, PHP and Go.

Pass the scenario identifier and the encrypted client key to the widget. See installation for the script and the options.

window.KYCWidget.setupKYC({
  scenarioId: "<your scenario id>",
  clientKey: "<encrypted client key from your server>",
  clientUser: "<your user id>",
  closeCb: () => {},
  successCb: (sessionJson) => {},
});

Step 4: Receive the result on your server

Your server learns that the session is complete in one of two ways, and you can use both:

Webhook. The SESSION_COMPLETE event reaches your callback URL. Treat it as a signal and fetch the result by the session identifier. If you chose to omit identity fields, the SESSION_COMPLETE callback omits names, document data and images and keeps the session identifier. The check results of QUESTIONNAIRE_COMPLETE and DATABASE_CHECKS_COMPLETE are sent in full whatever the option. See receiving webhooks.
Status call. Call session status with the session identifier, or with the raw client key.

Decide on the customer from this server-side status, not from the callbacks in the browser. See session statuses.

Step 5: Read database checks

If your scenario runs database checks such as AML screening, they finish after the session. Wait for the DATABASE_CHECKS_COMPLETE event, or call database check results.

Step 6: Handle erasure and retention

When a person asks for erasure, call erase session personal data and use the data erasure log as your record. Retention is a setting you choose per scenario. See the data protection overview.

Checklist

The domain is in the allowed domains and the page is served over HTTPS.
The client key is encrypted on the server, and the secret key never reaches the browser.
The decision uses the server-side status.
The webhook endpoint answers quickly and treats the event as a signal.
You have a way to correlate the raw client key with your user.