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
This guide is outlines a more streamlined integration of the Acceptance guide.
You will need an API key and phone for each user. Below is a valid API Key and URL for your initial usage.
it6JXCP4E+j9W4oG+UyR1eJ4XNfvp8cB+lx2vxDJluo=
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
- 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
- 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.
{
"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.
- Direct the user to the
url
the response body contains with an additionalredirectUrl
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:
https://wallet.verified.inc/request/9f2053fc-cc4c-41cb-8d14-7d3ccf6167eb?redirectUrl=https://acme-bank.co/sign-up/complete
- Capture the
sharedCredentialsUuid
query param from theredirectUrl
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:
https://acme-bank.co/sign-up/complete?sharedCredentialsUuid=37ce0fff-af32-457e-9458-057125eb417d
- Call
/sharedCredentials/{uuid}
from your backend with thesharedCredentialsUuid
the callback URL contains. The response body will contain the credentials the user agreed to share via 1-Click IDV.
{
"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}
.
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.