5.7. InApp Actions

This flow is only available to users who have successfully authorised within the broker's client area. As such, there exist two possible flows for InApp actions;the differences between them are at the user authorization stage.

• Flow 1 outlines a case in which a user authorises inside the platform having previously enabled the 'Keep me logged in' option or equivalent.
• Flow 2 describes the process during which a user authorises inside the platforn by filling the authorisation form from scratch.

The process diagrams summarise both flows.

info

As InApp controls could be attached to a wide variety of InApp actions, it is impossible to create detailed user flows for each InApp action. However, with some changes, the below diagrams can also be extrapolated to other InApp actions. For example, KYC checks are passed entirely within the broker's client area, eliminating the need for sending a request to the cTrader backend (stages 20-21). KYC checks would also require the broker's backend to perform additional actions not represented in the process diagrams.

Tabset

Flow 1 (Automatic Relogin)

Flow 1 (Automatic Relogin) passes through the following stages.

1. The user launches cTrader.

2. The application finds the stored accessToken.

3. The application opens a new connection with the cTrader backend and sends an authorisation request including the accessToken as a parameter.

4. The cTrader backend sends a POST request to authorise the user via the provided accessToken (API call 4.3.).

5. The broker's CRM system checks the provided accessToken and responds with the relevant userId (API call 4.3.). Optional: the broker's backend generates an inappToken for subsequent verification.

6. The cTrader backend authorises the current session under the provided userId.

7. The application starts authorised communications with the cTrader backend. Optional: the application stores the inappToken.

8. The user interacts with an InApp control (e.g., a dedicated deposit button).

9. The platform sends a request to the cTrader backend to attain an OT token.

10. The cTrader backend sends a request to the broker's CRM system to generate an OT token. This request includes userId as a parameter and the optional inappToken parameter (API call 4.4.).

11. The broker's backend verifies the userId and generates the OT token. The OT token is, subsequently, sent to the cTrader backend (token) (API call 4.4.). Optional: the broker's backend verifies the inappToken.

12. The cTrader backend returns the token to the platform.

13. The application opens a predefined URL as defined in Section 5.2.

14. The browser sends a request to the broker's backend to attain the user details.

15. After validating the OT token, the CRM responds with the details of the user requesting the deposit form.

16. The user fills out the deposit form.

17. A deposit request is sent to the broker's backend. The backend processes the request and acknowledges the arrival of the deposit received via the broker's payment services provider.

18. The broker's backend, subsequently, sends a request for an account balance change to the cTrader backend (API call 3.5.).

19. Following the balance change, the cTrader backend sends the balanceHistoryId to the broker's CRM system (API call 3.5.). The broker's backend sends a response to the web browser.

20. The web browser redirects the user to a predetermined success URL.

21. The app checks the URL and, upon success, closes the web browser.

22. Simultaneously with stages 20-21, the cTrader backend sends a 'pump' to the trading platform confirming the change in the trading account balance.

Flow 2 (No Automatic Relogin)

Flow 2 (No Automatic Relogin) passes through the following stages.

1. [ ]The user attempts to authorise inside the application - this covers Stages 1-7 of the user authorization flow.

2. The application opens a new connection with the cTrader backend and sends an authorization request including token as a parameter.

3. The cTrader backend sends a POST-request via REST API to exchange the OT token for a long-term access token (API call 4.2.).

4. The broker's CRM verifies the token and responds with userId, accessToken, and the optional inappToken (API call 4.2.).

5. The cTrader backend authorises the session under the provided userId and returns the accessToken to the application.

6. The platform stores the accessToken for future usage.

7. The application starts authorised communications with the cTrader backend. Optional: the application stores the inappToken.

8. The user interacts with an InApp control (e.g., a dedicated deposit button).

9. The platform sends a request to the cTrader backend to attain an OT token.

10. The cTrader backend sends a request to the broker's CRM system to generate an OT token. This request includes userId as a parameter and the optional inappToken parameter (API call 4.4.).

11. The broker's backend verifies the userId and generates the OT token. The OT token is, subsequently, sent to the cTrader backend (token) (API call 4.4.). Optional: the broker's backend verifies the inappToken.

12. The cTrader backend returns the token to the platform.

13. The application opens a predefined URL as defined in Section 5.2.

14. The browser sends a request to the broker's backend to attain the user details.

15. After validating the OT token, the CRM responds with the details of the user requesting the deposit form.

16. The user fills out the deposit form.

17. A deposit request is sent to the broker's backend. The backend processes the request and acknowledges the arrival of the deposit received via the broker's payment services provider.

18. The broker's backend, subsequently, sends a request for an account balance change to the cTrader backend (API call 3.5.).

19. Following the balance change, the cTrader backend sends the balanceHistoryId to the broker's CRM system (API call 3.5.). The broker's backend sends a response to the web browser.

20. The web browser redirects the user to a predetermined success URL.

21. The app checks the URL and, upon success, closes the web browser.

22. Simultaneously with stages 20-21, the cTrader backend sends a 'pump' to the trading platform confirming the change in the trading account balance.