Roblox: Safe Gamepasses and Developer Products
ESCOPO
Generate a professional monetization system for Roblox that correctly distinguishes permanent gamepasses from consumable developer products. The prompt requires a server-side implementation with MarketplaceService, ownership verification, reliable receipt processing, and safe benefit granting.
Ideal for developers who need to integrate VIP, multipliers, coins, revives, boosts, or purchasable items without trusting the client. The requested result is a complete, commented Luau Script ready to adapt to the Explorer and the RemoteEvents already existing in the project.
The architecture prioritizes security and resilience: the server is authoritative, developer product purchases are processed only through ProcessReceipt, and repeated receipts cannot grant duplicate rewards. It also includes practical guidance for testing in Roblox Studio and publishing safely.
Conteudo
Prompt principal
Act as a senior Roblox Luau developer, specialized in MarketplaceService, secure monetization, DataStore, and server-authoritative architecture. Generate a single complete **Script** Luau, ready to paste into **ServerScriptService** (not a LocalScript and not a ModuleScript), that implements a robust system of **permanent gamepasses** and **consumable developer products**, including purchase verification and safe benefit delivery. Before writing the code, consider the context of my game below. If any field is empty, keep a clearly identified CONFIG section with placeholder values and clear comments for me to fill in. Do not invent objects, paths, or APIs from my game without explicitly marking the required adaptation. === MY GAME CONTEXT (I WILL FILL IN) === - Game/experience name: [FILL IN] - Where coins/leaderstats/player attributes are located: [e.g. player.leaderstats.Coins / Attributes / custom system] - Name and path of the RemoteEvents/RemoteFunctions already existing: [FILL IN] - Should I create RemoteEvents automatically if they do not exist? [YES/NO] - Gamepasses (logical name = ID = benefit): [e.g. VIP = 123456 = VIP tag + 2x multiplier] - Developer products (logical name = ID = reward): [e.g. Coins1000 = 987654 = add 1000 Coins] - Are there products that grant an item, revive, temporary boost, or another effect? Describe: [FILL IN] - Existing saving system (DataStore/framework), if any: [FILL IN] - Existing UI and purchase flow rules: [FILL IN] === END OF CONTEXT === Mandatory implementation requirements: 1. Use `MarketplaceService` and `Players`. Centralize gamepass and developer product IDs in readable configuration tables, with comments indicating exactly where to change IDs, names, and rewards. 2. For gamepasses, create a reusable function such as `PlayerOwnsGamePass(player, gamePassId)` that uses `MarketplaceService:UserOwnsGamePassAsync(player.UserId, gamePassId)` wrapped in `pcall`. Cache by UserId during the session, clear the cache in `PlayerRemoving`, and handle API failures without granting an unfair benefit. Apply gamepass benefits when the player joins and provide a clear function to reapply benefits if needed. 3. Connect `MarketplaceService.PromptGamePassPurchaseFinished` only to update the verification/apply the benefit after a confirmed purchase. Never treat this event as the only source of truth: confirm ownership on the server with `UserOwnsGamePassAsync` before granting the permanent benefit. 4. For developer products, implement `MarketplaceService.ProcessReceipt` correctly on the server. The callback must identify the product by `receiptInfo.ProductId`, locate the player by `receiptInfo.PlayerId`, deliver the reward only on the server, and return `Enum.ProductPurchaseDecision.PurchaseGranted` only after successfully completing the grant. If the player is offline, required data is not ready, or a transient error occurs, return `NotProcessedYet` for a retry. 5. Ensure idempotency against duplicate receipts. Use `receiptInfo.PurchaseId` and a persistent processed-record mechanism via DataStore (or integrate with the saving system provided in the context). Explain in comments the receipt reservation/confirmation strategy and avoid marking a purchase as complete before the reward has been effectively saved/granted. If perfect transactional integration is not possible due to the external system in the context, state the limitation and implement the safest possible alternative. 6. Do not trust the client for currency values, inventory, damage, product IDs, or purchase confirmation. If the context includes RemoteEvents to request purchase prompts, the Script must connect `OnServerEvent`, rigorously validate `player`, the argument types, whether the requested ID is in a configured whitelist, and apply rate limiting per player before using `PromptGamePassPurchase` or `PromptProductPurchase`. The client can never specify the reward or call a function that grants it. 7. For rewards, write isolated functions per product and safe examples for currency via leaderstats and attributes. If the context uses a custom system, leave explicit integration points, without creating duplicate currency or inventory systems. Use `warn` with useful context for failures, but do not expose sensitive data. 8. The code must use modern Luau, `--!strict` when viable, useful types, `task.spawn`/`task.wait` only when justified, organized connections, and technical comments in Portuguese. Do not use `loadstring`, external HTTP, client-side solutions to grant purchases, or nonexistent APIs. Do not overwrite another system’s `ProcessReceipt` without warning: if there is an existing handler, explain in a comment that the logic must be consolidated into a single server dispatcher. Mandatory response format: first, present a short list of assumptions and objects I need to confirm. Then, deliver the full code in **a single Markdown ` ```lua ` block**, with no omitted parts and no pseudocode. After the block, provide objective instructions for: configuring IDs, creating/using RemoteEvents, enabling API Services for DataStore testing when appropriate, testing gamepasses and developer products in Roblox Studio using a published experience/purchase tests, and checking `ProcessReceipt` logs. Also include a final security checklist and the test scenarios (repeated purchase, player leaving during processing, DataStore failure, and invalid product).
