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	true = demo with play money (see "Demo launch" below); false or absent = real launch
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.

Demo launch (freePlay=true)

Send the same Step-1 GET with freePlay=true to open the game in demo mode with play money:

• TS does not call your /authenticate and makes no wallet calls (/getbalance, /opentrade, /closetrade) for the session. Steps 2 and 3 do not happen.
• No player account is created on our side and nothing touches your player's balance. The player starts with a demo balance; trades open and settle in the browser only.
• The response has the same shape as a real launch: with responseType=json you get {"status":"ok","data":"<iFrame URL>"}, otherwise a redirect. The URL is the demo copy of your game on your launch host, e.g. https://<ts-host>/demo/?noheader=true&lang=en.
• token and the cookies are not needed for a demo launch. language is honoured.

GET https://<ts-host>/ajax/external-wallet/index?freePlay=true&type=tap&language=EN&noheader=true&responseType=json
→ {"status":"ok","data":"https://<ts-host>/demo/?noheader=true&lang=en"}

If demo is not enabled for your account, the answer is "Demo not available". Ask TS to enable it.

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.

Showing the game before login?

The guest launch returns the iFrame URL with no token, no /authenticate call and no player — a view-only board for lobbies and landing pages. Enabled per host on request.

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.