Approved publishing partners can place a complete Leaproans.com run inside their own website while keeping authorization and result processing on trusted servers.
Begin with an approved website
Each application includes the organization, primary website, intended use, audience information, approved HTTPS origins, and a completion callback address. Access is enabled only after administrator review. Wildcard origins are not accepted.
Keep the shared secret on the server
The partner portal provides a partner ID and shared secret. The secret is used to create an HMAC signature for session requests and must never appear in browser JavaScript, page source, a public repository, or an iframe URL.
Create a short-lived play session
The partner server sends a signed request containing its pseudonymous user reference and approved parent origin. A successful response returns a short-lived play URL and the active run rules. The browser loads only that returned URL.
Use a responsive frame
The game is designed for a 16:9 frame. The surrounding page should reserve enough space for the full frame and controls, avoid overlays, and allow keyboard focus. Mobile layouts should keep the frame within the viewport without forcing horizontal scrolling.
Process only the confirmed callback
The browser may display progress messages, but those messages are informational. The partner should authorize its own outcome only after receiving the signed server-to-server callback. The callback contains the accepted Satoshi units, starting lives, lives used, lives remaining, elapsed time, distance, score, session ID, and user reference.
Respect limits and one-time completion
Sessions expire, bind to an approved origin and player connection, and can be completed only once. Per-IP session, completion, unit, life-usage, and cooldown controls are applied by the Leaproans.com server. Partners should also apply appropriate limits on their own systems.
Protect the visitor experience
Connected play is kept free from ordinary display advertising and direct sponsor cards. The frame should not be surrounded by controls that could be mistaken for game buttons. Clear opening and closing states help visitors understand when a run begins and when a result has been confirmed.
Test before launch
Complete an end-to-end test using a staging origin, a test user reference, the real callback handler, mobile and desktop layouts, hidden-tab pausing, error handling, and duplicate callback protection. Production access should begin only after every step is verified.
Application and review
The process begins on the publisher and advertiser registration page. Supply a working business email, the real website that will contain the experience, a concise audience description, intended placement, and every HTTPS origin that may host the frame. The administrator can request corrections before approval and can restrict access to a narrower set of origins than those submitted.
Prepare the callback before requesting production access
The callback handler should accept a signed JSON message, verify the signature against the raw request body, confirm that the session has not already been processed, and store the result idempotently. It should return a successful status only after the accepted values have been recorded. Retries must not duplicate a partner-side outcome.
Handle launch and response errors
Session creation can fail because of a stale timestamp, invalid signature, inactive partner, unapproved origin, rate limit, or incomplete configuration. Show a normal error state around the frame rather than exposing a raw response. Log the partner-side request identifier, status code, and time for support, but never log the shared secret.
Protect user references
Use an internal pseudonymous value that your server can map back to the appropriate account. Avoid sending names, email addresses, phone numbers, or payment data. The same reference format should be stable enough for support but not meaningful to someone who sees a log entry.
Design the containing page
Reserve a responsive 16:9 region before the frame loads to prevent layout movement. Do not cover the game with popups, floating navigation, or unrelated promotional controls. Provide a clear close or return action outside the frame, and preserve focus visibility for keyboard users.
Operational monitoring
Track session creation success, callback success, duplicate callback attempts, average completion time, and unusual failure spikes. Monitoring should distinguish a visitor closing the game from a signature or origin error. Contact Leaproans.com support before repeatedly retrying a configuration that is being rejected.
Launch checklist
- The production origin exactly matches the approved origin.
- The shared secret exists only in server configuration.
- Request timestamps and signatures use the documented format.
- The callback verifies signatures and handles duplicate delivery safely.
- The frame is responsive on desktop and mobile.
- No ordinary banner or direct sponsor is inserted inside connected play.
- Support staff can locate a run using the session identifier.
A professional integration treats the game frame, partner server, callback handler, and visitor support flow as one system. Testing only the visible game is not enough.
