在应用程序购买中，用户在应用程序处于后台时取消交易：交易状态保持购买状态
当应用程序处于后台且用户尚未登录商店时，我在应用程序购买（沙盒环境）中取消用户时出现一些奇怪的行为：
过程如下：
- 用户未登录/应用程序 ID 未设置在设置>商店
- 用户单击购买按钮。这会调用
[[SKPaymentQueue defaultQueue] addPayment: payment]; - 用户立即按下主页按钮（应用程序转到后台）
- 会出现 Storekit 弹出窗口，要求确认购买。用户取消
- 应用再次激活，并希望收到
- (void) paymentQueue:(SKPaymentQueue *)queue UpdatedTransactions:(NSArray *)transactions，但没有。 TX仍处于国家采购状态。
如果测试用户已经登录到商店，则此过程会有所不同。在这种情况下，上述过程将按预期进行。
另一句话：经过上述步骤后，我实际上购买了另一个应用内商品（包括登录应用商店）。此后，我将应用程序发送到后台并重新激活它，它将处理以前丢失的取消交易。
结论： 用户在应用程序处于后台且未登录商店时取消付款交易会导致 storekit 回调延迟传送。交付是在用户实际登录应用商店后完成的，并且通过重新激活应用程序来触发 PaymentQueue 流程。
这种行为似乎是错误的，如果它实际上是在真实环境中，我可能会认为这是一个 Storekit 错误。有人经历过同样的行为或者可以指出一些事情来防止交易在购买状态下“挂起”吗？
谢谢， 马库斯
I have some odd behavior with User canceling in App Purchase (Sandbox Environment) while the app is in background and the user is not yet logged in to the store:
The process is as follows:
- User is not logged in/App Id is not set in Settings > Store
- User clicks buy button. This calls
[[SKPaymentQueue defaultQueue] addPayment:payment]; - User immediatly preses home button (app goes to background)
- Storekit popup appears asking to confirm purchase. User cancels
- App is activated again and would expect to recieve
- (void)paymentQueue:(SKPaymentQueue *)queue updatedTransactions:(NSArray *)transactions, but does not. The TX is still in state purchasing.
This process is different, if the testuser is logged in to the store already. In that case the above process works as expected.
Another remark: After the above steps, I actually buy another in-App item (inlcuding logging in to the appstore). After this I sent the app to backgrounding and reactivate it and it will process the fomerly missing cancel transaction.
Conclusion:
A user canceling a payment tx while the app is in background and not being logged in to the store results in late delivery of the storekit callback. Delivery is done after the user actually logged in to the appstore and the PaymentQueue process gets triggered by reactivating the app.
This behavior seems to be wrong and if it is actually like that in real environment, I might consider this a Storekit bug. Has someone experienced the same behavior or can indicate something to prevent a tx "hanging" in purchasing state?
Thanks,
Marcus
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
我不相信您可以信赖 Store Kit 的任何东西。按下“购买”按钮后，不要“期待地等待”交易排队，而是继续做你的事情。当您收到有交易的通知（可能是明天）时，请对其进行处理。我相信文档中对此有评论——您的应用程序应该在启动时注册 SK 通知，并且应该随时收到它们。因此，当涉及到 Store Kit 时，不要在您的应用程序中建立任何“状态”意识。只需在交易到达时进行处理即可。
I don't believe you can count on ANYTHING when it comes to Store Kit. Rather than "waiting expectantly" for the transaction to be queued after the "Buy" button is pressed, just go on about your business. When you are notified that there are transactions (which could be tomorrow) process them. I believe there's a comment to this effect in the documentation -- that your app should register for SK notifications when it's launched and it should expect to get them at any time. So don't build any awareness of "state" into your app when it comes to Store Kit. Just process the transactions as they arrive.