Roblox gives you exactly two ways to sell something for Robux inside an experience: game passes and developer products. They look similar in the Creator Hub — both get an id, an icon, a price — and they are structurally opposite. Confusing them, or shipping only one of them, is one of the most common monetization mistakes we see in pre-launch audits.
The mechanical difference
A game pass is a one-time, permanent purchase. A player buys it once, owns it forever, and can never buy it again — the platform enforces this. Ownership is queryable from the server (UserOwnsGamePassAsync), which makes passes the natural container for permanent state: a VIP tier, a persistent tool, a cosmetic identity, a x2 multiplier.
A developer product is a repeatable purchase. The same player can buy it two times or two hundred times. Nothing about ownership persists on the platform side; instead your server receives each purchase through ProcessReceipt and must grant the goods itself. That makes products the container for consumables: currency packs, revives, boosts, stage skips.
There’s a discovery difference too, and it matters before launch: game passes are listed on your experience’s store tab on the game page itself, purchasable from the website without ever joining a server. Developer products can only be bought in-game, through UI you build. A pass is visible to a player researching your game the day before your update drops; a product does not exist until they’re inside.
The ceiling argument
Here is the structural fact that should drive your build order: a passes-only catalog caps every player’s lifetime spend at the sum of your passes.
Make it concrete. Suppose you ship five passes at 99, 149, 249, 499, and 799 Robux. A player who loves your game, plays daily, and wants to support you can spend at most 1,795 Robux — total, forever. Your ceiling per player is a fixed number you can compute today, and no amount of retention raises it. The player who would happily keep spending has been structurally told no.
Developer products remove the ceiling. One 49-Robux revive that a committed player buys whenever they need it is unbounded in a way no pass can be. This is why our audit engine treats a catalog with passes but zero products as a warning (no-repeatable-purchases, 8 points), not a stylistic note: it’s a hard cap on revenue baked into the catalog structure.
What each type is actually for
- Passes: identity and permanence. VIP, cosmetic classes, permanent tools and multipliers, supporter badges. Anything a player should buy exactly once and feel ownership of.
- Products: moments and consumption. Currency top-ups, revives at the moment of death, timed boosts, skips at the moment of frustration. Anything whose value regenerates.
The classic design error is shipping a consumable as a pass (“+500 coins” as a game pass can be bought once — then it’s dead inventory) or a permanent as a product (players who buy your “VIP” product twice by accident will file disputes, and they’ll be right).
So which do you build first?
Build your first game pass first.It’s the fastest route to a purchasable game: no server code is strictly required for a simple cosmetic or multiplier pass, it shows up on your game page before launch, and it gives your earliest supporters something permanent to own. If you follow a price ladder (we recommend three tiers), the entry-tier pass at 25–50 Robux is the single highest leverage item in your catalog.
But do not launch without at least one product. The ceiling argument above is the reason, and launch week is when it binds hardest — your most enthusiastic players arrive first. One well-placed consumable is enough to remove the cap.
A build-order that survives contact with a real release schedule:
- One entry-tier pass (25–50 Robux) — cheap trust.
- One core pass (150–400 Robux) — your main permanent value.
- One consumable product wired through
ProcessReceipt— the ceiling remover. - Everything else after launch, informed by what players do.
The engineering footnote that saves disputes
Products come with one server-side obligation passes don’t: ProcessReceipt must be idempotent. The platform can and will call it more than once for the same purchase (crashes, retries, players rejoining), so record the PurchaseId you’ve granted and return PurchaseGranted only once the goods are durably saved. Grant-then-save races are how players end up paying for nothing — and paying for nothing is how you end up in the trust failures that kill conversions.
Structure first, tuning later: one pass for permanence, one product for repeatability, prices on a ladder. That’s a catalog worth auditing — and the audit will tell you what you missed.