¶ 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.
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.
Flow 1 (Automatic Relogin) passes through the following stages.
-
The user launches cTrader.
-
The application finds the stored
accessToken. -
The application opens a new connection with the cTrader backend and sends an authorisation request including the
accessTokenas a parameter. -
The cTrader backend sends a POST request to authorise the user via the provided
accessToken(API call 4.3.). -
The broker’s CRM system checks the provided
accessTokenand responds with the relevantuserId(API call 4.3.). Optional: the broker’s backend generates aninappTokenfor subsequent verification. -
The cTrader backend authorises the current session under the provided
userId. -
The application starts authorised communications with the cTrader backend. Optional: the application stores the
inappToken. -
The user interacts with an InApp control (e.g., a dedicated deposit button).
-
The platform sends a request to the cTrader backend to attain an OT token.
-
The cTrader backend sends a request to the broker’s CRM system to generate an OT token. This request includes
userIdas a parameter and the optionalinappTokenparameter (API call 4.4.). -
The broker’s backend verifies the
userIdand 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 theinappToken. -
The cTrader backend returns the
tokento the platform. -
The application opens a predefined URL as defined in Section 5.2.
-
The browser sends a request to the broker’s backend to attain the user details.
-
After validating the OT token, the CRM responds with the details of the user requesting the deposit form.
-
The user fills out the deposit form.
-
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.
-
The broker’s backend, subsequently, sends a request for an account balance change to the cTrader backend (API call 3.5.).
-
Following the balance change, the cTrader backend sends the
balanceHistoryIdto the broker’s CRM system (API call 3.5.). The broker’s backend sends a response to the web browser. -
The web browser redirects the user to a predetermined success URL.
-
The app checks the URL and, upon success, closes the web browser.
-
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) passes through the following stages.
-
[ ]The user attempts to authorise inside the application - this covers Stages 1-7 of the user authorization flow.
-
The application opens a new connection with the cTrader backend and sends an authorization request including
tokenas a parameter. -
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.).
-
The broker’s CRM verifies the token and responds with
userId,accessToken, and the optionalinappToken(API call 4.2.). -
The cTrader backend authorises the session under the provided
userIdand returns theaccessTokento the application. -
The platform stores the
accessTokenfor future usage. -
The application starts authorised communications with the cTrader backend. Optional: the application stores the
inappToken. -
The user interacts with an InApp control (e.g., a dedicated deposit button).
-
The platform sends a request to the cTrader backend to attain an OT token.
-
The cTrader backend sends a request to the broker’s CRM system to generate an OT token. This request includes
userIdas a parameter and the optionalinappTokenparameter (API call 4.4.). -
The broker’s backend verifies the
userIdand 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 theinappToken. -
The cTrader backend returns the
tokento the platform. -
The application opens a predefined URL as defined in Section 5.2.
-
The browser sends a request to the broker’s backend to attain the user details.
-
After validating the OT token, the CRM responds with the details of the user requesting the deposit form.
-
The user fills out the deposit form.
-
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.
-
The broker’s backend, subsequently, sends a request for an account balance change to the cTrader backend (API call 3.5.).
-
Following the balance change, the cTrader backend sends the
balanceHistoryIdto the broker’s CRM system (API call 3.5.). The broker’s backend sends a response to the web browser. -
The web browser redirects the user to a predetermined success URL.
-
The app checks the URL and, upon success, closes the web browser.
-
Simultaneously with stages 20-21, the cTrader backend sends a ‘pump’ to the trading platform confirming the change in the trading account balance.