大统一收据长度如何处理？
How to deal with the length of Grand Unified Receipts?
我有一个包含许多不同的自动续订订阅的应用程序。当用户订阅新订阅时，收据（Grand Unified Receipt）从应用程序上传到我的服务器，然后发送到 Apple 并返回和解释详细信息。
我注意到当用户订阅了很多订阅时，这张收据会变得很长。此外，收据自然会变长，因为订阅每个月都会自动续订，并且新条目会插入到收据中。
因此，收据的大小可能会变成兆字节大，这对用户的移动服务提出了巨大的数据需求，并且需要在我的服务器上花费大量的处理时间（遍历收据中的所有条目以找到需要记录的那个）。
有没有人对处理这个问题有建议？
是的，这是个问题，但您只需向您的服务器发送一张收据，供 iTunes 用户使用您的应用购买非消费品或订阅商品，换句话说，初始收据验证使您能够访问后续交易通过针对 Apple 的服务器验证 latest_receipt 字符串。
最有效的方法是向您的服务器发送用户首次购买的收据，对于任何后续购买，您只需在 SKPaymentTransaction [上发送 transaction_id 属性 class.
请注意，虽然在我的测试中消费品购买不是这样工作的，但它们存在于收据的 in_app 数组中，但后续收据将不再包含它。因此，如果您想验证这些收据，您必须将这些收据发送给您的服务器。
我有一个包含许多不同的自动续订订阅的应用程序。当用户订阅新订阅时，收据（Grand Unified Receipt）从应用程序上传到我的服务器，然后发送到 Apple 并返回和解释详细信息。
我注意到当用户订阅了很多订阅时，这张收据会变得很长。此外，收据自然会变长，因为订阅每个月都会自动续订，并且新条目会插入到收据中。
因此，收据的大小可能会变成兆字节大，这对用户的移动服务提出了巨大的数据需求，并且需要在我的服务器上花费大量的处理时间（遍历收据中的所有条目以找到需要记录的那个）。
有没有人对处理这个问题有建议？
是的，这是个问题，但您只需向您的服务器发送一张收据，供 iTunes 用户使用您的应用购买非消费品或订阅商品，换句话说，初始收据验证使您能够访问后续交易通过针对 Apple 的服务器验证 latest_receipt 字符串。
最有效的方法是向您的服务器发送用户首次购买的收据，对于任何后续购买，您只需在 SKPaymentTransaction [上发送 transaction_id 属性 class.
请注意，虽然在我的测试中消费品购买不是这样工作的，但它们存在于收据的 in_app 数组中，但后续收据将不再包含它。因此，如果您想验证这些收据，您必须将这些收据发送给您的服务器。