The problem
A player in Stockholm opens a slot game. Their display currency is SEK. Their wallet holds BTC. Somewhere in between, a conversion has to happen — and it has to happen correctly, consistently, and in a way that both the player and the regulator can verify after the fact.
This is not a formatting problem. It's not about showing the right symbol next to the right number. It's a financial integrity problem. When a player places a 50 SEK bet, the platform has to debit the equivalent amount of BTC from their wallet. When they win 200 SEK, the platform has to credit the equivalent BTC back. If the EUR/BTC rate moved between the bet and the payout — which it does, constantly, because crypto markets never close — someone absorbs the difference.
In a naive implementation, the player absorbs it. They bet at one rate and get paid at another. A 200 SEK win might be worth 0.00031 BTC at bet time and 0.00029 BTC at payout time. The player sees "You won 200 SEK" but receives less purchasing power than they expected. In the opposite direction, the operator absorbs the loss. Neither outcome is acceptable at scale, and neither is auditable without knowing exactly which rate was applied at which moment.
This is the problem PAM's multi-currency engine was built to solve. Not currency display — currency correctness.
Multi-provider rate fetching
Exchange rates are only as good as their source. A single provider going stale, returning an error, or lagging behind the market by thirty seconds can mean thousands of transactions priced incorrectly. PAM doesn't rely on one source. It fetches rates from four independent providers, each serving a different role in the rate hierarchy.
- CoinMarketCap — the primary source for crypto-to-fiat and crypto-to-crypto pairs. BTC/EUR, ETH/USD, LTC/SEK — all sourced from CoinMarketCap's aggregated market data.
- European Central Bank (ECB) — the reference source for EUR-based fiat pairs. EUR/SEK, EUR/NOK, EUR/GBP. Updated daily, used as the baseline for fiat conversions in European-regulated markets.
- Fixer — a secondary fiat rate provider covering 170+ currencies. Serves as both a supplement for pairs the ECB doesn't cover and a fallback when the ECB feed is unavailable.
- XE — the tertiary fiat provider. Covers exotic pairs and serves as the final fallback in the provider chain.
Each provider has a configured polling interval and a TTL for its cached rates. CoinMarketCap rates are refreshed frequently because crypto markets move fast. ECB rates are refreshed daily because that's how often the ECB publishes. Fixer and XE sit in between. The TTLs are configurable per operator — a crypto-first casino might want tighter refresh intervals than a fiat-only sportsbook.
When a rate is requested, PAM walks the provider chain in priority order. If the primary provider for that pair has a fresh cached rate, it's returned immediately. If the cache has expired or the provider returned an error on the last fetch, the next provider in the chain is tried. If all providers fail for a specific pair, the system uses the last known good rate and flags the staleness for operator review. At no point does a transaction fail because of a rate provider outage — but at every point, the operator knows exactly how fresh the rate is.
Rate locking per session
Fetching accurate rates is necessary but not sufficient. The harder problem is when the rate is applied. If a player bets at the rate from 14:00:01 and gets paid at the rate from 14:00:03, the game's economics are broken. A 2x win might not actually be 2x in the player's wallet currency. This violates the fundamental contract between the game and the player.
PAM's CryptoCasinoService locks the exchange rate at the moment a game session starts. From that point forward, every wager, every payout, every bonus credit within that session uses the same locked rate. The player bets at 1 BTC = 542,000 SEK, they get paid at 1 BTC = 542,000 SEK. The rate might have moved to 543,000 or 540,000 in the real market — but inside that session, the rate is fixed. No mid-spin surprises.
The locked rate is stored as part of the session record. When the game provider sends a bet request, PAM converts using the session's locked rate. When the provider sends a win result, PAM converts using the same rate. The conversion is deterministic and reproducible — given the session ID, anyone can look up exactly what rate was used and verify every transaction's math.
Rate locking also simplifies the game provider integration. The provider operates in the display currency (SEK, EUR, USD — whatever the player sees). It doesn't need to know that the wallet is denominated in BTC. It sends "bet 50 SEK" and "win 200 SEK," and PAM handles the conversion transparently. The provider never sees the crypto side of the transaction, which means existing game integrations work with crypto wallets without modification.
When the session ends, the lock expires. The next session gets a fresh rate from the provider chain. This means the operator's exposure to rate movement is bounded by session duration — typically minutes, not hours. The risk is real but contained and predictable.
Fixed rate overrides
Market rates are the default, but they're not always what operators want. There are legitimate business reasons to override the market rate for specific currency pairs, and PAM supports this through fixed rate configuration.
An operator running a promotional campaign might offer a favorable BTC/EUR rate to attract crypto depositors. A platform operating in a market with a pegged currency might want to lock the rate permanently rather than fetching it repeatedly. An operator with a negotiated OTC rate for large-volume crypto settlements might want to use that rate instead of the spot market price.
- Promotional pricing — "Deposit in BTC this weekend and get a 2% better rate." The override is configured with a start and end time, and the system reverts to market rates automatically when the promotion expires.
- Stable pairs — for currencies pegged to the USD or EUR, operators can set a fixed rate and eliminate the noise of minor fluctuations around the peg.
- Negotiated rates — operators who settle crypto through OTC desks at pre-agreed rates can mirror those rates in the platform, ensuring the player-facing conversion matches the back-end settlement.
Fixed rate overrides take priority over the provider chain. When a rate is requested for a pair that has an active override, the override is returned without consulting any external provider. The override is logged with the same audit trail as market rates — who set it, when, what the market rate was at the time, and when it expires. This is not a backdoor. It's a controlled, auditable mechanism for operators to manage their currency economics.
Historical rate audit trail
In a regulated gaming environment, "we used the market rate" is not a sufficient answer. Regulators want to know which market rate, from which provider, at what time, applied to which transaction, and whether it matched the rate available to other players at the same moment.
PAM stores the complete rate history for every provider, every pair, and every fetch. When a rate is used in a transaction — whether from the live provider chain, a session lock, or a fixed override — the transaction record includes the rate value, the source provider, the fetch timestamp, and the session or override ID that determined the rate selection.
This means a regulator can reconstruct the entire rate decision chain for any transaction. They can see that on March 15 at 14:32:07, a player started a session with a locked BTC/SEK rate of 541,823.45, sourced from CoinMarketCap at 14:32:06. They can see that the player placed 47 bets and received 12 payouts over the next 23 minutes, all at that locked rate. They can see that the market rate at session end was 542,190.12 — a 0.07% movement that the rate lock absorbed. Every number is traceable. Every conversion is reproducible.
The audit trail also serves the operator's finance team. Monthly reconciliation between the rates used in player transactions and the rates at which the operator actually converted crypto to fiat (or vice versa) reveals the operator's net exposure to rate movement. This is the data that informs decisions about TTL configuration, session duration limits, and whether to use fixed overrides for high-volume pairs.
PAM's multi-currency engine handles both fiat and crypto wallets across all supported markets. Rates flow from four providers with automatic failover, session-level rate locking eliminates mid-game conversion variance, and every rate applied to every transaction is stored with full provider attribution. Operators configure TTLs, override rates for specific pairs, and reconcile exposure through the back office — without involving the development team.
The principle
Currency is not a display concern. Showing "50 SEK" instead of "0.000092 BTC" is the easy part — any template engine can do that. The hard part is making sure that 50 SEK actually equals 0.000092 BTC at the moment the transaction executes, that it still equals 0.000092 BTC when the payout settles, and that a regulator can verify both of those facts six months later.
This requires treating currency conversion as a financial operation with the same guarantees as any other wallet transaction: atomicity, auditability, and determinism. The rate has to come from a trusted source. It has to be locked at a well-defined moment. It has to be stored alongside the transaction. And it has to be reproducible.
That's what PAM's multi-currency engine does. Not currency formatting — currency integrity, at every point in the transaction lifecycle.