[Live] Changes to Game Passes

These changes are now live!

Hey Developers,

Last September, we mentioned an upcoming change to Game Passes.

Since then, we have made changes to how the game passes will work. Please use the following announcement as reference for the most up to date information.

This change will not break existing games or require changes to game passes that currently exist, but you will need to follow the recommendations below for the game passes created after the new changes are live.

Here is a tutorial we have updated with further technical details about the change: https://wiki.roblox.com/index.php?title=Game_Passes_–_Abilities_and_Bonuses

Here is a summary of the change:

Like Badges, we wanted to restructure how we store these objects, both to let our systems scale well, but also to make sure that they are structured cleanly. From now on, game passes will not be assets, but will be their own unique entities. This means that they will use their own separate ID system from other Roblox objects (such as badges or assets). Game passes will now have game pass ID that will be used to identify them. Any game pass made before this change will still have an asset ID, but they will also be automatically assigned a game pass ID. New game passes will only have a game pass ID.

You can get the game pass ID the same way you would have gotten the asset ID before these changes. Go to the page of the game pass (one of the easiest ways is to click on the pass’s image in the store on your Game’s page) and check the URL.

In the old asset system, the URL would look something like:

Here is an example of how the URL will look in the new system:

Once the change is live, to get the game pass ID from an existing asset ID, go to www.roblox.com/library/{assetId}/view . You will be redirected to www.roblox.com/game-pass/{gamePassId}/view . You can then copy the game pass ID from the URL.

This change means that you will need to use the correct Lua APIs (as outlined below) when working on new development projects with game passes. MarketplaceService.UserOwnsGamePassAsync should be used to see if a player has a particular pass. Additionally, MarketplaceService now has specific functions for game passes, both to prompt for the purchase and to handle the purchase events.

Note that these changes will not break existing games. The old functions will continue to work for old game passes, but you will start seeing warnings in the output asking you to switch over. If you are creating any new game passes, the old methods like PromptPurchase and PromptPurchaseFinished will not work.


This function takes a user ID and the game pass ID as parameters (remember, the game pass ID, not the old asset ID) and returns if the player owns the game pass or not. Note that this function makes a web call under the hood so the best practice is to wrap this function in a pcall. Make sure you use this function and not MarketplaceService:PlayerOwnsAsset.


This function takes a player object and the game pass ID as parameters and it will create a dialog prompting the user to purchase the pass. Make sure to use this function and not MarketplaceService:PromptPurchase.


This event fires when a player finishes interacting with a game pass purchase prompt. The event will pass the player, the game pass ID, and whether or not the player purchased the pass to the connected function. Make sure to use this function and not MarketplaceService.PromptPurchaseFinished.


This can be used for game passes if InfoType is changed to Enum.InfoType.GamePass.

Check out the Developer Portal for more information:

Please let us know if you have any questions about this new system.

Developer Relations Team


Does this cache, or does it actually check 100% of the time?


So, does it cache? That kind of nullifies its usefulness in a lot of cases.
rip, cheese beat me to it


Alright. You mentioned this, but I want to clarify this more. If you have a script with a bunch of GamePass Ids, will all the scripts in the game relating to MarketPlaceService (Prompting, checking PlayerHasPass, etc.) break if you are using the old Ids?


Here’s a cheat sheet for you:

Works with new AND old game passes (uses the gamepass ID, not the asset ID)

Works with old game passes, doesn’t work with new ones (uses the asset ID, not the gamepass ID)

As long as you use the right ID type with the right function, everything will work just fine.

PlayerOwnsAsset() doesn’t work with new game passes because the new ones don’t get assigned an asset ID.


Awesome, good to see game passes being finalised so the different APIs don’t conflict lol :wink:


Quick recommendation to bookmark this thread, I can almost guarantee there will be a time in the near future that you attempt to use game passes like regular assets.

Don’t have too many issues with this change because it seems fairly easy to implement and not much different than how it used to be, just labeled differently.


but does it cache?


Remove the cache and you’ve got a deal.


UserOwnsGamePassAsync is actually not usable if it caches. I will sooner switch back to selling products with Shirts than use a caching product API.


Definitely need to remove the caching.


If I’m being honest, I have to say that this change is really not a nice one from the point of view, I think, of most developers. I really hope that the documentation on the wiki makes this very clear as new players or developers not in the devforums (of which I know quite a few) will definitely have a lot of confusing problems and issues with this. The rolling out of the warnings in the console before the release of the new gamepass system was certainly a massive mistake, and I am hoping this won’t happen again.

I haven’t had time to mess around with this and as I’m writing this from my phone I can’t check this, but it would be nice if, when a user accidentally uses an assetid instead of a gamepass id the error outputted tells them the exact issue, as this is certainly a massive change and having two systems running side by side will make this a much bigger job for developers getting started and developers getting to grips with the new system.

However, this is not to say that I disagree with the change, it’s completely understandable that gamepasses should be put into their own system to save on server processing and allow for ‘expandability’. Just, I beg of you guys that it’s rolled out well and every effort is made to make it as simple for developers as possible.

Also the problems with caching are really annoying, you can’t have an API like this that caches when not expected to. At least include a caching parameter to enable or disable caching the result!


See, I like this idea. Using a structure like this, you could probably reduce the length of IDs by giving them subcategories, instead of grouping everything into a singular assetID system.



Edit: oops didn’t read the other posts


Not a half-bad idea. I was thinking you could just move to dev products, but then you would lose the game store. But using T-shirts would allow them to appear in your group’s store, which is… better than nothing, at least.

…But that’s assuming that the game store is also much better than nothing. Unless I saw some compelling stats about that, I’d probably still just use dev products and not bother with this mess.


Just one question…


Hello I am not a scripter but many people are talking about a cache and that it should be removed so yes I agree with them


We’re 6 hours in and we have yet to learn whether or not if it caches.


90% of replies:

“pls dont cache” / “does it cache”

Which is reasonable to post. If it caches, I’m going to use products as pseudo-game passes and will never touch passes again until it doesn’t cache.


Just checked with engineering, and the new UserOwnsGamePassAsync method doesn’t cache.