Coin packages
How coins are sold: package structure, what has to happen between a payment and a balance, and which offers actually exist.
A purchase, not a wager
Buying coins is a product sale. That framing decides more than it appears to: it is priced like a sale, receipted like one, refunded like one, and the payment behaves like a purchase rather than a deposit — no balance is being funded, and nothing is being held on the buyer’s behalf.
What the buyer receives is a quantity of the play currency. Any Sweeps Coins that accompany it are a promotional grant that came with a purchase, not part of what was bought — a distinction that sounds like semantics until somebody asks what exactly the money paid for.
How a package is put together
Three numbers: a price, a quantity of Gold Coins, and a quantity of Sweeps Coins that accompanies it. All three are yours on both routes.
The third is the one that repays thought. Because Sweeps Coins cannot be bought, their quantity is not a price — it is a promotional decision that happens to be attached to a purchase. Keeping the same ratio across every package in the ladder quietly teaches an exchange rate that the product does not implement and will not honour. Varying it is both more honest and more useful, because it lets the ladder do commercial work rather than just scaling.
The purchase flow, step by step
What has to happen between a card being charged and coins appearing, stated as requirements rather than as a description of any one implementation — on the API route this sequence is yours to build, and on the managed platform we run it.
- PlayerSelects a package. The price, the Gold Coins and any accompanying Sweeps Coins are all visible before anything is charged.
- Operator or platformChecks that the buyer’s jurisdiction permits the purchase, before the payment is attempted rather than after.
- Payment providerAuthorises and takes the payment. This is the only step where money moves.
- Operator or platformGrants the coins against the confirmed payment, with a reference that ties the grant to the transaction. The grant is idempotent: a retried confirmation credits once.
- LedgerWrites the Gold Coins and the Sweeps Coins to their own balances, separately, each recorded with its origin.
- Operator or platformReceipts the purchase — what was paid, what was received, and when.
Step four is where the money goes missing
The two failure modes are a payment taken without a grant, and a grant issued more than once for a single payment. Both come from the same cause: no idempotent link between the transaction and the credit. Whoever builds this step owns that problem — you on the API route, us on the managed platform.
Offers and promotional grants
Two offer types are in use and confirmed: a first-purchase offer, and a win-back offer aimed at a player who has stopped buying. Both are operator decisions on both routes — what they contain, who qualifies, and when they fire.
We are deliberately not listing a longer menu here. Promotional mechanics are easy to describe and hard to substantiate, and a supplier’s site claiming a catalogue of offer types is the kind of thing that comes apart on the second call. If you need a mechanic that is not one of those two, ask — the answer will be what it is.
What you set, and what comes through us
| Capability | API integration — you run the platform | Managed platform — we run the platform |
|---|---|---|
| Coin package price and contents | You | You set it, we run itThe price point, the Gold Coins, and the Sweeps Coins that accompany a package are an operator decision on both routes. |
| Taking the payment | You | YouYours on both routes. The merchant account is in your name and we do not resell acquiring, so a coin purchase is never acquired through us. The one exception is the crypto rail, which is ours on the managed platform because it needs no merchant account at all. |
| Promotional offers and grants | You | You set it, we run itFirst-purchase and win-back offers are confirmed. Anything beyond those is an operator decision on both routes. |
| The player wallet and both balances | You | casinoapi.techOn the API route you are wallet of record and the balances live in your system. On the managed route we hold them. |
Where the payment rails are described
Which methods are available, how settlement works and what the money actually does are a separate subject with a separate page: payments and settlement. This page stops at the point the payment confirms, on purpose.
Something here not match what you were told on a call? Tell us — the page is wrong or the call was, and either way we want to know which.