Integration
What connecting involves
One frame inside your product, one call from your backend saying who is playing, and one feed your server reads to find out what happened. Everything about your players and their money stays with you. The deal, the score, and the record of how it was reached are ours.
Where the line sits
Your players, your money, your market
The boundary is drawn where a supplier’s is. Your players are yours: they sign in under your terms, the token you mint names them by an identifier you chose, and nothing else about them reaches us.
Money does not cross either. You charge the stake, you hold the balance and you pay the prize, in the wallet your players already trust. Your players’ money never reaches us: not the stake, not the balance, not the prize.
Matchmaking
One pool, every platform
An asynchronous duel needs an opponent of roughly your player’s standard, in the game they chose, at the prize they chose. Very few platforms can fill that queue out of their own users, and a queue with nobody in it is a game nobody plays.
So there is one pool, and every connected platform queues into it — ours included: play4sats is our own consumer platform and it queues on the same terms yours do. One pool, one matchmaker, one rating scale, however many platforms.
Today a paid match seats two players of the same operator — yours play each other. You hold both stakes and you pay your own winner, so a paid match spanning two platforms has no single pot and no honest way to pay out of one. Making it work needs clearing between operators. We would rather say that than approximate it, and everything above it is already built for the day it exists: one pool, one matchmaker, and the only thing standing in the way is the money.
Partner zero
We run one of these ourselves
play4sats is live, it carries all eight games, and it was the first thing built on any of this. That is also why the integration has the shape it does: every awkward part of embedding a game in somebody else’s product was found there first.
It is not a demo of the integration, it is the integration. The frame your page would embed is the frame it embeds, the handshake is the same exchange, and the matches are scored by the same dealer through the same game rule modules. What differs is one thing: play4sats names its players from its own sign-in, and you would name yours with a session token you mint. Everything downstream of that is code we share with ourselves.
It is also young, so treat it as proof that the thing runs and not as a claim about how many people are in it — go and play a match on it, which takes about three minutes and no account.
the score
No endpoint we run accepts a score from a browser. The number in your results feed is one we computed here, by re-playing that match ourselves against the deal it was dealt from.
The whole argument, including where it is weakest, is on Fairness.
Stakes, prizes, and what we charge
The prize is ours. The stake is yours.
A match pays one of five prizes, and we set them: $1, $5, $10, $20 and $50. It is the one thing on your side of that line that we decide.
Your stake can differ from what the operator next door charges. What a player pays to enter a match against a given prize is a pricing decision, and pricing belongs to whoever owns the customer.
The five are not equally easy to fill. A $50 match needs two people who both want a $50 match in that game, so the top of the ladder is worth whatever the pool in that game is worth.
How we are paid
We take a share of the fee on a paid match, on terms agreed with you. We publish the model and not the number: those terms differ per partner, and a headline percentage would be wrong for almost everyone who read it.
We take that share by invoicing you for it, after the fact, against matches your platform has already settled. A player’s money moves between your wallet and theirs, and we are not in that path at any point.
And nothing is charged on a match that did not produce a winner. A draw refunds both stakes whole, an unmatched match refunds the one that was paid, and neither of us takes anything from either — our share is a share of the fee, so when there is no fee there is nothing to split.
Connecting
One frame, one token, one feed
Each game is an iframe from an origin that is not yours, so your page and the game cannot read each other. Your backend mints a session token for the player at the keyboard, scoped to one player and one game and good for an hour.
The result comes back another way. When a match finishes, the authoritative outcome is on the results feed, which your backend reads server to server. The frame does talk to your page as well, but never about the score. Every field and call is in the docs; this page is the shape.
Running your account
Almost everything is yours to run
Keys, embedding origins, colleagues and what each may do are yours to change in the partner portal. A key is shown once and only its hash is kept, and the old key keeps working for seven days beside the new one, which stops a cutover being an outage.
The event log records what we did on your account as well as what you did. And the emergency stop is self-serve: a Developer can pull it without a second factor, because the moment you need it is the worst possible moment to be hunting for your phone.
Almost everything, not everything. Three things still come through us: creating the account, changing a domain rule we have already recorded, and getting you back in if you lose your second factor.
Roles, the step-up windows, the lockout and the log: managing your account.
The part that depends on your stack
The frame, the token and the feed are the same for everybody. What differs is how your players sign in and where a game sits in your product. Tell us how yours works and we will tell you what connecting to it looks like.
Talk to us