Development / ROBLOX
ProcessReceipt in Roblox: planning Developer Product fulfillment checks
Separate a purchase prompt from fulfillment, a new purchase from repeated processing, and function execution from its result. Define reviewable conditions for a handler before selling a paid product.
Define the promised purchase result #
Begin with a precise promise: a fictional pack adds practice tokens to a player's saved profile. Specify the pack size, usage scope and what should remain after another join. “Granted” is too vague if all you observed was a temporary message on screen.
This article has no working shop, real IDs, purchases or ready handler. It prepares a review plan for an author. A and B are fictional operations, not real player receipts. Do not substitute this plan for a verified sales implementation.
Separate the prompt from server fulfillment #
A displayed prompt only starts a player-facing flow. Documentation separately warns against handling Developer Product fulfillment through PromptProductPurchaseFinished; firing that event does not itself establish a successful purchase. Review receipt handling separately from a button's response.
Record distinct observations: prompt displayed, receipt received, effect confirmed and processing acknowledged to the platform. Do not collapse them into one success event. If only a button animation is visible, the saved profile state is still unknown.
Distinguish the product from the operation #
ProductId identifies the product being handled. PurchaseId distinguishes particular purchases. Two receipts for one ProductId can represent two independent purchases; repeating the same PurchaseId is a different case requiring a check of the previously handled operation.
Our first pair is A handled for the first time, then A delivered again. The second is A followed by a new B for the same product. The first should not repeat A's effect; the second needs B's separate result. Blocking the whole product after its first purchase confuses these tasks.
Open full-size image ↗Do not confuse no exception with a grant #
A protected call can finish without throwing while the inner function declines or fails to grant the item. Our proposed record therefore has two fields: did the call execute, and was the intended effect confirmed? These are separate statements, not one interchangeable flag.
Plan a handler returning false without an exception. The expected response should reflect missing fulfillment, not merely successful function execution. Separately examine an exception and unavailable player state. This article contains no code that produces those outcomes automatically.
Review the effect and the record together #
Persistent tokens require consistent facts: the profile effect and the record of a processed purchase. If a temporary balance changes but completion is not saved, a retry can encounter incomplete state. Recording completion before the effect can incorrectly label an unfulfilled operation as finished.
Draw failure points between stages and describe recovery for each. A normal successful run does not test these gaps. A flag beside a nonpersistent value is not evidence of reliable fulfillment. Persistence and replay architecture require separate review before sales begin.
Specify the chosen API contract #
ProcessReceipt returns Enum.ProductPurchaseDecision. MarketplaceService documentation also includes BindReceiptHandler with distinct receipt types and Enum.ReceiptDecision. Do not mix registration styles or return values from those two contracts in one example.
This article plans a ProcessReceipt review; it does not announce mandatory migration between APIs. Record which contract the implementation uses, where the server handler lives and who registers it. Documentation describes setting ProcessReceipt once from a server script; another script unexpectedly replacing it needs investigation.
Include unavailable fulfillment conditions #
Plan a receipt with an absent player, unknown product or profile that is not ready. For each, identify what evidence is needed to confirm fulfillment. Missing evidence must not become a confident “everything received” message.
Also include a failed save and a later join. Retain minimal technical context and the original observation without publishing personal information or actual receipts on the website. Do not promise a precise retry delay: this plan reviews decisions, not the platform's processing schedule.
Review retries and multiple servers separately #
Testing A twice in one session is useful but does not cover competing processing or failure between an effect change and a save. The API's ProcessReceipt example explicitly states a limitation concerning cross-server data failure. Copying the example does not resolve that issue.
List parallel attempts, replay after an unknown write result and repeated state transformations. Do not introduce irreversible external effects into a repeatable operation without a separately reviewed protocol. These are implementation questions, not proof that our fictional shop is already protected.
Build an expected-outcome matrix #
For each case, record starting state, operation identity, expected change and acknowledgment condition. Begin with A, repeated A and new B, then add an unavailable profile and failed write. The table below provides review questions, not paid-test results.
An expected outcome must refer to the specific operation and persistent effect. “No errors in Output” does not answer the duplicate-grant question. After changing a handler, repeat both the normal path and the case that motivated the change.
| Case | Check |
|---|---|
| First A | Is one effect confirmed? |
| Repeated A | Is another A effect absent? |
| New B | Does B have its own effect? |
| Write failed | How is an unknown result recovered? |
Hand off evidence and open questions #
The handoff card contains product type, chosen API, profile model, retry scenario, observed result and remaining limits. State whether review was conceptual, simulated or performed in a separate test game. Those levels do not automatically establish one another.
Before selling, you need a verified implementation connecting the effect and purchase acknowledgment under failure. This guide helps specify that work; it does not establish sales readiness of your games. Do not make a real purchase to demonstrate an article or label a hypothesis as a verified result.
Open full-size image ↗| Field | Record |
|---|---|
| Contract | Chosen API and return value |
| Operation | Product and specific purchase |
| Effect | Persistent result and replays |
| Evidence | Review type, observation and scope |
Original sources
Roblox Creator Hub — Developer ProductsRoblox Creator Hub — MarketplaceService API
