It's very important to test your verification rule set using both real live data and 'stubs'. Without doing this, potential problems can go unnoticed until it's too late.

About real data testing

Testing with real data means just that - inputting real people's details into the system. The results that they achieve are the same as they would be if that person was a real customer. Testing with real data means:

• you can be sure that all data is being sent to greenID in the correct field and format
• you can get a feel for how easy or hard your chosen verification rule set is to pass, and whether you have selected a good range of data sources
• you can address these things before going live

GreenID does not provide real data for testing, however, we are happy to purge your test system of all data prior to go live.

About stubs testing

Stubs testing allows various codes to be input that will force different verification results on each data source. Stubs makes it easy to use fake data to force various verification results, removing the need to find real data that can achieve all these results.

However, testing only with stubs (and not doing any real data testing) means that the actual format of the data you are sending to greenID is never tested for errors (most data fields are ignored under stubs testing). You may find too late that you are not sending the address in the correct fields, for example, because only testing with real data would pick this up.

Turning on Stubs

Stubs can be turned on via the Administration Panel. Note that stubs are only available in test they do not work in production. After logging into the Administration Panel, use the "Switch Stubs" menu item to turn stubs on and off. When stubs are "on" they are on for all users of the test site.

Different codes are available for background and interactive checks, as outlined in the following sections. In most rulesets, there is no way to completely pass a verification rule set using background sources alone. A combination of the background and interactive stubs codes must be used to achieve full verification.

Using Stubs

Existing background stubs codes will continue to work, so if you have tests with stubs codes in the middle name, they will continue to work. To use stubs 2 with background sources, a different string is required in the middle name field.

To use stubs 2, the middle name string must being with "2-". This instructs the greenID stubs manager to use stubs 2. All of the subsequent codes and examples will follow this convention.

If your input validation prohibits the use of digits or hyphens in name fields, the alternate prefix "TWO" can be used.

If a source's validation prohibits the use of digits or hyphens in name fields, then 2- will not work and "TWO" should be used. An example of this is the 'Australian Electoral Roll'.

** Please note that the stub codes are NOT case sensitive.

Using stubs for New Zealand data sources

A customer may elect to use stubs codes for New Zealand data sources. These sources use a different stubs mapping scheme. The New Zealand stubs do not require the use of stubs 2. For full details, please refer to the tables below.

Codes for background checks (Australia)

The code for background checks consists of a series of letters, each of which relate to one of the background checks. GreenID interprets this code and sends back the corresponding result. Please note there is no difference between the stubs code for a standard or a cascading background source, the same background stubs code applies.

This series of letters is sent to greenID in the middle name field. The order of these letters is extremely important to ensure the right verification outcome. The order is defined as below:

2-FFFPPFFFFFFFFF

TWOFFFPPFFFFFFFFF

FFFFFFPF

Full or Partial Data Matches in Stubs

Testing greenID alert Responses

greenID alerts must be configured within your account to enable testing of its outcomes. 

Testing uses a combination of the 16th letter of middle name as well as the <deviceIDData> field to control the results. The 16th letter in the middle name drives the overall response and the <deviceIDData> field determines the number of RCF codes that are returned. 

Accepted values for 16th letter of the middle name are:

A - for an accept pass  (greenID alert specific)

D - for a deny fail (greenID alert specific)
C - for a challenge fail  (greenID alert specific)
F - a standard fail, same as any other source
P - a standard pass, same as any other source
E - for error, e.g. greenID can not make the call to redshield

An example of the middle name field which would drive a DENY response is 2-FFFFFFFFFFFFFFFD.

RCF codes indicate the rules that were triggered during the greenID alert check. The number of RCF codes returned for a challenge or deny response is determined by the number in the <deviceIDData> attribute.

Accepted values for <deviceIDData> attribute are:
11111111- a single predetermined RCF code will be returned
22222222 - two predetermined RCF codes will be returned
33333333 - three predetermined RCF codes will be returned
44444444 - four predetermined RCF codes will be returned
55555555 - five predetermined RCF codes will be returned

Testing GBG Trust: Alert (stubs mode)

GBG Trust: Alert must be configured on your GBG Alert account to enable testing this feature. With stubs mode enabled, in the middle name, send a ‘27^th’ character with ‘P’, ‘E’ or ‘F’.

 All configured active rules for the account / ruleID will trigger.

Testing GBG Trust: Alert (non-stubs mode)

GBG Trust: Alert must be configured on your GBG Trust: Alert account to enable testing this feature. Please note:

• these rules and a corresponding verification block will only occur if these are configured to your greenID account
• Use this as an alternative, if you are unable to stubs mode to test GBG Trust: Alert

The following identities can be used to raise Rules B1 and B2 in Test:

Visa Entitlement Check 

As the visa entitlement check does not contribute to verification outcomes, stubs code will result in the following results: