Launch Flow

Launch flow (3 steps)

The Step-1 GET is held open until your /authenticate returns. The iFrame URL never reaches the player until you've verified the launch token and returned status:"Ok".

Step 1 — Authorization Request (your backend → TS)

GET https://<ts-host>/ajax/external-wallet/index?...

Where <ts-host> is the URL TS provisions for you (e.g. s11.taptrading.com for staging).

Query parameters:

Param	Type	Example	Notes
noheader	bool	true	Hide TS's header for a white-label look
currencyCode	string	USD	Must match a currency configured for your account
freePlay	bool	false	Keep false
language	string	EN	2-letter UPPERCASE
mobile	bool	false	Optional UI hint
mode	string	dev	Keep dev during integration; TS will move to prod for go-live
token	string	<UUID>	The launch token you generated; TS echoes it back in Step 2
type	string	tap	Always tap for this integration
responseType	string	json	Request JSON envelope
landingParam	string	VIP	Optional grouping parameter (filter for analytics on TS's side)

Required cookies:

Cookie	Example	Notes
PHPSESSID	abc123…	Session identifier (used by TS's session bootstrap)
userId	user-123 or 123_usd	Your user ID. Must be stable per (user, currency) pair. Avoid dashes.
UserName	john.doe	Display name; can be spoofed
userCurrency	1	Numeric currency code (see Currency Codes section). 1 = USD, 6 = JPY, 25 = USDT, etc.
accountLevel	0	Leave 0 unless TS tells you otherwise

Important: TS will NOT immediately return the iFrame URL on this GET. TS first calls your /authenticate (Step 2). Only after you return status:"Ok" does TS answer this GET with the Authenticated Link.

Step 2 — Authenticate Verification (TS → your backend)

POST https://<your-custodial>/authenticate

This call is unsigned — no HMAC headers. The launch token itself is the credential: it's single-use, freshly minted by you seconds earlier, and known only to your backend and TS. Signing starts with the wallet callbacks (/getbalance, /opentrade, /closetrade) — see "Message Integrity".

Request body (sent by TS):

{
 "launchToken": "<launchToken>"
}

Response (you → TS):

{
 "status": "Ok",
 "token": "<walletToken>",
 "userId": "user-123",
 "userName": "john.doe",
 "balance": "1000",
 "currency": "USD"
}

Fields:

• status — "Ok" to proceed. Anything else aborts the launch and the player sees an error.
• token — your wallet access token. Opaque to TS. TS sends it back on every wallet callback. Persist the mapping launchToken → walletToken, userId, currency on your side.
• userId / userName — echo back the values you originally minted the launch token for.
• balance — current wallet balance as a string. Keep precision intact (no float coercion).
• currency — match the currencyCode from Step 1.

Step 3 — Authenticated Link (TS → your backend)

If Step 2 returns status:"Ok", TS's Step-1 GET response is a fully formed iFrame URL, e.g.:

https://<ts-host>?noheader=true&lang=EN&PHPSESSID=<...>&userID=<TS-USER-ID>&username=<UserName>

Embed it on your parent page:

<iframe
 id="ts-tap"
 src="<AUTHENTICATED-LINK>"
 allow="clipboard-write"
 referrerpolicy="no-referrer"
 style="width:100%;height:720px;border:0;"
></iframe>

If you use the sandbox attribute, include allow-same-origin allow-scripts and let TS know — some sandbox combinations block app features.

Session inside the iFrame

The launch URL TS returns carries the session identifier in its query string (e.g. PHPSESSID=<...>&userID=<...>&username=<...>). The iFrame reads it on load and bootstraps the session.

No cookie setup is required on your side — the launch token in the URL handles session setup inside the iFrame. If you ever observe session issues for specific browsers at scale, contact your TS integration contact; there are server-side options to address it.