# developerPayload处理机制及使用建议

支持开发者在创建订单/订阅订单时通过传入的PurchaseParameter设置developerPayload字段。developerPayload一般用于识别已支付的购买订单是由哪个应用账号发起的购买，并将此购买订单的相关权益正确发放给对应的应用账号。

**在订阅型商品购买场景下developerPayload处理机制**：

*   初次购买场景
    
    如果用户在初次购买订阅时传入了developerPayload，那么该developerPayload将与此订阅绑定，后续此订阅整个生命周期内该developerPayload均将保持不变。
    
*   恢复订阅场景
    
    如果开发者在恢复订阅时传入了新的developerPayload，那么此订阅的developerPayload将刷新为新传入的值，将会影响其后所有事件通知中的developerPayload，如果此时未传入新的developerPayload值，developerPayload保持不变。
    
*   切换订阅场景
    
    切换订阅可以理解为老订阅撤销、新订阅创建这两个过程。切换后的新订阅将使用切换时传入的developerPayload为初始值，如果在切换时没有传入新的developerPayload，那么新订阅将继承老订阅的developerPayload，后续新订阅developerPayload的处理机制参考初次购买场景。
    
*   用户在订阅管理页面操作订阅的场景
    
    用户在订阅管理界面对订阅的操作，包括暂停、取消、恢复等，不会改变原有订阅的developerPayload。用户在订阅管理页面切换订阅时，新订阅将继承老订阅的developerPayload。
    

**developerPayload使用建议：**

1.  请开发者使用应用帐号相关信息作为developerPayload。
    
    基于隐私保护的最小化原则，建议开发者使用单向哈希或加密来混淆应用帐号信息生成标识符，并将此标识符作为developerPayload，此标识符应与应用帐号信息固定关联，此标识符在应用账号的整个生命周期内均有效。
    
2.  由于订阅存在developerPayload刷新机制，同时订阅的生命周期可能很长，因此强烈建议开发者不要使用业务订单号作为developerPayload来确定订阅的归属，此方式可能在业务订单失效或丢失时导致无法确定订阅归属。