Accept crypto payments as a game studio: the web shop where the sale is final

Why a game studio's web shop inherited the platform's hardest job

The direct web shop stopped being an experiment somewhere around the point every mid-sized live-service title had one. The reason was always the commission: a storefront takes its cut of every gem pack, and a studio selling the same pack from its own domain keeps a materially larger share of it. The legal ground shifted too. Apple's App Store Review Guidelines now let apps on the United States storefront include buttons, external links and other calls to action pointing at purchasing mechanisms outside in-app purchase, without a special entitlement — while making clear the prohibition still stands on other storefronts, subject to the exceptions listed there. The terms attached to those link-outs came out of litigation and are still moving.

So the web shop went up. And every point of margin the studio took back came attached to a job the platform used to do silently: supporting the payment methods a player in Manila or São Paulo actually has, filing tax on digital goods in dozens of jurisdictions, scoring fraud, and — the one that hurts — defending disputes.

In 2026 that last one moved even inside the walled garden. Google's Play Console Help page on refund protection and chargeback cost responsibility states that for orders placed after 3 August 2026, Google Play and developers begin sharing chargeback costs: when a chargeback occurs, the developer is responsible for the purchase price less Play's service fee, plus the associated chargeback fees from the financial institution, while Play continues to cover its own service-fee cost. Google also shipped an optional Review Refund API so developers can hand over delivery and consumption evidence to contest illegitimate chargebacks.

Read that as what it is: the industry consensus has moved to the developer owns the dispute. On platform billing you now share the cost. On your own web shop you carry all of it. Either way, a studio that sells virtual items is now a merchant with a dispute problem — and most studios are twelve people, four of whom are artists.

What a disputed top-up actually costs after the gems are spent

The anatomy of the loss. A $49.99 gem pack sells at 22:40. The entitlement lands in the player's account in under a second; the gems go into a limited-time banner within twenty minutes. Seventy days later a dispute arrives. Your evidence is a server log you wrote yourself. There is no tracking number, no carrier scan, no signature, no delivery address — the three artefacts the card dispute process was designed around simply do not exist for a digital item. You lose the money, you lose the item, and you pay a fee for the privilege of having been told.

Friendly fraud is the base rate, not the tail. A shared family card, a teenager, a parent who genuinely does not recognise "premium currency" on a statement. Some of these are honest confusion and some are a business model, and from the outside they look identical. Neither is fraud your risk engine can catch, because the card, the device and the account were all legitimate at the moment of purchase.

The clawback spiral. You do the right thing: revoke the currency, restrict the account. Now the player disputes the other four purchases from that month too. One $49.99 problem becomes a $260 problem and a support thread that ends up on Reddit.

The ratio, not the amount, is what ends you. Individual disputes are survivable. A dispute ratio that drifts above the card networks' monitoring thresholds is not — it invites a higher rate, a rolling reserve, or a termination notice, and it happens to a merchant category (virtual currency, instant digital delivery, global card mix, heavy mobile traffic) that acquirers already read as elevated risk. Card scheme rules give cardholders months to file; the windows are set out in network documentation such as the Visa Core Rules. Your Q1 dispute ratio is decided by sales you made last autumn.

The growth markets decline first. The player in Buenos Aires, São Paulo, Istanbul or Manila hits a checkout priced in dollars and gets a cross-border decline, a step-up challenge they abandon, or a purchase that goes through and then appears on the statement with a foreign-currency surcharge attached — which is, reliably, a dispute waiting to be filed. The studio concludes the market is small. The market was not small; the checkout was.

And the fraud stack eats the margin you went direct to keep. Risk scoring, 3-D Secure tuning, dispute representment, a tax engine, a second processor for failover. The web shop was supposed to be the high-margin channel. For a lot of studios it is the high-admin channel.

Why cards fail specifically on digital goods sold worldwide

• The dispute process assumes a parcel. Its whole evidentiary logic — shipped, scanned, signed for, delivered to the billing address — maps onto nothing a game studio does. Instant delivery is structurally the weakest position in the system.
• Acceptance is thinnest where your players are growing. Cross-border card acceptance is weak in exactly the regions adding the most players, and locally issued cards frequently aren't enabled for international online purchases at all.
• Local instant-payment schemes are resident-only by design. Pix, UPI, SPEI and Bizum work beautifully for a domestic merchant with a local entity. A studio selling from one country to eighty is not that merchant.
• Reversibility is priced into everything you're offered. Rate, reserve, settlement delay and the risk of a sudden account review are all the acquirer's response to the fact that the money it just sent you can be taken back for months.
• Platform billing solves coverage and sells you the rest. It handles methods, tax and refunds — for a commission, and, as of the August 2026 change, while sharing chargeback cost back to you.

The structural fact: a game studio sells an instantly delivered, instantly consumed, subjectively valued digital item to a global, young, mobile-first audience on a rail built to protect the buyer of a physical parcel. That combination is not a fraud problem you can tune your way out of. It's a rail mismatch.

How Payzum lets a game studio accept crypto payments in its own web shop

Payzum is a non-custodial crypto payment processor. There is no Payzum balance, no settlement batch and no rolling reserve priced against your dispute history, because Payzum never holds the money. When a player pays, funds move on-chain from their wallet to a wallet your studio controls, and settlement is the payment.

On-chain payments are also final. Once a top-up confirms, no issuing bank can pull it back seventy days later. That single property removes the entire category of loss described above: friendly fraud, the clawback spiral, the dispute ratio, the reserve, the representment queue. A refund still exists — it just becomes a decision your support team makes under your published policy, rather than a verdict someone else's bank hands down about a purchase you can no longer prove.

And a stablecoin is the same asset in the player's country and yours. A $9.99 bundle paid in USDC from Manila arrives in your wallet in seconds, at face value, on a Sunday, for cents — no cross-border interchange, no FX spread on the way in, no surprise surcharge on the player's statement to dispute later. It's the mechanics we lay out for cross-border collections, applied to the most cross-border customer base in software.

The instruments, mapped to a studio's revenue surfaces

• Hosted checkout — redirect, modal or inline — on your own web shop. This is the flagship: the gem pack, the bundle, the founder pack and the cosmetic sale all end in a confirmed, final payment inside the same session, no human in the loop, at 3am, from any country.
• Payment links and buttons, no code. The instrument for everything that doesn't live in the shop grid: a creator-code bundle dropped in Discord, a limited weekend offer posted to your community, a one-off charge for a player whose regional checkout failed, a Kickstarter-style pledge tier upgrade.
• Recurring subscriptions for the revenue that repeats: the battle pass, server VIP, a premium tier, a private-server plan. Recurring billing with on-chain finality — the mechanics of subscriptions that don't die by chargeback, and don't die on a reissued card either.
• Invoices with an expiry and overpayment detection for the B2B side a live-service studio forgets it has: brand collaborations, in-game sponsorships, esports org partnerships, publisher milestones, localisation vendors billing you and guild-tier corporate deals. Reference the campaign, set the expiry to the contractual due date.
• POS with a fresh QR per sale. Conventions, expos and launch events: merch, art books, early-access keys and signed collectibles at the booth. Any phone becomes a terminal — the same in-person flow as any counter — and cashier accounts with PIN let the volunteers on the stand collect without ever touching the studio wallet, with per-cashier analytics at close.
• REST API and signed webhooks so your entitlement service grants the item the moment the payment confirms. Solana confirms in roughly 0.4 seconds; Base and Polygon in about two. The player is back in the match before the receipt email renders. Full details in the REST gateway walkthrough.
• Mass payouts. CSV batch payouts plus EVM stablecoin payouts on Polygon, Arbitrum, Optimism, Base, BNB Chain and Avalanche: UGC creators and modders on revenue share, contract artists and composers, translators, community moderators, creator-code commissions and tournament prize pools — one batch instead of forty transfers across nine countries.

What this does not change: the platform's rules are still the platform's rules

We'll be blunt, because this is where bad advice gets studios into trouble. Nothing here overrides Apple's or Google's policies. Inside your app, in-app purchases stay on the platform's billing wherever its guidelines require it, and any link-out you ship has to match the rules of the storefront the app is being served from — the US allowance described in the review guidelines is not a global switch, and the rest of the world's rules are written in the same document. Payzum is the payment rail on your web shop, the destination you own and control. Build it as a real storefront rather than a link that only makes sense from inside the app, and a policy change in either direction stops being existential.

Finality cuts both ways — and your refund policy has to say so

There is no pre-authorisation and no reversal on-chain. That's the whole benefit, and it comes with a duty: refunds are money you send, on your terms, and your published refund policy becomes the only document in the room. Consumer refund rights in your players' jurisdictions, platform refund rules, age and parental-consent requirements, spending controls for minors, and the rules that apply to loot boxes and randomised item sales in a growing list of countries are all unchanged and all remain the studio's responsibility. A rail that removes chargebacks does not remove any of that — it just stops a policy question from being settled by someone else's bank.

Volatility is a setting, not a risk

You price in dollars and pay salaries, cloud and middleware in fiat, so "I'm not holding an asset that moves" is the correct first objection. You don't have to. Payzum accepts crypto and settles in crypto, with optional auto-conversion to a stablecoin such as USDC or USDT. The $49.99 pack is $49.99 when it lands and $49.99 when you spend it.

What doesn't change

Payzum is crypto-only and does not settle to a bank account. Converting stablecoins into your operating currency for payroll and cloud bills stays a separate step you take with your own exchange or off-ramp, on your own schedule. What changes is how fast confirmed money arrives, who holds it in the meantime — nobody but you — and whether a sale from last autumn can still be taken off you next spring.

How it works, step by step

1. Open the account and connect a wallet you control. Create a Payzum account, complete KYC, point settlement at the studio's own wallet. There's no Payzum-held balance to be released, reserved or reviewed.
2. Wire it into the web shop. Hosted checkout on the shop pages, payment links for community drops and creator codes, subscriptions for the battle pass and VIP tiers, invoices for sponsorship and partner billing. No-code where you want it, API where you don't.
3. Connect entitlements to a signed webhook. Your backend already knows how to grant an item; now it grants on a signed webhook rather than a card authorisation that might be reversed later. Test it in the integration playground before you point real traffic at it.
4. Collect as final money. Players pay in USDC or USDT from any wallet across Bitcoin, Ethereum, Solana, Polygon, Base, Arbitrum, Optimism, BNB Chain and Avalanche. Confirmation lands in seconds; the item lands with it; optional auto-conversion keeps the amount in dollars.
5. Run the payout side from the same place. Month end: one CSV settles UGC creators, modders, contract artists, translators, moderators, creator-code commissions and the season's prize pool — across countries, in one batch.

Use cases at a game studio

Five situations where the difference shows up inside a single sale rather than a year-end review.

• The top-up from a market your checkout keeps losing. A player in São Paulo has abandoned your shop three times — cross-border decline, then a step-up challenge, then a surcharge on the statement. They pay $19.99 in USDC on Base instead; it confirms in about two seconds, the webhook grants the currency, and the amount that reaches your wallet is the amount on the price tag. No FX spread, no surcharge, nothing to dispute in November.
• The battle pass that survives the season. Seasonal passes are sold as recurring subscriptions in stablecoins. They don't lapse silently on a reissued card, they don't fail a 3-D Secure challenge on a phone that changed country, and they can't be reversed after the season's rewards have been claimed.
• The creator-code drop in Discord. A streamer announces a bundle to a live chat at 21:00. You post a payment link, it converts while the hype lasts, and the creator's commission goes out in the same week's payout batch — to whichever country they happen to live in.
• The payout run a UGC economy actually needs. Two hundred map-makers, modders and cosmetic creators on revenue share, plus translators and moderators, plus the finalists of the community tournament. One CSV batch of stablecoin payouts replaces a fortnight of individual transfers, minimums, and "my bank rejected it" tickets — the same mechanics as tournament prize payouts, run monthly.
• The convention booth. Three days at an expo, merch and early-access keys on the table, two volunteers running the stand on their own PIN accounts and a fresh QR per sale. No terminal contract for a three-day event, no float to count at the end of it, per-cashier totals when you pack up.

Payzum vs cards and platform billing for a game web shop

Common objections, answered

"Our players don't hold crypto."

Most don't, and you don't need them to. This runs alongside your existing checkout, not instead of it. The players it converts first are the ones your current stack serves worst: the ones in regions where a foreign card checkout simply declines, the ones who already hold USDC because they're paid in it, the whales who'd rather send one final payment than have a five-hundred-dollar authorisation reviewed by a risk engine. Offering it costs you nothing on the days nobody uses it, and it earns on every sale your current rail would have refused.

"Doesn't this break App Store or Play rules?"

It doesn't, because it isn't a way around them. In-app purchases stay on the platform's billing wherever its guidelines require it. What Payzum powers is your own web shop — the destination you own, which studios have run for years, and which the review guidelines address separately per storefront. Build the shop as a standalone destination, keep your in-app behaviour compliant with the storefront it's served from, and your payment rail is a question about your website, not about your app listing.

"If there are no chargebacks, what stops us being seen as anti-consumer?"

Your refund policy, which is now the thing that actually governs. Finality removes the involuntary reversal, not your ability to give money back: a support agent can refund a mis-click in minutes, and the player has it in their wallet before the ticket closes. What disappears is the asymmetry where a purchase from ten weeks ago can be undone against goods that no longer exist. Studios that publish a clear, generous, fast refund policy find the dispute conversation stops being adversarial.

"We already have an entitlement service and a shop front end."

Keep them. Payzum is drop-in: a REST API with API keys, signed webhooks, an integration playground, and no-code links, invoices and subscriptions for everything you don't want to build. Your shop stays the source of truth for catalogue, pricing and entitlements; a webhook tells it the moment a payment is final. Nothing about your item pipeline changes.