1-Click or Free IDV

Time to read: 5 min

Time to implement: 30 - 60 min

tip

You will need an API key and an email and/or phone for each user. Below is a valid API Key for your initial usage along with suggested test email and phone values.

Sandbox API Key

yVg3LEnF08y0MDmpHcPxB+sZWFcDARmPRKdY2M906ng=

Sandbox User Email

test@example.com

Sandbox User Phone

+10123456789

Verified Inc. enables 1-Click or Free ID Verification (IDV), powered by our digital ID cards.

You can implement any of the following:

Free IDV Only: You issue a digital ID card to any of your users (new or existing), and we pay you for it.
Demo of Free Only
Richard is an existing, verified Hooli user. The next time he signs in, Hooli asks him if he wants to activate his Hooli digital ID card. When he clicks the Activate button, Hooli issues the card, and Verified Inc. reimburses Hooli for the cost of the identity verification performed by Hooli for Richard.
1-Click IDV only: If a user has a digital ID card, they can verify with 1-Click. If they don't, you take them through your existing verification process (no change needed).
Demo of 1-Click Only
This demo shows Kredita using 1-Click IDV when it's available. They collect email and phone from the user (Richard) and check if the user has matching credentials. The user does, so Kredita lets them verify with 1-Click.
Both: If a user has a digital ID card, they can verify with 1-Click. If they don't, you take them through your existing verification process (no change needed) — and at the end you issue them a digital ID card, and we pay you for it.

What do you want to implement?

Free Only
1-Click Only
Both

You need to issue

A credential is a collection of data about a person. It's issued by a company and can be requested by other network participants, gated by the user's consent.

+ More...
Example: ACME Lending issues a KYC verification credential to Richard (an ACME user). This includes Richard's contact information and account numbers, as well as a level of confidence in the accuracy of the data.
Components: A company issues credentials following the steps in the Issuance Guide.

credentials to a user. When you do, Verified Inc. will pay you according to your contract.

Get user consent. Ask the user if they want to activate their digital ID card (from your brand), and include Verified Inc. legal language:
By clicking the button below, you agree to Verified Inc.’s Terms of Use and direct YOUR_COMPANY_NAME to share your personal information with Verified Inc. to provide its digital ID card services, in accordance with its Privacy Policy.
"Terms of Use" should be underlined or colored and hyperlinked to https://www.verified.inc/legal/terms-of-use. "Privacy Policy" should be underlined or colored and hyperlinked to https://www.verified.inc/legal/privacy-policy.
info
You must obtain user consent before issuing credentials. Not doing so violates our terms and will prevent us from paying you for issuing credentials.
Call /credentials with the user's verified email and/or phone and one or more credentials. For each credential, include a type and data in accordance with one of our schemas.
If we don't have a schema that suits your needs, email us and we'll make one for you.
For example, if you have a verified Social Security Number (SSN) for a user, you can issue them a SsnCredential. Just call the /credentials endpoint with the user's email and/or phone, the SsnCredential type, and the SSN data:
Example Issue Credentials Request Body
```
{
  "email": "test@example.com",
  "phone": "+10123456789",
  "credentials": [
    {
      "type": "SsnCredential",
      // based on the properties attribute of the schema
      "data": {
        "ssn": "111223333"
      },
      "expirationDate": 1893484800
    }
  ]
}
```
Format the credential data according to the properties attribute of the credential schema. In this case, the schema is for a SsnCredential which can found found at https://schema.verified.inc/jsonSchema/SsnCredential.
More information about credential schemas can be found in the Schema section.
✅ You're done!
For more detailed information on how and why to implement Free IDV, see our Free IDV Guide.

You need to check whether the user has matching

A credential is a collection of data about a person. It's issued by a company and can be requested by other network participants, gated by the user's consent.

credentials. If they do, 1-Click IDV is available.

Call /hasMatchingCredentials with the user's email and/or phone and the credential type(s) you need.
Example Response Body
```
{
    "match": true,
    "url": "https://wallet.verified.inc/request/9f2053fc-cc4c-41cb-8d14-7d3ccf6167eb"
}
```
What counts as a match?
When you call /hasMatchingCredentials, you include one or more credential requests. For each credential request, you specify:
- the type
- (optional) which issuers are acceptable
- (optional) whether the credential is required
There's a match if, for each credential request for a required credential, the user has a credential of the correct type from an acceptable issuer.
The user will either have matching credentials, or they won't. If they do, continue to step (2). If they don't, you're done with Verified Inc. and should take the user through your existing verification flow. If you would like your existing verification flow verification costs to be covered, please look into the Both section of this quick start, which includes both Free IDV and 1-Click IDV.
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
```
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
```

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": string // the sharedCredentialsUuid
    "credentials": [{
        "id": "8a1d4e35-413d-496b-b499-8810b55cfb5c",
        "type": "SsnCredential",
        "data": {
            "ssn": "111223333"
        },
        "issuanceDate": "1671847264479",
        "expirationDate": "1871839024044",
        "issuer": "32ef9562-312d-4a8b-8f3e-ccb8df500b55",
    }],
    // user's email from input to /hasMatchingCredentials
    // only present if email was provided
    "email"?: string,
    // user's phone from input to /hasMatchingCredentials
    // only present if email was provided 
    "phone"?: string
}

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.

✅ You're done!

This simply combines the 1-Click Only and Free Only options.

You need to check whether the user has matching

A credential is a collection of data about a person. It's issued by a company and can be requested by other network participants, gated by the user's consent.

credentials. If they do, 1-Click IDV is available.

If they don't, you need to issue them credentials. When you do, Verified Inc. will pay you according to your contract.

Call /hasMatchingCredentials with the user's email and/or phone and the credential type(s) you need.
Example Response Body
```
{
    "match": true,
    "url": "https://wallet.verified.inc/request/9f2053fc-cc4c-41cb-8d14-7d3ccf6167eb?email=test%40example.com&phone=%2B10123456789"
}
```
What counts as a match?
When you call /hasMatchingCredentials, you include one or more credential requests. For each credential request, you specify:
- the type
- (optional) which issuers are acceptable
- (optional) whether the credential is required
There's a match if, for each credential request for a required credential, the user has a credential of the correct type from an acceptable issuer.
The user will either have matching credentials, or they won't. If they do, continue to the Match tab of step (2). If they don't, continue to the No Match tab of step (2).

Match
No Match

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 the user is redirected to is:
Example Redirect to Verified Inc. Wallet URL
```
https://wallet.verified.inc/request/9f2053fc-cc4c-41cb-8d14-7d3ccf6167eb?email=test%40example.com&phone=%2B10123456789&redirectUrl=https://acme-bank.co/sign-up/complete
```
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
```

Example Response Body
{
    "uuid": string // the sharedCredentialsUuid
    "credentials": [{
        "id": "8a1d4e35-413d-496b-b499-8810b55cfb5c",
        "type": "SsnCredential",
        "data": {
            "ssn": "111223333"
        },
        "issuanceDate": "1671847264479",
        "expirationDate": "1871839024044",
        "issuer": "32ef9562-312d-4a8b-8f3e-ccb8df500b55",
    }],
    // user's email from input to /hasMatchingCredentials
    // only present if email was provided
    "email"?: string,
    // user's phone from input to /hasMatchingCredentials
    // only present if email was provided 
    "phone"?: string
}

✅ You're done!

Get user consent. Ask the user if they want to activate their digital ID card (from your brand), and include Verified Inc. legal language:
By clicking the button below, you agree to Verified Inc.’s Terms of Use and direct YOUR_COMPANY_NAME to share your personal information with Verified Inc. to provide its digital ID card services, in accordance with its Privacy Policy.
"Terms of Use" should be underlined or colored and hyperlinked to https://www.verified.inc/legal/terms-of-use. "Privacy Policy" should be underlined or colored and hyperlinked to https://www.verified.inc/legal/privacy-policy.
info
You must obtain user consent before issuing credentials. Not doing so violates our terms and will prevent us from paying you for issuing credentials.
Call /credentials from your backend with the user's verified email and/or phone and one or more credentials. For each credential, include a type and data in accordance with one of our schemas.
If we don't have a schema that suits your needs, email us and we'll make one for you.
For example, if you have a verified Social Security Number (SSN) for a user, you can issue them a SsnCredential to their verified phone. Just call the /credentials endpoint with the user's verified email and/or phone, the SsnCredential type, and the SSN data:
Example Issue Credentials Request Body
```
{
  "email": "test@example.com",
  "phone": "+10123456789",
  "credentials": [
    {
      "type": "SsnCredential",
      // based on the properties attribute of the schema
      "data": {
        "ssn": "111223333"
      },
      "expirationDate": 1893484800
    }
  ]
}
```
Format the credential data according to the properties attribute of the credential schema. In this case, the schema is for a SsnCredential which can found found at https://schema.verified.inc/jsonSchema/SsnCredential.
More information about credential schemas can be found in the Schema section.
✅ You're done!