开发 / ROBLOX
Roblox ProcessReceipt：Developer Product 发放检查计划
区分购买窗口与实际发放、新购买与重复处理，以及函数运行与业务结果。在销售付费商品之前，为处理器建立可以核对的条件与检查记录。
明确购买所承诺的结果 #
先写出准确承诺：一个虚构礼包给玩家的已保存档案增加练习代币。注明数量、用途，以及再次进入时应该保留的状态。如果仅观察到屏幕上的临时提示，“已发放”仍然是含糊的结论。
本文没有运行中的商店、真实 ID、实际购买或现成处理器，而是为创作者准备检查计划。A 与 B 是虚构操作，不是真实玩家收据。这个计划不能代替已经验证的销售实现，也不表示你的游戏已经完成商品发放。
分开窗口和服务器发放 #
窗口出现只表示玩家流程开始。文档明确提醒，不能用 PromptProductPurchaseFinished 处理 Developer Product 发放；事件触发本身不能证明购买成功。收据处理应该与按钮反应分别检查。
分别记录窗口出现、收到收据、确认效果、向平台确认处理结果。不要把这些观察合并成一个“成功”事件。如果只看见按钮动画，保存档案中的状态仍然未知。展示反馈不能替代实际结果的证据。
区分商品与具体购买 #
ProductId 表示所处理的商品，PurchaseId 区分具体购买。相同 ProductId 的两张收据可能来自两次独立购买；相同 PurchaseId 再次到达，则是需要核对已有操作的另一种情况。
第一组情形是首次处理 A，之后再次收到 A。第二组是处理 A 后，收到同一商品的新购买 B。第一组不应该重复 A 的效果，第二组需要 B 自己的结果。首次购买后封锁整个商品，会把这两个任务混为一谈。
打开大图 ↗不要把无异常等同于发放 #
受保护调用可以没有抛出异常，但内部函数可能拒绝处理或没有发放物品。因此建议的记录中有两个字段：调用是否运行，以及目标效果是否得到确认。它们是两个事实，不能由一个标志互相替代。
计划检查“处理函数返回 false，但没有异常”。预期回应应该体现没有完成发放，而不是只体现函数正常运行。异常和玩家状态不可用也要分别检查。本文没有自动产生这些结果的执行代码，不应当作可复制的商品处理器。
一起检查效果和处理记录 #
持久代币需要一致的事实：档案中的效果与已处理购买的记录。临时余额改变但完成记录未保存，重试可能遇到不完整状态。先保存完成记录，再修改效果，也可能把未完成的发放错误标记为完成。
画出阶段之间的故障点，为每一点说明如何恢复。正常成功一次不能检查这些间隙。非持久数值旁边的一个标志不能证明可靠发放。销售前仍需单独检查保存与重放的架构，以及未知结果应该如何处理。
记录所选 API 的契约 #
ProcessReceipt 返回 Enum.ProductPurchaseDecision。MarketplaceService 文档还包含 BindReceiptHandler，使用独立的收据类型与 Enum.ReceiptDecision。不要在一个例子中混用两种契约的注册方式或返回值。
本文为 ProcessReceipt 准备检查计划，并没有宣布必须迁移 API。记录实现采用哪个契约、服务器处理器在哪里，以及由谁注册。文档描述由一个服务器脚本设置一次 ProcessReceipt；如果另一个脚本意外覆盖它，需要进一步调查。
包含无法发放的条件 #
计划检查玩家不在服务器、商品未知或档案尚未准备好的收据。每种情况都要明确，确认发放需要哪些证据。缺少这些证据时，不能给出肯定的“全部收到”消息，也不能把等待误写为完成。
还要包含保存失败和再次进入。保留最少的技术上下文与最初观察，不把个人数据或真实收据发布到网站。不要承诺重试的精确延迟：这里检查决策逻辑，不是平台的处理时间表或到账保证。
分别检查重复与多服务器 #
在同一会话中处理 A 两次是有用的检查，但不能覆盖并发处理，或效果改变与保存之间发生的故障。API 的 ProcessReceipt 示例明确说明了跨服务器数据故障方面的限制。复制该示例不会消除这个问题。
把并行尝试、写入结果未知后的重放，以及可重复状态转换列入计划。没有单独审查的协议，不要把不可逆外部效果放入可重复操作。这些是实现需要回答的问题，不是我们的虚构商店已具备防护的证明。
建立预期结果矩阵 #
每种情况记录初始状态、操作标识、预期改变和确认条件。先列 A、重复 A 与新 B，再加入未准备好档案和写入失败。下表提供检查问题，不是实际付费测试结果，也不表示已经执行购买。
预期结果必须关联具体操作与持久效果。“Output 没有错误”并不能回答是否重复发放。修改处理器之后，既要重走正常路线，也要重新检查导致修改的情况，保留不同场景的观察记录。
| 情况 | 检查问题 |
|---|---|
| 首次 A | 是否确认一个效果？ |
| 重复 A | 是否没有 A 的第二次效果？ |
| 新 B | B 是否有自己的效果？ |
| 写入失败 | 如何恢复未知结果？ |
交接证据与未解决问题 #
交接卡包含商品类型、选用 API、档案模型、重试场景、实际观察和剩余限制。标明检查是概念分析、模拟，还是在独立测试游戏中执行。不同层级不会自动互相证明，模拟成功不能代表平台销售已经可靠。
销售前需要经过验证的实现，在故障条件下仍能连接效果与购买确认。本文帮助描述该任务，不证明你的游戏已准备好销售。不要为了展示文章去真实购买，也不要把一个假设称作已经证实的结果。
打开大图 ↗| 字段 | 记录内容 |
|---|---|
| 契约 | 选用 API 与返回值 |
| 操作 | 商品与具体购买 |
| 效果 | 持久结果与重放 |
| 证据 | 检查类型、观察和范围 |
原始资料
Roblox Creator Hub — Developer ProductsRoblox Creator Hub — MarketplaceService API
