This section contains conformance tests, their stages, and accepted results.
Note that conformance testing is a regular process conducted entirely by Spotware. Passing conformance tests is an essential requirement for continued operations with our SSO (OAuth) flows.
When performing an API call as part of conformance testing and encountering an error, provide the error description to Spotware’s Service Assurance team.
In cases 6.2.1 - 6.2.4 and case 6.2.6, check the following screens.
1. The login/signup screen.
2. The deposit/withdrawal screen.
3. The ‘Open New Account’ screen.
4. The ‘Change Password’ screen.
5. The ‘Change Email’ screen.
When testing how content is displayed by variious SSO (OAuth) screens as part of cases 6.2.1 and 6.2.2, make sure that the screens conform to the following requirements.
Note that the majority of all tests described on this page are mandatory. They cover essential SSO (OAuth) operations, user flows, and API calls. Only tests 6.2.3-6.2.6 are optional and are marked as such in their titles.
6.1.1. The cTrader backend is authenticated (API call 4.1)
| Test Steps | Expected Results |
|---|---|
1. Send a POST request to authenticate the cTrader backend with a valid password.2. Send a POST request to authenticate the cTrader backend with an invalid password. |
1. The broker’s backend returns a response with code 200; the output contains crmApiToken.2. The broker’s backend returns a response with an error with code 403; the output does not contain crmApiToken. |
6.1.2. An OT token is checked, verified, and exchanged (API call 4.2)
| Test Steps | Expected Results |
|---|---|
1. Send a POST request to verify and exchange a valid OT token with a valid crmApiToken.2. Send a POST request to verify and exchange an invalid OT token with a valid crmApiToken.3. Send a POST request to verify an OT token with an invalid crmApiToken. |
1. The broker’s backend returns a response with code 200; the output contains accessToken and userId.2. The broker’s backend returns a response with an error with code 404. The output does not contain accessToken and userId.3. The broker’s backend sends a response with an error with code 403. The output does not contain accessToken and userId. |
6.1.3. A long-term access token is checked and verified (API call 4.3)
| Test Steps | Expected Results |
|---|---|
1. Send a POST request to verify a long-term access token with a valid accessToken.2. Send a POST request to verify a long-term access token with an invalid accessToken.3. Send a POST request to verify an long-term token with an invalid crmApiToken. |
1. The broker’s backend returns a response with code 200; the output contains userId.2. The broker’s backend returns a response with an error with code 404; the output does not contain the userId.3. The broker’s backend sends a response with an error with code 403. The output does not contain accessToken and userId. |
6.1.4. An OT token is generated for an InApp action (API call 4.4)
| Test Steps | Expected Results |
|---|---|
1. Send a POST request to generate an OT token with a valid userId.2. Send a POST request to generate an OT token with an invalid userId.3. Send a POST request to generate an OT token with an invalid crmApiToken. |
1. The broker’s backend returns a response with code 200; the output contains an OT token.2. The broker’s backend returns a response with an error with code 404; the output does not contain an OT token.3. The broker’s backend sends a response with an error with code 403. The output does not contain accessToken and userId. |
6.1.5. The broker’s backend generates a new OT token each time it is requested to do so
| Test Steps | Expected Results |
|---|---|
| 1. Log in under an existing user. 2. Wait for the success page to appear. 3. Log in under an existing user in incognito mode. 4. Wait for the success page to appear. |
1. The success page is opened after a successful login. 2. The broker’s backend generates and returns an OT token. 3. The success page is opened after a successful login. 4. The broker’s backend generates and returns an OT token; this token is different from the one generated during Step 2. |
6.1.6. Different OT tokens are generated for different users
| Test Steps | Expected Results |
|---|---|
1. Authorise the user with userId1 inside the broker’s backend and generate an OT token for this user.2.Authorise the user with userId2 inside the broker’s backend and generate an OT token for this user. |
1. A valid OT token is generated. 2. A valid OT token is generated. It is different from the token generated during Step 1. |
6.1.7. OT tokens expire one minute after generation
| Test Steps | Expected Results |
|---|---|
1. Authorise a user inside the broker’s backend, generate an OT token for the corresponding userId, and remember it.2. Wait one minute. 3. Send a request to exchange this token for an accessToken (API call 4.2.) with a valid crmApiToken. |
1. A valid OT token is generated. 2. A minute is expired. 3. The broker’s backend returns a request containing an error as the OT token has expired. |
6.1.8. All API calls use the https protocol
| Test Steps | Expected Results |
|---|---|
1. Send any request with valid parameters and a request body using the http protocol.2. Send any request with valid parameters and a request body using the https protocol. |
1. The request is unsuccessful. 2. The request is unsuccessful. |
6.1.9. All servers have valid certificates
| Test Steps | Expected Results |
|---|---|
| 1. Check server certificates. | 1. All servers have valid certificates. |
6.2.1. Check screen designs when using different browsers
Repeat this case for all major browsers including Chrome, Firefox, Safari and Edge. Use incognito tabs for each step. For examples of screens, see Section 2.
| Test Steps | Expected Results |
|---|---|
| 1. Open an SSO (OAuth) screen through all of its stages. | 1. The screen contents are displayed correctly and satisfy key requirements (see above). |
6.2.2. Check screen designs when using different screen sizes.
Repeat this process for all common screen sizes and aspect ratios such as 4:3 and 16:9.
| Test Steps | Expected Results |
|---|---|
| 1. Open an SSO (OAuth) screen through all of its stages. | 1. The screen contents are displayed correctly and satisfy key requirements (see above). |
6.2.3. The screens support the lang parameter (optional test)
| Test Steps | Expected Results |
|---|---|
1. Open an SSO (OAuth) screen with lang equal to en.2. Open the same screen with lang equal to another valid Alpha-2 code that your brokerage supports.3. Open the same screen with lang equal to an Alpha-2 code that the broker’s backend does not support. |
1. The opened iframe displays the correct screen and has lang=en. The screen is displayed in English.2. The opened iframe displaus the correct screen and has lang = {other code}. The screen is displayed in the language matching the specified code.3. The opened iframe displays the correct screen and has lang = {unsupported code}. The screen is displayed using whatever language is specified as the default language by the broker’s backend. |
6.2.4. The screens support the theme parameter (optional test)
| Test Steps | Expected Results |
|---|---|
1. Open an SSO (OAuth) screen with theme equal to light.2. Open the same screen screen with theme equal to dark. |
1. The opened iframe displays the correct screen and has theme=light. The screen is displayed using the light UI theme.2. The opened iframe displays the correct screen and has theme=dark. The screen is displayed using the dark UI theme. |
6.2.5. The screens support the firstLogin parameter (optional test)
| Test Steps | Expected Results |
|---|---|
1. Open the login/signup screen with firstLogin equal to true.2. Open the login/signup screen with firstLogin equal to false. |
1. The opened iframe displays the signup screen and has firstLogin=true. The screen displays suitable information for first-time user creation.2. The opened iframe displays the signup screen and has firstLogin=false. The screen displays suitable information for an existing user; the screen does not offer to create a first account. |
6.2.6. The screens support changing multiple parameters simultaneously (optional test).
| Test Steps | Expected Results |
|---|---|
1. Open an SSO (OAuth) screen with lang=en and theme=dark.2. Change lang to a valid Alpha-2 code supported by your brokerage; change theme to light. |
1. The iframe displays the correct screen, its content is in English, and it has the dark UI theme. 2. The iframe displays the correct screen, its content is in the specified language, and it has the light UI theme. |
6.2.7. The login/signup screen contains the ‘Reset Password’ button or its equivalent.
| Test Steps | Expected Results |
|---|---|
1. Open the login/signup screen with firstLogin=false. |
1. The screen displays a ‘Reset Password’ button or its equivalent. This control can be interacted with. |
6.3.1. A new user is able to pass the user creation flow.
| Test Steps | Expected Results |
|---|---|
| 1. Open the login/signup screen. 2. Type valid data into all fields and complete the signup process. 3. Wait while the cTrader backend sends a request to exchange the OT token for a long-term access token (API call 4.2). 4. Wait until you are logged into the newly created account. 5. Close cTrader. 6. Open cTrader. |
1. The login/signup screen is opened; accessToken is missing.2. The broker’s backend sends a request to create a new user (API call 3.2.) followed by a request for live trading account creation (API call 3.3.), and user-account linkage (API call 3.4). The cTrader backend creates a live trading account and links it to the correct cTID. The broker’s backend receives a response with userId. The success URL is opened with a valid OT token.3. The broker’s backend verifies the OT token and returns a successful response containing userId and accessToken (API call 4.2). The cTrader backend authorises the user and returns accessToken to the application.4. The user is successfully authorised under the correct cTID; accessToken is saved.5. cTrader is closed. 6. cTrader is opened. API call 4.3 is performed with the accessToken saved during Step 4. The broker’s backend returns a correct userId. The user is authorised under the cTID from Step 3. |
6.3.2. A user is able to log in using valid credentials.
| Test Steps | Expected Results |
|---|---|
| 1. Open the login/signup screen. 2. Type a valid email and password and click on the ‘Submit’ button or its equivalent. 3. Check the URL of the success page. 4. Wait until the current iframe is closed. 5. Wait until you are logged in. 6. Close cTrader. 7. Open cTrader. |
1. The login/signup screen is opened; accessToken is missing.2. The broker’s backend finds the userId of the user and generates an OT token.3. The URL contains the OT token generated during Step 2. 4. The application sends a request to the cTrader backend with the OT token. The cTrader backend sends a request to exchange the OT token for a long-term access token (API call 4.2). The broker’s backend verifies the OT token and returns a successful response containing userId and accessToken (API call 4.2). The cTrader backend authorises the user and returns accessToken to the application.5. The user is authorized successfully under the correct cTID; accessToken is saved.6. cTrader is closed. 7. cTrader is opened. API call 4.3 is performed with the accessToken saved during Step 5. The broker’s backend returns a correct userId. The user is authorized under the cTID from Step 5. |
6.3.3. Traders are attributed to correct partners via the partnerId parameter
| Test Steps | Expected Results |
|---|---|
| 1. Create a new user in the broker’s client area. 2. Register the new user as a partner in the broker’s client area and receive a unique partner identifier. 3. Open the login/signup screen in incognito mode with the value of the partnerId parameter equal to the identifier received during Step 2.4. Complete the signup flow while using a different set of credentials compared to the one used during Step 1. 5. In the broker’s client area, log in as the user from Step 1 and proceed to the list of attributed traders. |
1. A new user is successfully created in the broker’s client area. 2. A valid partner identifier is generated either at the account or the user level. 3. The login/signup screen is opened; its URL contains the correct partnerId.4. The user creation flow is passed successfully (see case 6.3.1). The broker’s client area attributes the new user to the user whose partner identifier matches the partnerId parameter from the login/signup screen URL.5. The user sees a new trader in their list of attributed traders. This trader has the same details as the new user created during Step 4. |
6.3.4. An authorised user can make a deposit
| Test Steps | Expected Results |
|---|---|
| 1. Log into the trading platform. 2. Click on the ‘Deposit’ button. 3. Fill out the form with correct data and submit it. |
1. Login is successful under the correct cTID. 2. cTrader sends a request to the cTrader backend to attain an OT token. The cTrader backend sends a request to the broker’s client area containing userId (API call 4.4). The broker’s backend verifies userId, generates an OT token and returns it to the cTrader backend (API call 4.4). The cTrader backend returns the token to the application; the deposit/withdrawal screen is opened in an iframe containing the OT token as a query parameter.3. The application sends a request to the broker’s backend; the broker’s backend sends a request to the cTrader backend to change the account balance (API call 3.5). The cTrader backend sends a response with balanceHistoryId to the broker’s backend (API call 3.5). The broker’s backend returns a response to the application. The user is redirected to the success page. |
6.3.5. An authorised trader can make a withdrawal.
| Test Steps | Expected Results |
|---|---|
| 1. Log into the trading platform. 2. Click on the ‘Withdrawal’ button. 3. Fill out the form with correct data and submit it. |
1. Login is successful under the correct cTID. 2. cTrader sends a request to the cTrader backend to attain an OT token. The cTrader backend sends a request to the broker’s client area containing userId (API call 4.3). The broker’s backend verifies userId, generates an OT token and returns it to the cTrader backend (API call 4.4). The cTrader backend returns the token to the application; the deposit/withdrawal screen is opened in an iframe containing the OT token as a query parameter.3. The application sends a request to the broker’s backend; the broker’s backend sends a request to the cTrader backend to change the account balance (API call 3.5). The cTrader backend sends a response with balanceHistoryId to the broker’s backend (API call 3.5). The broker’s backend returns a response to the application. The user is redirected to the success page… |
6.3.6. An authorised user can create a new trading account
| Test Steps | Expected Results |
|---|---|
| 1. Open the ‘Create New Account’ form. 2. Fill all required fields and submit the form. |
1. The ‘Create New Account’ form is opened. The form URL has accessToken.2. The broker’s backend sends a request to create a new account. The cTrader backend returns a response with the account login (API call 3.3). The broker’s backend sends a request to link the new account (API call 3.4). The cTrader backend returns a confirmatory response with ctidTraderAccountId. The broker’s backend has a record about the new account.3. The user sees the success page. The user is automatically switched to their new account after the success page is closed. |
6.3.7. The user is able to switch between login and signup on the login/signup screen
| Test Steps | Expected Results |
|---|---|
| 1. Open the login/signup screen. 2. Click on a link to proceed to the login form. 3. Click on a link to the signup form. |
1. The login/signup screen is opened. 2. The login form is opened. This form contains a link to the signup form. 3. The signup form is opened. This form contains a link to the login form. |
6.3.8. The user can open embedded cTrader Web from the broker’s client area
| Test Steps | Expected Results |
|---|---|
| 1. Log into the broker’s client area. 2. Access cTrader Web using either of the two possible options (in an iframe or via a link/button). |
1. The authorised user sees a means to open cTrader Web from the broker’s client area. 2. The user accesses cTrader Web and is authorised inside the application. |
6.3.9. Traders can reset their password via the ‘Reset Password’ button (or equivalent) on the login screen.
| Test Steps | Expected Results |
|---|---|
| 1. Open the login/signup screen. 2. Click on the ‘Reset Password’ button or equivalent. 3. Receive a new email containing a link to resetting your password. 4. Follow the link and complete the password reset flow. 5. Open the login/signup screen. 6. In the ‘Password’ field or equivalent type the password chosen during Step 2 and proceed with authorisation. |
1. The login/signup screen is opened; it displays suitable information for an existing user. 2. The button is clickable and a password reset is requested. 3. A valid email is received containing a password reset link. 4. When clicking on the link, the user is redirected to the platform. After seeing the confirmation message, the user is automatically authorised inside the platform. 5. The login/signup screen is opened; it displays suitable information for an existing user. 6. The user is authorised inside the platform. |