How sessions work
Learn about the status and lifecycle of VerificationSessions.
Asynchronous verification flows are complex to manage because they depend on customer interactions that happen outside your application. VerificationSessions simplify this by keeping track of the status of the verification flow.
When the VerificationSession is created, it has a status of requires_ and is ready for your user to begin the verification process. We recommend creating the VerificationSession right before the start of the verification flow.
As soon as the user submits the session, the VerificationSession moves to processing. Most verification checks are processed in less than 1 minute.
A VerificationSession with a status of verified means that the verification flow is complete. Processing of all the verification checks are complete and successfully verified.
If any of the verification checks fail (for example, because of a manipulated document), the VerificationSession’s status returns to requires_. You can find an explanation for the verification failure in the last_ field of the session. If you want your user to attempt verification again, you need to Retrieve the VerificationSession to get a fresh URL or client secret. Details provided by the provided_ field might be shown to your user.
You may cancel a VerificationSession at any point before it’s processing or verified. This invalidates the VerificationSession for future submission attempts, and can’t be undone.
Session events
Events are created every time a session changes status. Here’s a complete list of the VerificationSession event types:
| Event type | Description |
|---|---|
identity. | The session was created. |
identity. | The user has successfully submitted their information, and verification checks have started processing. |
identity. | Processing of all the verification checks have completed, and they’re all successfully verified. |
identity. | Processing of all the verification checks have completed, and at least one of the checks failed. |
identity. | The session has been cancelled and future submission attempts have been disabled. This event is sent when a session is cancelled or redacted. |
identity. | The session was redacted. You must create a webhook endpoint which explicitly subscribes to this event type to access it. Webhook endpoints which subscribe to all events will not include this event type. |
You might want to take action in response to certain events, such as emailing your user when a verification fails or succeeds.
Stripe recommends that you listen for events with webhooks.