> ## Documentation Index
> Fetch the complete documentation index at: https://docs.ripio.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Identity verification in the widget

> How the widget runs KYC when your account has it enabled, and how your backend learns the outcome.

When your account has identity verification enabled, the widget runs the whole KYC flow itself — including the hand-off to the identity provider and the wait for a decision. You do not call the KYC API for widget users.

<Note>
  This flow only appears when identity verification is enabled on your account. When it is not, or when the user was verified recently enough to still be approved, the widget skips the step and goes straight to the operation. Ask your Ripio contact whether it is enabled for you — see [Partner settings](/ramps-api/widget/configuration/partner-settings).
</Note>

### What the user sees

<Steps>
  <Step title="Fill in their details">
    In **Argentina** the widget collects the data itself across four steps — name, personal information, address, and financial information. In every other country the user goes straight to the provider.
  </Step>

  <Step title="Complete verification at the provider">
    The widget hands the user to Ripio's identity provider to submit documents and a liveness check. This happens on the provider's own pages, outside the widget.
  </Step>

  <Step title="Come back and wait for the decision">
    The provider returns the user to Ripio, which re-enters the widget on a status screen. The widget polls for the outcome every 10 seconds for up to 5 minutes.
  </Step>

  <Step title="Continue, or find out it failed">
    On approval the user carries on into the operation they came for. On rejection they see a failure screen with the option to contact support.
  </Step>
</Steps>

<Note>
  Verification can outlast the 5-minute window — plenty of submissions land in manual review. When that happens the widget stops waiting and tells the user they will hear by email; the approval email arrives when the decision is made, and their next visit finds them already verified.
</Note>

### What your backend observes

Verification results reach you as [KYC Webhook Events](/ramps-api/webhooks/kyc-events), the same events an API-driven KYC produces. Two details matter for widget users:

| Field      | Value               | Why it matters                                                                                                                           |
| ---------- | ------------------- | ---------------------------------------------------------------------------------------------------------------------------------------- |
| `source`   | `"WIDGET"`          | Tells you this verification came from the widget rather than from your own API integration. An API submission carries `"API"`.           |
| `metadata` | may carry `session` | If you launched the widget with `_tracking_session`, it is echoed here, so you can tie the verification back to the session you started. |

Events arrive at the `kyc_webhook_url` configured on your account, which is separate from your main webhook URL.

<Warning>
  A verification run in the widget is a KYC that the customer holds **with Ripio**. Whether you can rely on it for your own purposes, and whether it can be reused, follows the rules in [Identity verification (KYC)](/ramps-api/kyc/overview) — not a widget-specific policy.
</Warning>