Address Verification

In addition to the general address lookups, the Checkin.com Framework is also integrated with different services for strong person and address authentication in many countries.

With this functionality turned on, the user object in both regilyUpdateCallback and regilyDoneCallback will contain an additional property with JWT token signing called proofOfAddress.result which can be either true or false.

What do you need to add to your standard Checkin.com integration?

Once the service is enabled, an additional property called proofOfAddress will be added to the user callback data. Depending on the result from the provider, it will be true or false and this field should be captured and saved together with the other user data.

For additional security, it is also recommended to run server-side validations on the signed JWT token before the user data is saved. You can find information on how to handle a JWT token here.

Do you want to use our proof of address integration?

Reach out to [email protected] and we will switch this service on for you

Address verification data

Here is an example of the data added as part of the address validation. All data is signed and non-personal parts of the response is added as proofOfAddress to the regilyUpdateCallback and regilyDoneCallback.

regilyDoneCallback.data:
{
  credentials... ,
  mapped... ,
  user... , 
  proofOfAddress:  {
     result: true, // true/false , result of match to address lookup 
     authenticatorSpecificData: { ... }, // (see "Authenticator specific information")
     jwtSignData: 'DSFAWERQWEZADXASDFQWER....' (jwt signed data of all above)
   }
}

The jwtSignData will always contain a signed copy of all the data. The unsigned data can be used in the frontend without additional libraries, while token verification can be done on the backend for security purposes.

Authenticator specific information

The Checkin.com Framework is integrated with several providers in different countries and markets. These providers will send unique information depending on the type of lookup utilized.

This information will be part of proofOfAddress.authenticatorSpecificData and can be used for additional logging, tracking and validations.

The example below shows the specific data provided by German Post authentications:

// ------ EXAMPLE DATA IN authenticatorSpecificData, relayed from address-proof-lookup ------
{
 "PDStatusCodeItem": {
        "ModuleCodes": [
          {
            "attributes": {
              "name": "BAC"
            },
            "StatusCode": [
              "BAC010102",
              "BAC140107",
              "BAC010107",
              "BAC144107",
              "BAC104107"
            ]
          },
          {
            "attributes": {
              "name": "FNC"
            },
            "StatusCode": "FNC030102"
          },
          {
            "attributes": {
              "name": "PDC"
            },
            "StatusCode": [
              "PDC030105",
              "PDC050500",
              "PDC040500"
            ]
          }
        ]
      }
 }