Skip to main content
This page explains consumer identity verification from the payment provider perspective.

​
Scenario

The source page uses an example with:
  • Aussie Apps as the merchant
  • OgnabTel as the payment provider
  • Ernie as the consumer
The example uses a Negotiated flow. This is a low-level, generic identity verification flow for cases where identity verification requires one or more interactions between merchant and payment provider. Many production flows may be simpler.

​
Example negotiated flow

In the example:
  1. Aussie Apps provides OgnabTel with a site ID.
  2. OgnabTel uses the site ID to generate a unique redirect URL for an OgnabTel site.
  3. OgnabTel sends the redirect URL back to Aussie Apps.
  4. Aussie Apps redirects Ernie to the OgnabTel URL.
  5. Ernie signs in to OgnabTel.
  6. OgnabTel confirms Ernie’s identity to the Bango Platform.

​
API collaboration

The flow uses both API directions:
  • The Bango Platform sends a notification request action to OgnabTel using the Outbound API.
  • OgnabTel responds with an OPPA response action containing the generated redirect URL.
  • After Ernie signs in, OgnabTel uses the Inbound API to send an identity confirmation request action to the Bango Platform.
  • The Bango Platform returns a response action acknowledging the confirmation.

​
Shared data

The source page notes two forms of arbitrary shared data:
  • Merchant-to-payment-provider data, such as the site ID
  • Payment-provider-to-merchant data, such as the generated redirect URL