Submission (AU brands)

Overview

This page describes the Sign Up submission process to create a new client account once page 1 and 2 of the sign up form have been filled in. For more info on page 1 and 2 refer to Join Form.

Page 1 and 2 screenshots:

Branding

There is no difference between the AU brands when it comes to submission except for the create client url described below.

Integrations

Configuration

• domain.zeroday.zero-day-verification-v2-timeout - delay in seconds before requesting offers, to allow time for verification to complete.

Used in the Betstop dialog when the create client API returns a betstop_self_excluded error as described below:

• domain.phones.betstop - Betstop Phone Number - from App Config.
• domain.urls.betstopWebsite - Betstop website link - from App Config.

Outputs

REST: POST /client/Create

• This is the endpoint to which the user's details are sent to create a new account.

Parameters:

• first_name, middle_name, last_name, username, password, email, bonus_code and address fields: string values as entered into form.
• address_country_code: string value hardcoded to "AU"
• address_locality: this value mirrors address_suburb.
• salutation_id: integer enum MS: 1, MR: 2, MISS: 3, MRS: 4.
• phone_number_type_id: hardcoded to "06ae915f-905e-4be7-abc7-bc9c1b9a6021" to represent a mobile phone.
• phone_number: mobile phone number without country code e.g. 0421234567.
• date_of_birth: date in string format yyyy-MM-dd e.g. 1980-01-31.
• deposit_limit: decimal value representing the deposit limit.
• depositlimit_period: string value concatenating the prefix "DAYS" with the duration e.g. DAYS_7
• address_place_id: Harmony address ID or null for manual entry
• currency_code: string value hardcoded to "AUD"

Json Request

{
  "salutation_id": number,          // 1 - 4 corresponding to enum (MS, MR, MISS, MRS)
  "first_name": "string",
  "middle_name": "string",
  "last_name": "string",
  "date_of_birth": "string",        // In yyyy-MM-dd format
  "email": "string",
  "phone_number": "string",
  "phone_number_type_id": "string", // hardcoded to mobile id: 06ae915f-905e-4be7-abc7-bc9c1b9a6021
  "username": "string"
  "password": "string",
  "deposit_limit": number,
  "deposit_limit_period": "string", // e.g. DAYS_7
  "accepts_marketing": boolean,
  "bonus_code": "string",
  "address_place_id": "string",     // Populated with Harmony address ID or null for manual entry
  "address_unit_number": "string",
  "address_street_number": "string",
  "address_street": "string",
  "address_post_code": "string",
  "address_suburb": "string",
  "address_locality": "string",
  "address_state": "string",
  "address_country_code": "string"
}

Create Client UI Mapping

The following scenarios are the result of the process of creating a new client account:

Successful client creation

A successful response from the create client API, results in a new account being created. The auto_login_token value in the response enables authenticating the user with the auth web url without the user entering their credentials again. For more information on authentication, refer to the Login feature, the Android authentication or iOS authentication docs, or the Authentication Bridge. Onward navigation is determined based on the below logic.

User already exists

The backend returns this error when it determines that the user already has an account. While the username, email address, and phone number are checked before submission to make sure they don't exist in the database, it is still possible to receive this error when for example, the first name, lastname and date of birth combination already exists. In this case, a system error is presented to the user to let them know that an account already exists and gives the user the option to go to the Login screen.

Betstop excluded

This error is returned by the backend when the user has been added to the Betstop exclusion list. In this case, a dialog is presented to the user with the Betstop support contact details which are retrieved from the app configuration module as described above.

Self excluded

This error is returned by the backend when the user has been added to the Self exclusion list. In this case a system error is displayed to the user letting them know that something went wrong and inviting them to try again or contact Customer Support.

Generic or Unknown errors

This scenario can happen when there is an issue creating or sending the create client request, for example, when there is no connectivity or the server is down. It can also happen when the backend returns an error that is not one of the mentioned scenarios above, and for which there is no specific scenario. In this case, a system error is displayed to the user letting them know that something went wrong and inviting them to try again or contact Customer Support.

Onward Navigation

Onward navigation is determined by verification status and whether surrogate offers have been returned by the API. Verification of accounts is an asynchronous task started by the backend upon successful sign up. We don't know how long this process can take, but we have a configurable delay on the frontend to allow enough time for it. The app expects a client status push to RN, and a subsequent method call to native, to know that verification was successful.

We first load client details and check if verificationApproved and load surrogate offers, or add a delay based on the app config value domain.zeroday.zero-day-verification-v2-timeout (currently 7 seconds) while observing changes to the client status. When the client status changes to OPEN, or the delay elapses, we load the surrogate offers.

• If offers are returned we navigate to the Surrogate Offers screen.
• If client status is still PRE_OPEN we navigate to the Failed Verification modal.
• If client status is OPEN we navigate to the Deposit flow.
• As a fallback we navigate Home.

Troubleshooting

Account Verification Timing

There is a risk the client status is not updated before onward navigation is decided, due to verification being an asynchronous task on the backend. The original designs cater to this scenario, whether the account failed verification or the result is unknown, the flow is the same, with the Failed Verification modal shown.

We observe the client status so the delay is interrupted when it changes to OPEN. Therefore, if we see examples of the Failed Verification modal appearing for users who have eventually been automatically verified, we could increase the configured delay in app config. This will allow more time for the update to be synced to the app, but make unverified users wait a bit longer to proceed.

Client Status Inconsistency

We have experienced discrepancies between the client details data for status and verificationApproved on the UAT environment. Often client details are returned after a successful signup with verificationApproved = true while status = PRE_OPEN, with the status later updated to OPEN via a websocket push.

This has been raised in Slack for clarification where it was confirmed these updates are driven by separate asynchronous events and aim for eventual consistency. Also confirmed the timing of verificationApproved being updated is expected to come before status.

What this means for the frontend is that the implementation is somewhat fragile. An asynchronous verification task running behind the scenes, 2 data values relating to its status that may not be in sync. Client status is pushed to the client with websockets, but only on successful verification, and is known to experience delays. The verification state does not appear to be included in any websocket payloads.

An improvement on this design would be to push the verification state to the app so it can be updated immediately when verification either fails or succeeds. Also it would be beneficial to speed up client status updates as it is used throughout the app to check the pre-open state.

Client Details Managed by RN

The native app does not request client details directly from the backend, instead relying on updates from RN code over the bridge. This is the same for websocket messages that update client status. With this indirect approach, troubleshooting data inconsistencies requires debugging RN code to ensure it is providing expected updates to native.

With the removal of direct GQL integration from native we do not expect RN components and native components to be out-of-sync when showing pre-open state. In general if the app is still showing a pre-open state after successful verification then it's likely the client status websocket update was not delivered to the app.

Resources

• Epic - Jira
• Reported Bugs - Jira
• Tech Debt - Jira
• Tech Debt - Confluence

Role	Contact
PM	Lily Sommers
Android Lead	Anthony Librio
iOS Lead	Nicholas Vella