Registering a user

Owned by Deborah Cross (Unlicensed)
Last updated: Oct 20, 2019 by Murat Altikulac (Unlicensed)


iFrame Deprecated

iFrame integration was deprecated in January 2015.

New customers should integrate using either greenID Web or greenID API. Existing customers are encouraged to upgrade the integration method - contact support to find out more.

This documentation remains to support existing customers with an iFrame integration.

Method Summary

The registerUser method is the first method that must be called when a verification of an individual is required (or one of the alternative methods described below). This method establishes a registration with greenID that can be used as the basis of further checks.

Some automatic (“non-consent”) checks, including Watchlist checks, can also be performed if the customer’s rules require it. The results of these checks will be returned in the RichVerificationResult object.   

Method Signature 

RichVerificationResult registerUser( String customerId,  
     String userId,  
     String ruleId,  
     Name name,  
     String email,  
     AusAddress currentResidentialAddress,  
     AusAddress previousResidentialAddress,  
     Date dob,  
     String homePhone,  
     String workPhone,  
     String mobile,  
     nameValuePair[] extraData)


Parameters


NameTypeRequired?DescriptionContract
customerId

String

255 Chars		YesThis parameter is GreenID's identifier for the client application.  The value is supplied by GreenID, and must be included with each registration request.Must be a valid identifier issued by GreenID. 
userId

String

255 Chars		YesThis parameter is an identifier that the client uses for the individual being verified. GreenID does not use it as an identifier, but in order to easily locate individual's for a particular client application, the userId is used. This can be anything the client likes, and if it is not specified, then GreenID will issue an identifier.

May be any string, null or the empty string.

If present, must be unique among all the users for a given client application.
ruleId

String

255 Chars		YesSpecifies the predefined verification rule that this registration will be run against.

Must be a string and must match a predefined rule string specified in the system. In almost all cases you should use the ruleId "default".  Other values can only be used when your customer account has multiple rulesets configured for it.


NB: you should not use a rule ID like 'A' or 'F' here unless there is a ruleId specially configured for your account that has that name. 
email

String

255 Chars		NoThe user’s email address.

Must be a valid email address following the Standard Hibernate validation and checking Top Level Domain (TLD) is valid. See https://data.iana.org/TLD/tlds-alpha-by-domain.txt

addressAusAddressYesA complex type encapsulating the user’s address. Not null.  

There is a configuration option that can be used to make the address field optional for this web service call and/or the admin panel user registration screens.  Let us know and we can configure this for your site.
previousAddressAusAddressNoA complex type encapsulating the user’s previous address. 
nameNameYesA complex type encapsulating the user’s name. Not null.
dobDateNoThe user’s date of birth. If present, the date must be in the past. If the DOB is missing, it is assumed that the person did not enter one. Any DOB supplied by the customer will be stored as the person’s DOB, therefore if the customer’s application provides a user with a default DOB if they don’t provide one, then passing that default DOB to GreenID is highly discouraged.

Null or in the past.

See DateTime Specification within Reference Tables
homePhone

String

255 Chars		NoThe user’s home phone number.No restrictions - non-digits are stripped when sent for verification checks.  Please don't include country codes.
workPhone

String

255 Chars		NoThe user’s work phone number.No restrictions
mobile

String

255 Chars		NoThe user’s mobile phone number.No restrictions
extraDatanameValuePair[]NoThis allows the customer to send extra data that will need to be agreed upon before implementation. It will be a simple key/value format. If there is no previous agreement for certain keys to be sent in this field then it will be ignored.

Return Value 

This method will return a RichVerificationResult object. This object is described in detail in the section on Outcome Notification, so the reader is referred to that section for further details. In summary, the return value will indicate the current status of the individual’s registration, and the outcome of any checks that were automatically performed.  

If the userId has already been used then the saved result for the user represented by that ID will be returned, this will not re-run any validations checks.

Faults

This method may raise a FaultDetails, inside which can be the following codes:  

  • SystemFault
  • InvalidCustomerIdFault
  • InvalidCertificateException

This method may also raise a SystemFault.