Page Comparison

...

1. Call registerVerification with the person's basic details.  Some background sources may pass, but the person requires further verification.
2. Call getSources to fetch a list of sources that will help the person become verified.  The person selects "Medicare card" as the next data source they wish to attempt.
3. Call getFields for the "Medicare card" data source (source ID "medicare"), and present the person with input fields for the required data.
4. Call setFields for the "Medicare card" data source with the data supplied by the person.  The result indicates the person requires further verification, and includes a list of sources that will help the person complete their verification.  The person selects "NSW drivers' licence" as the next data source they wish to attempt.
5. Call getFields for the "NSW driver's licence" data source (source ID nswrego), and present the person with input fields for the required data.
6. Call setFields for the "NSW driver's licence" data source with the data supplied by the person.  The result indicates the person has completed their verification, so the process ends here.

...

1. Call registerVerification with the person's basic details.  Some background sources may pass, but the person requires further verification.
2. Call setFields for the "Medicare card" data source with the data supplied by the person.  The result indicates the person requires further verification, and includes a list of sources that will help the person complete their verification.  The person selects "NSW drivers' licence" as the next data source they wish to attempt.
3. Call setFields for the "NSW driver's licence" data source with the data supplied by the person.  The result indicates the person has completed their verification, so the process ends here.

Complete example with a combination source

The sequence of calls and events below illustrate a full scenario where a combination source is used.  The scenario assumes that greenID scan has been integrated into a customer's verification journey, and is invoked at the appropriate point in the customer's workflow.

1. The person downloads and installs the customer's application, which includes the greenID Mobile SDK.
2. The person starts the onboarding workflow.
3. The person selects the ID document they wish to photograph.
4. The person captures an image of the front and back of their ID document.  The images are uploaded to greenID and checked for authenticity, integrity and digital tampering.
5. The person captures a selfie.  The selfie is uploaded to greenID and compared against the image extracted from the ID document.
6. The details that were automatically extracted from the ID document are presented to the person for confirmation.  The person corrects any errors and submits the details.
7. The master record is created at greenID and watchlists and background sources (if configured) are checked.  The details from the ID document are also checked.  The level of verification achieved is sufficient to satisfy the rule the customer has configured on their greenID account.
8. The greenID Mobile SDK hands off to the controlling application.
9. The customer's mobile application sends the details to the customer's back-end application, which uses the verificationToken (received from the greenID Mobile SDK at handoff) to query the results of the verification process by calling getVerificationResult.
10. The customer's back-end application communicates with their native mobile application to determine the next step in the workflow for the person, based on the results of the verification process.

Complete example with a combination source (returning user)

1. Call registerVerification with the person's basic details.  Some background sources may pass, but the person requires further verification.
2. The customer's back-end application stores the verificationId and associated it with their record for the person.
3. The customer's back-end application generates some form of token or code and associates it with the verificationId.
4. Direct the person to resume the verification process using the customer's native mobile app.
5. The person resumes the verification process using the customer's native mobile app by entering the token or code generated in step 3.
6. The native mobile app sends the token or code to the back-end application, which finds the associated verificationId and uses it to call getGreenIdWebVerificationToken (TODO - add link).  The verificationToken is passed back to the native mobile app.
7. The native mobile app initialises the greenID Mobile SDK in "returning user" mode and supplies the greenIdWebVerificationToken.
8. The greenID Mobile SDK guides the person through the rest of the verification process.  The person achieves a level of verification sufficient to satisfy the rule the customer configured on their greenID account.
9. The greenID Mobile SDK hands off to the controlling application.
10. The customer's mobile application sends the details to the customer's back-end application, which uses the verificationToken to query the results of the verification process by calling getVerificationResult.
11. The customer's back-end application communicates with their native mobile application to determine the next step in the workflow for the person, based on the results of the verification process.

Example with GBG Trust: Alert Only

1. Call registerVerification with the person's basic details. Any alerts raised will be returned in the verificationResult section of the response.
2. Call getVerificationResult to query the result.