Skip to main content

1-Click Signup Guide

Time to read: 5 min

Time to implement: 1 - 4 hours

Overview

Verified Inc. enables brands to provide their users with best in class onboarding - now truly with 1-Click. This particular guide focuses on how and why to become a

A brand is a company entity that has a corresponding unique api key, name, and card image. Brands can issue, request and receive credentials to and from users.
Example: ACME Bank is an Verified Inc. customer. However, they have two separate brands: ACME Lending and ACME Savings. Each brand has a unique api key, name, and card image.
Components: Each brand has an associated umbrella customer. It is totally okay if your customer only has one brand. We want to have the flexibility to support multiple brands per customer.
brand that use's Verified Inc.'s 1-Click Signup.

This guide is outlines a more streamlined integration of the Acceptance guide.

tip

You will need an API key and phone for each user. Below is a valid API Key and URL for your initial usage.

Sandbox API Key
it6JXCP4E+j9W4oG+UyR1eJ4XNfvp8cB+lx2vxDJluo=
Sandbox URL
https://core-api.sandbox-verifiedinc.com

Because this integration requires receiving an SMS you will need to have a number to receive messages to.

Motivations

Using the 1-Click Signup flow, you will allow users to easily retrieve and verify their:

  • first and last name
  • phone number
  • email
  • address
  • birth date
  • social security number

This data is from Identity Verification Providers and is packaged in manner that allows users to share with 1-Click.

In brief: using the 1-Click the Verified Inc. network, you will gain all the benefits of being an Acceptor but with additional value…

  • Leverage identity data that always provided by a trusted identity verification provider.
  • Our fastest and easiest integration experience to get it up and running.
  • Impress 95% of United States adults with this truly 1-Click experience.

Implementation

  1. Call /1-click with the user's phone. If there is a match, will be the case for 95% of United States adults, you will get a URL value in the response body.
Example Response Body
  {
"url": "https://wallet.verified.inc/request/9f2053fc-cc4c-41cb-8d14-7d3ccf6167eb"
}
Match for 95% of United States Adults?

Yes, we have data for 95% of United States adults through our service providers. When you call /1-click using our default credential requests value we can rely on our IDV service providers having the necessary data. The accessible data incudes:

  • first name

  • last name

  • email

  • phone

  • address

  • birth date

  • social security number

The user will either have matching credentials, or they won't. If they do, continue to step (2). If they don't you should take the user through your existing verification flow.

  1. Direct the user to the url the response body contains with an additional redirectUrl query param that you define which will serve as the ultimate landing page after the user completes 1-Click IDV from the Verified Inc. web wallet. For example the final url you need to redirect the user to is:
Example Redirect to Verified Inc. Wallet URL
https://wallet.verified.inc/request/9f2053fc-cc4c-41cb-8d14-7d3ccf6167eb?redirectUrl=https://acme-bank.co/sign-up/complete
  1. Capture the sharedCredentialsUuid query param from the redirectUrl page you defined in step (2). To continue the example in step (2), the final url the user will be redirected to will be something like this:
Example Redirect Back to Acme Bank URL
https://acme-bank.co/sign-up/complete?sharedCredentialsUuid=37ce0fff-af32-457e-9458-057125eb417d
  1. Call /sharedCredentials/{uuid} from your backend with the sharedCredentialsUuid the callback URL contains. The response body will contain the credentials the user agreed to share via 1-Click IDV.
Example Response Body
{
"uuid": "d2fc31c3-8174-4e61-ab85-65be6446e8cf", // the sharedCredentialsUuid
"phone": "+14044327570",
"credentials": [
{
"id": "8743dce2-b0d3-46bd-a866-7af1b389ff0f",
"createdAt": "1703101781006",
"updatedAt": "1703101781006",
"type": "FullNameCredential",
"issuanceDate": "1703101781005",
"expirationDate": null,
"data": {
"fullName": "Richard Hendricks"
},
"issuerUuid": "e1f20210-f8a5-4f88-b760-9e34a6e65d28",
"status": "valid",
"verificationMethod": "phone_carrier"
},
{
"id": "53622515-7509-4ed1-9d70-5c3f17c148d9",
"createdAt": "1703101772943",
"updatedAt": "1703101772943",
"type": "PhoneCredential",
"issuanceDate": "1703101772943",
"expirationDate": null,
"data": {
"phone": "+14044327070"
},
"issuerUuid": "e1f20210-f8a5-4f88-b760-9e34a6e65d28",
"status": "valid",
"verificationMethod": "phone_carrier"
},
{
"id": "2a9b6f78-eaaf-4526-a131-d919d1a1d0cb",
"createdAt": "1703101781008",
"updatedAt": "1703101781008",
"type": "AddressCredential",
"issuanceDate": "1703101781006",
"expirationDate": null,
"data": {
"address": "6536 Del Playa Dr, Goleta, US-CA 93117-5117"
},
"issuerUuid": "e1f20210-f8a5-4f88-b760-9e34a6e65d28",
"status": "valid",
"verificationMethod": "phone_carrier"
},
{
"id": "46dc73e8-659e-41f8-be66-f7cedad26bd8",
"createdAt": "1703101781006",
"updatedAt": "1703101781006",
"type": "BirthDateCredential",
"issuanceDate": "1703101781005",
"expirationDate": null,
"data": {
"birthDate": "721310400000"
},
"issuerUuid": "e1f20210-f8a5-4f88-b760-9e34a6e65d28",
"status": "valid",
"verificationMethod": "phone_carrier"
},
{
"id": "e3a55df0-2245-4ec2-ad6a-64ba186a7089",
"createdAt": "1703101781006",
"updatedAt": "1703101781006",
"type": "SsnCredential",
"issuanceDate": "1703101781005",
"expirationDate": null,
"data": {
"ssn": "333224444"
},
"issuerUuid": "e1f20210-f8a5-4f88-b760-9e34a6e65d28",
"status": "valid",
"verificationMethod": "phone_carrier"
}
]
}

It's easiest to extract the data from each credential using the corresponding schema. The extracted data is verified according to the issuer of the credential, but you can perform additional verification steps if you like.

Example Application Code Credential Handling

import _ from 'lodash';

/**
* Finds value in an object that matches a property name.
* @param object
* @param propertyName
*/
export function findByPropertyName<Type>(
object: Record<string, any>,
propertyName: string
): Type | undefined {
if (_.has(object, propertyName)) {
// a hit, return the value
return object[propertyName];
}

for (const key in object) {
if (_.isArray(object[key])) {
// if the value is an array, iterate over it and recursively call this function
for (const item of object[key]) {
const result = findByPropertyName(item, propertyName);
if (result !== undefined) {
return result as Type;
}
}
}
if (_.isPlainObject(object[key])) {
// just look for the value in the object
const result = findByPropertyName(object[key], propertyName);
if (result !== undefined) {
return result as Type;
}
}
}

// no hit, return undefined
return undefined;
}

You're done!

Integration Testing

All testing and development ought to be done against our Sandbox environment. The publicly published Postman collection's Integration Test Suite is very helpful facilitating testing your Acceptor integration. All instructions below are in reference to this Postman collection. If you are more accustom to an alternative HTTP request client for development purposes, please let us know and we maybe be able to accommodate you.

To test either flavor of integration, you need to replace the acceptorBrandApiKey from the also published Public API environment variables with your brand's Sandbox API key to make the calls to /1-click and /sharedCredentials/{uuid}.

note

Some pre-configuration is necessary to test this appropriately. However, if we have already given you an ApiKey this should already be done for you. If you are unsure, please contact us.

Testing in our Sandbox environment will be returning mocked data from our IDV service providers. We can configure that data in the response to suite your needs.