Verifying an identity

Let’s assume Aussie Apps and OgnabTel are using the Negotiated flow. This is a low-level, generic flow suitable for more esoteric identity verification processes that require (possibly multiple) interactions between the merchant and payment provider. Most real-world flows will likely be simpler.

Imagine that in this flow:

1. Aussie Apps must provide OgnabTel with a site ID
2. OgnabTel uses the site ID to generate a unique redirect URL for an OgnabTel site
3. OgnabTel must send that redirect URL to Aussie Apps
4. Aussie Apps must redirect Ernie to the redirect URL to sign in to OgnabTel

After the Consumer signs in, OgnabTel can confirm their identity to the Bango Platform.

In this example, the Bango Platform and the payment provider collaborate using both the Outbound and the Inbound APIs to complete identity verification.

Here’s an overview of how it works (there’s more detail later in this guide):

1. The Bango Platform uses the Outbound API to send a notification request action to OgnabTel. This tells OgnabTel that Aussie Apps has started a Negotiated flow as part of an identity verification session. The request action contains the session ID as well as the site ID provided by Aussie Apps.
   1. The site ID is part of arbitrary data the merchant can share to the payment provider
2. OgnabTel returns an OPPA response action to the Bango Platform with the generated redirect URL
   1. The redirect URL is part of arbitrary data the payment provider merchant can share to the merchant
3. Once Ernie logs in, OgnabTel uses data from the URL to identify the identity verification session ID, and uses the inbound API to send an identity confirmation action request to the Bango Platform.
4. The Bango Platform returns a response action to OgnabTel acknowledging the confirmation.

Visually: