在什么情况下 SKPaymentTransaction.transactionIdentifier 与验证收据的 transaction_id 相同?
In what scenarios is SKPaymentTransaction.transactionIdentifier the same as the validated receipt's transaction_id?
SKPaymentTransaction.transactionIdentifier
注释的文档:
This value has the same format as the transaction’s transaction_id
in
the receipt; however, the values may not be the same.
以及 transaction_id
注释的文档:
This value has the same format as the transaction’s
transactionIdentifier
property; however, the values may not be the
same.
You can use this value to:
• Manage subscribers in your account
database. Store the transaction_id
, original_transaction_id
, and
product_id
for each transaction, as a best practice to store
transaction records for each customer. App Store generates a new value
for transaction_id
every time the subscription automatically renews or
is restored on a new device.
• Differentiate a purchase transaction from
a restore or a renewal transaction. In a purchase transaction, the
transaction_id
always matches the original_transaction_id
. For
subscriptions, it indicates the first subscription purchase. For a
restore or renewal, the transaction_id
does not match the
original_transaction_id
. If a user restores or renews the same
purchase multiple times, each restore or renewal has a different
transaction_id
.
还将注意交易标识符下的 Receipt Validation Programming Guide(来自文档存档)状态:
This value corresponds to the transaction’s transactionIdentifier
property.
注意到这一点后,我的问题是:SKPaymentTransaction.transactionIdentifier
何时与已验证收据的 transaction_id
具有相同的值,或者何时不是?
在我们的应用中,我们只处理消耗性应用内购买,不支持订阅。在这种情况下,这两个值是否相同?我问是因为我需要能够记录购买服务器端以及有关购买它的用户的信息。请参阅下面的过程和它提出的问题的解释。
假设用户购买了消费品,并且记录该交易的请求失败,例如因为我们的服务器停机,所以我们不调用 finishTransaction:
。现在假设该人注销并登录到另一个用户帐户并购买了另一种消费品,但我们再次未能记录下来。收据中现在有两种消耗品。当他们接下来启动应用程序时,paymentQueue(_:updatedTransactions:)
被调用,其中包含 transactions
数组中的两个项目,以通知我们有 purchased
个交易需要完成。我们需要将收据提交给我们的服务器以记录交易,但我们还需要随每笔交易发送一些附加信息,例如购买它的用户 ID。这意味着我需要将此信息与关联的 transactionIdentifier
保存在磁盘上,以便稍后获取该数据。我可以将一组用户 ID 和收据发送到服务器。但是后端如何知道收据中的哪笔交易与数组中的哪个用户 ID 相匹配呢?我不相信 in_app
数组一定会以任何特定方式排序,并且可能与提供给 paymentQueue(_:updatedTransactions:)
的 transactions
数组的顺序不匹配。那么当有多个交易记录时,我们如何正确地 link 它们以便将购买应用到正确的用户帐户服务器端?在这种情况下,应用内可用的 transactionIdentifier
是否保证与验证收据中的 transaction_id
相同?
在测试中,我们确定 transactionIdentifier
与消耗品购买的验证收据中交易的 transaction_id
的价值相同。
但是,我们不愿意依赖这种情况,因为文档中的说明表明它可能不是相同的值。因此,我们使用 transaction.payment.productIdentifier
和 transaction.transactionDate
的组合来进行回退,以唯一标识交易,即 documented 对应于收据中的 original_purchase_date_ms
。这允许后端在收据中为应用程序提交的信息找到正确的交易。
SKPaymentTransaction.transactionIdentifier
注释的文档:
This value has the same format as the transaction’s
transaction_id
in the receipt; however, the values may not be the same.
以及 transaction_id
注释的文档:
This value has the same format as the transaction’s
transactionIdentifier
property; however, the values may not be the same.You can use this value to:
• Manage subscribers in your account database. Store the
transaction_id
,original_transaction_id
, andproduct_id
for each transaction, as a best practice to store transaction records for each customer. App Store generates a new value fortransaction_id
every time the subscription automatically renews or is restored on a new device.• Differentiate a purchase transaction from a restore or a renewal transaction. In a purchase transaction, the
transaction_id
always matches theoriginal_transaction_id
. For subscriptions, it indicates the first subscription purchase. For a restore or renewal, thetransaction_id
does not match theoriginal_transaction_id
. If a user restores or renews the same purchase multiple times, each restore or renewal has a differenttransaction_id
.
还将注意交易标识符下的 Receipt Validation Programming Guide(来自文档存档)状态:
This value corresponds to the transaction’s
transactionIdentifier
property.
注意到这一点后,我的问题是:SKPaymentTransaction.transactionIdentifier
何时与已验证收据的 transaction_id
具有相同的值,或者何时不是?
在我们的应用中,我们只处理消耗性应用内购买,不支持订阅。在这种情况下,这两个值是否相同?我问是因为我需要能够记录购买服务器端以及有关购买它的用户的信息。请参阅下面的过程和它提出的问题的解释。
假设用户购买了消费品,并且记录该交易的请求失败,例如因为我们的服务器停机,所以我们不调用 finishTransaction:
。现在假设该人注销并登录到另一个用户帐户并购买了另一种消费品,但我们再次未能记录下来。收据中现在有两种消耗品。当他们接下来启动应用程序时,paymentQueue(_:updatedTransactions:)
被调用,其中包含 transactions
数组中的两个项目,以通知我们有 purchased
个交易需要完成。我们需要将收据提交给我们的服务器以记录交易,但我们还需要随每笔交易发送一些附加信息,例如购买它的用户 ID。这意味着我需要将此信息与关联的 transactionIdentifier
保存在磁盘上,以便稍后获取该数据。我可以将一组用户 ID 和收据发送到服务器。但是后端如何知道收据中的哪笔交易与数组中的哪个用户 ID 相匹配呢?我不相信 in_app
数组一定会以任何特定方式排序,并且可能与提供给 paymentQueue(_:updatedTransactions:)
的 transactions
数组的顺序不匹配。那么当有多个交易记录时,我们如何正确地 link 它们以便将购买应用到正确的用户帐户服务器端?在这种情况下,应用内可用的 transactionIdentifier
是否保证与验证收据中的 transaction_id
相同?
在测试中,我们确定 transactionIdentifier
与消耗品购买的验证收据中交易的 transaction_id
的价值相同。
但是,我们不愿意依赖这种情况,因为文档中的说明表明它可能不是相同的值。因此,我们使用 transaction.payment.productIdentifier
和 transaction.transactionDate
的组合来进行回退,以唯一标识交易,即 documented 对应于收据中的 original_purchase_date_ms
。这允许后端在收据中为应用程序提交的信息找到正确的交易。