My app offers auto renewable subscriptions, I have couple of questions regarding how to model the subscriptions at server side, Is originalTransactionId will ever change for a subscription? Will it stay same in case of subscription upgrade/downgrade/crossgrade? If it changes on product change then how do i keep track that the subscription was a continuous subscription and not a new one? Is the webhook payload contains any identifier of which apple account purchase the subscription? I am having issues maintaining sync between the app account's current subscription and the local apple account's subscription, is there any doc regarding this? Will be really helpful

Hi all, I've received emails from other apps after making a purchase, with content like: You have purchased {App Name} on {Date & Time} and acknowledged that if you download or use this in-App Purchase within fourteen days of buying it, you will no longer be eligible to cancel this purchase. Do anyone know under what circumstances Apple sends a Purchase Confirmation Letter to the user's email after they purchase our digital products via IAP? Is this something developers can control? Additionally, I've seen pop-up reminders before making a payment in apps, with content similar to the above message. Are these reminders provided by Apple, or can developers create their own guidance to help users avoid accidental purchases? Kindly, Vanto

Hello, Our app has been released in Korea with an external payment feature. The function that must display the required modal for external payments is as follows: let result = try await ExternalPurchase.presentNoticeSheet() guard result != .cancelled else { return } However, while testing in the development environment, the API returns a result of continuedWithExternalPurchaseToken(token: String), but in the version distributed through the App Store, it returns cancelled. We would like to know how we can receive the continuedWithExternalPurchaseToken result in the App Store version. Thank you for your guidance. If anyone here has experienced a similar issue or found a solution, I would greatly appreciate your insights as well.

Hi Apple Developer Team, I'm looking to confirm some technical details regarding the pre-order flow and App Store receipt handling. Specifically, I have the following questions: Q1: After a user installs an app via pre-order and launches it for the first time, will a valid App Store receipt be available immediately via [[NSBundle mainBundle] appStoreReceiptURL]? Are there any known cases where the receipt might be missing or invalid, requiring a manual refresh (e.g., via SKReceiptRefreshRequest)? Q2: Is the pre-order flow currently supported in the sandbox environment? Specifically, is it possible to simulate pre-ordering an app and installing it in a sandbox or TestFlight environment, in order to test receipt generation and related logic? https://developer.apple.com/documentation/appstorereceipts/responsebody/receipt Q3: The receipt field in the App Store receipt structure is marked as deprecated. Is it still acceptable to use this field for validating receipts? Has Apple announced any timeline or system version in which this field will be fully removed or unsupported?

I am finding that the verifyReceipt endpoint used to verify a receipt is failing on occassion starting around October 27, 2015. I realize this API is deprecated. I am using cURL to call verifyReceipt. The specific errors are 52 - Empty reply from server and 56 - Connection closed abruptly. This indicates an issue with Apple's server as I understand it. Is anyone else experiencing this as well?

Hello all, We developed an iOS app which we started advertising now. In our iOS app we already implemented the updatePostbackConversionValue(_:completionHandler:) to send in-app events in increasing numbers (first open -> 1, lead ->2, conversion -> 3). From our understanding this should be enough for alle ad networks (Apple Ads, Google Ads, Meta Ads, Microsoft Ads and Reddit Ads) to receive those numbers - at least they receive the app installs from the SKAN already. Is this correct or do we miss something here in the integration? We currently really struggle to assure that everything is working and we do not see any conversions coming in - even though two weeks of advertising have passed already. I look forward for any feedback or discussion and I am also happy to share more details if needed. Best regards, Manuel

One of our customers subscribed to a monthly plan on August 16 but the server-to-server notification seems to have been sent on August 18. What could be the reasons for such a delay between the purchase and the server-to-server notification which are usually sent right after the purchase? The receipt sent along with the notification seems to confirm that the receipt has only been created 2 days after the purchase. Here is an extract: { "environment": "Production", "receipt": { "receipt_type": "Production", "bundle_id": "fr.gaumontvideo.gaumontclassique", "application_version": "613", "receipt_creation_date": "2025-08-18 13:00:16 Etc/GMT", "receipt_creation_date_ms": "1755522016000", "receipt_creation_date_pst": "2025-08-18 06:00:16 America/Los_Angeles", "request_date": "2025-08-25 13:08:27 Etc/GMT", "request_date_ms": "1756127307346", "request_date_pst": "2025-08-25 06:08:27 America/Los_Angeles", "original_purchase_date": "2022-05-11 06:14:37 Etc/GMT", "original_purchase_date_ms": "1652249677000", "original_purchase_date_pst": "2022-05-10 23:14:37 America/Los_Angeles", "original_application_version": "265", "in_app": [ { "quantity": "1", "product_id": "fr.gaumontvideo.gaumontclassique.subscription.monthly.apple", "transaction_id": "270002386706194", "original_transaction_id": "270002386706194", "purchase_date": "2025-08-16 08:02:06 Etc/GMT", "purchase_date_ms": "1755331326000", "purchase_date_pst": "2025-08-16 01:02:06 America/Los_Angeles", "original_purchase_date": "2025-08-16 08:02:08 Etc/GMT", "original_purchase_date_ms": "1755331328000", "original_purchase_date_pst": "2025-08-16 01:02:08 America/Los_Angeles", "expires_date": "2025-09-16 08:02:06 Etc/GMT", "expires_date_ms": "1758009726000", "expires_date_pst": "2025-09-16 01:02:06 America/Los_Angeles" } }

I have consumable IAPs in my app. Currently there is no way for me to test refunds for them as Xcode testing doesn't allow refunds option for my Purchases. According to this official documentation on Transaction.all , i should be getting my refunded consumables in Transaction's all property. But there is no way for me to know what kind of data is in the refunded transaction object. Will there be a 'revocation date' like in the case of non-consumables?

Description of the Issue We are encountering issues with App Store Server Notifications, where the notification type received does not align with our expectations for subscription changes. Specifically, we receive DID_RENEW notifications in scenarios involving downgrades or intra-tier upgrades, which disrupts our backend subscription management logic and may lead to incorrect user subscription states and billing errors. Below are two reproducible scenarios with associated transaction data. Scenario 1: Downgrade from Premium Yearly (with 7-Day Trial) to Standard Yearly Steps to Reproduce: A user purchases the Premium Yearly subscription with a 7-day free trial (initial transaction ID: 700002116066502). On the day before the trial ends, the user downgrades to the Standard Yearly subscription via the App Store’s subscription management interface. Expected Behavior: We expect to receive a DID_CHANGE_RENEWAL_STATUS or a similar downgrade notification (e.g., DID_CHANGE_RENEWAL_PREF) to indicate the subscription plan has been downgraded, enabling immediate updates to the user’s subscription status. Actual Behavior: Upon downgrade, our server receives a DID_RENEW notification instead of a downgrade-specific notification. This causes our system to incorrectly interpret the action as a renewal of the Premium subscription rather than a downgrade to Standard, with no subsequent downgrade confirmation received. Relevant Transaction Data: New Transaction ID: 700002122810952 Notification Type: DID_RENEW Notification UUID: 26de9b0e-5d61-4893-b679-0bd18ae3d208 Original Transaction ID (Trial): 700002116066502 Scenario 2: Intra-Tier Upgrade from Standard Monthly to Standard Yearly Steps to Reproduce: A user purchases the Standard Monthly subscription. On the day before the monthly subscription expires, the user switches to the Standard Yearly subscription via the App Store’s subscription management interface. Expected Behavior: The original Monthly subscription expires normally, with a DID_EXPIRE notification received. Upon expiration, we expect a DID_RENEW or SUBSCRIBED notification for the new Yearly subscription to confirm its activation, allowing seamless transition of the user’s subscription plan. Actual Behavior: Immediately after the upgrade, our server receives a DID_RENEW notification for the new Yearly plan. No further notifications are received, including no DID_EXPIRE for the original Monthly subscription. This leaves our system unable to confirm the expiration of the Monthly plan, potentially resulting in duplicate active subscriptions in our records. Relevant Transaction Data: Transaction ID: 70002902074491 Notification Type: DID_RENEW Notification UUID: 3d35bc2f-e769-4549-bf50-d84d41b10342 Impact These notification discrepancies disrupt our subscription lifecycle management, potentially causing incorrect user entitlements, over-billing, and a degraded user experience. Requested Assistance Please confirm the correct notification types for these scenarios as per Apple’s documentation (e.g., App Store Server Notifications V2). Provide guidance on handling these edge cases, including any recent changes to notification logic. If this is a backend issue, please investigate the provided transaction IDs and Notification UUIDs. Thank you for your prompt assistance. We look forward to your response to help resolve this issue for our users. 问题描述： 我们在处理 App Store 订阅变更通知时发现，服务器接收到的通知类型与预期不符，具体表现为降级或同级升级场景下错误接收到 DID_RENEW 通知。这影响了我们后端订阅管理的逻辑，可能导致用户订阅状态和计费出现偏差。以下是两个可重现的场景及相关交易数据。 场景 1：高级年费（含 7 天试用）降级至标准年费 重现步骤： 用户购买高级年费订阅并开启 7 天免费试用（初始交易 ID：700002116066502）。 在试用期结束前一天，用户通过 App Store 的订阅管理界面降级至标准年费订阅。 预期行为： 我们预期会收到 DID_CHANGE_RENEWAL_STATUS 或类似的降级通知（如 DID_CHANGE_RENEWAL_PREF），以表明订阅计划已降级，从而允许我们立即更新用户订阅状态。 实际行为： 降级后，服务器立即收到 DID_RENEW 通知，而非降级相关通知。这导致系统误认为高级订阅仍在续订，而非降级为标准订阅，且后续未收到任何降级确认通知。 相关交易数据： 新交易 ID：700002122810952 通知类型：DID_RENEW 通知 UUID：26de9b0e-5d61-4893-b679-0bd18ae3d208 原始交易 ID（试用）：700002116066502 场景 2：标准月费订阅升级为标准年费订阅 重现步骤： 用户购买标准月费订阅。 在月费订阅到期前一天，用户通过 App Store 的订阅管理界面切换至标准年费订阅。 预期行为： 原月费订阅正常到期，预期收到 DID_EXPIRE 通知。 月费到期后，预期收到新年费订阅的 DID_RENEW 或 SUBSCRIBED 通知，以确认年费订阅开始，方便我们无缝切换用户订阅计划。 实际行为： 升级后，服务器立即收到新年费订阅的 DID_RENEW 通知。 后续未收到任何通知，包括原月费订阅的 DID_EXPIRE 通知。这导致我们无法确认月费订阅的到期状态，可能在记录中出现重复的活跃订阅。 相关交易数据： 交易 ID：70002902074491 通知类型：DID_RENEW 通知 UUID：3d35bc2f-e769-4549-bf50-d84d41b10342 影响： 这些通知异常干扰了我们的订阅生命周期管理，可能导致用户权益错误、潜在的重复计费以及用户体验下降。 请求协助： 请确认根据 Apple 文档（例如 App Store Server Notifications V2）在上述场景中应返回的正确通知类型。 请提供处理此类边缘场景的指导，包括通知逻辑的任何最新变更。 如果这是后端问题，请调查提供的交易 ID 和通知 UUID。 感谢您的及时协助，期待您的回复以帮助我们为用户解决问题。

After downloading Backyard Birds and following the steps in the section "Configure the sample code project" (i.e. enabling local StoreKit testing in the scheme). When I run the macOS app from within XCode, the following error occurs. Whenever I try to purchase any item from within the app, I am presented with the following error dialogue: "Couldn’t communicate with a helper application. Try your operation again. If that fails, quit and relaunch the application and try again." This happens after I click the purchase button (i.e. the button that displays the price). The Xcode logs show the following errors: Error handling payment sheet request: Error Domain=NSCocoaErrorDomain Code=4099 "The connection to service created from an endpoint was invalidated from this process." UserInfo={NSDebugDescription=The connection to service created from an endpoint was invalidated from this process.} Type: Error | Timestamp: 2025-09-26 18:05:36.214491+02:00 | Process: Backyard Birds | Library: StoreKit | Subsystem: com.apple.storekit | Category: Default | TID: 0xafed followed by Purchase did not return a transaction: Error Domain=ASDErrorDomain Code=5115 "Received failure in response from Xcode" UserInfo={NSDebugDescription=Received failure in response from Xcode, NSUnderlyingError=0x600001545470 {Error Domain=NSCocoaErrorDomain Code=4099 "The connection to service created from an endpoint was invalidated from this process." UserInfo={AMSDescription=Ein unbekannter Fehler ist aufgetreten. Versuche es erneut., AMSURL=http://localhost:49244/WebObjects/MZBuy.woa/wa/inAppBuy, NSDebugDescription=The connection to service created from an endpoint was invalidated from this process., AMSStatusCode=200, AMSServerPayload={ "app-list" = ( ); dialog = { cancelButtonString = Cancel; defaultButton = Buy; explanation = "Do you want to buy one Box of Nutrition Pellets for $3.99?\n\n[Environment: Xcode]"; initialCheckboxValue = 1; "m-allowed" = 0; message = "Confirm Your In-App Purchase"; okButtonAction = { buyParams = "bid=com.example.apple-samplecode.Backyard-BirdsHQN4U5V5MY&bvrs=1.0&offerName=pellet.box&quantity=1&deviceVerification=0aee9116-fef7-5d20-b21b-b28848615717&storekitViewInitiated=true"; itemName = "pellet.box"; kind = Buy; }; okButtonString = Buy; paymentSheetInfo = { caseControl = true; confirmationTitle = Pay; countryCode = US; currency = USD; designVersion = 2; displayPrice = "$3.99"; flexList = ( { value = ( { style = priceMain; value = "$3.99"; }, { style = priceSub; value = "One-time charge"; } ); }, { header = "$null"; value = "For testing purposes only. You will not be charged for confirming this purchase."; } ); price = "3.99"; requestor = AppStore; salableIcon = "http://localhost:49244/StoreKit/AppIcon?bid=com.example.apple-samplecode.Backyard-BirdsHQN4U5V5MY"; salableIconType = app; salableInfo = ( "Box of Nutrition Pellets %%image_0%%", "Backyard Birds", "In-App Purchase" ); styles = ( { bold = true; name = priceMain; size = large; }, { color = gray; name = priceSub; }, { bold = true; name = priceMainSpaceBefore; size = large; spacingBefore = medium; } ); title = { type = text; value = Xcode; }; }; }; "download-queue-item-count" = 0; dsid = 17322632127; failureType = 5115; jingleAction = inAppBuy; jingleDocType = inAppSuccess; pings = ( ); }}}} Type: Error | Timestamp: 2025-09-26 18:05:36.346918+02:00 | Process: Backyard Birds | Library: StoreKit | Subsystem: com.apple.storekit | Category: Default | TID: 0xafea I am running Xcode Version 26.0.1 (17A400) macOS Sequia 15.7 What I have tried so far: created a new admin user, logged in as that user, installed Xcode and ran the Backyard Bird sample from there. Same error. This also happens with my own app, when I am trying to test purchasing. How can I further debug this problem?

Can you implement storekit2 for in app purchases for a flutter project?

Question on token testing in development: Hello, I'm developing a React Native application using StoreKit External Purchase. I'm having difficulties testing the transaction token retrieval in the development environment. Specific questions: Is it possible to test the transaction token retrieval in development/sandbox environment? Is there a special testing mode for developers that would allow simulating token reception without going through the App Store? Are there specific debugging tools to verify proper token reception? Question on native implementation: Regarding the native implementation of StoreKit External Purchase: Is there detailed documentation on creating native modules for React Native that implement StoreKit External Purchase? Can you confirm if the following approach is correct for native implementation: Using NSClassFromString(@"ExternalPurchase") Calling presentNoticeSheetWithURL:completion: Retrieving the token in the completion block Are there any code examples for complete native implementation? Question on implementation validation: For validating StoreKit External Purchase implementation: How can we verify that our implementation is correct before App Store submission? Are there validation tools or automated tests to check compliance? What are common errors to avoid during implementation? Question on best practices: Regarding implementation best practices: What's the best way to handle potential errors during token retrieval? How to handle cases where the user cancels the transaction? What are the recommended security checks for server-side token validation? Question on documentation: I'm looking for additional resources on StoreKit External Purchase: Is there specific documentation for integration with frameworks like React Native? Are there complete code examples for native implementation? Where can I find information about testing and debugging best practices? Additional technical question: Technical implementation details: What's the correct way to handle the ExternalPurchase class initialization in React Native native modules? Are there specific requirements for the URL passed to presentNoticeSheetWithURL? How should we handle the token in the completion block to ensure it's properly passed back to React Native? Question on testing workflow: Testing workflow questions: What's the recommended testing workflow for External Purchase implementation? How can we verify the token format and validity before production deployment? Are there any tools or methods to simulate the complete purchase flow in development?

Hello Fellow Developers, I recently built a simple craft related app called "Genie Crystals" with a landing page. there is a button on landing page which redirects to a main template generator page. Here the user can play with the parameters and create an output which can be exported. to export there is an unlock button which is linked to the in-app purchase configured in the app. Initially it was not capturing price properly so I modified the code slightly to keep the button in disabled state until the product details got fetched in background asynchronously. But when I released the app and downloaded it on a different device at the time of load itself, I am getting the alert - product not available. I have used correct product Id in the program. I have confirmed that. I think I am missing something. Any help will be appreciated. I am new to this so if I need to share any additional information kindly let me know. Thanks.

Hello, Our app supports family sharing skus, we successfully ran tests on family sharing features in sandbox, we noticed the feature does not work on live builds. The family member (child account) do see the subscription as "Shared with you". We attempted to restore multiple time and there is nothing to restore.

When I added the ExcelIO library to my app and compiled it, the following error occurred: Framework 'SwiftSpreadsheet' not found Linker command failed with exit code 1 (use -v to see invocation) I added the following to my Podfile and installed it, but the error persists. (No errors occurred during pod install.) platform :ios, '9.0' Pods for medical_expense target 'medical_expense' do Comment the next line if you don't want to use dynamic frameworks use_frameworks! pod 'SwiftyTesseract', '~ 2.0' pod 'SwiftSpreadsheet' end Pods for Petty_staff target 'Petty_staffTests' do inherit! :search_paths pod 'ReachabilitySwift' Pods for testing end target 'Petty_staffUITests' do inherit! :search_paths Pods for testing end Note that "SwiftSpreadsheet" exists in /Users/ymdakr/MyAppli/Medical_Expense/Pods/Target Support Files/Pods-medical_expense/Pods-medical_expense.debug.xcconfig and /Users/ymdakr/MyAppli/Medical_Expense/Pods/Target Support Files/Pods-medical_expense/Pods-medical_expense.release.xcconfig Only in [Files/Pods-medical_expense/Pods-medical_expense.debug.xcconfig] What should I do?

I have been receiving beta software from the iPad App Store, despite not being enrolled in a beta program. Additionally, I do not have TestFlight or the Feedback app installed on my device. There are no certificates or profiles displayed either. I am using the App Store app that comes preinstalled on my device (note that I am not located in Europe). My iPad has been experiencing significant bugs, including numerous screen glitches and periods of sluggishness. Furthermore, numerous applications have crashed frequently. I was able to confirm that I was receiving beta software because the crash reports include beta identifier numbers. According to Apple documentation regarding analytic reports, a beta identifier will only be visible for beta applications. anyone know what could be going on or how to fix this?

Product Timeout, In App purchase is approved in App Store Connect. The Product ID and Bundle ID match. Environment macOS App in TestFlight Bundle ID: com.streamtime.StreamTime App Version: 1.1 (Build 51) StoreKit 2 Product ID: com.streamtime.premium Status: App & Subscription Approved Issue StoreKit product request (Product.products(for:)) consistently times out after 60 seconds in TestFlight, despite all connectivity checks passing. The same code works perfectly in Xcode with local StoreKit configuration. Diagnostic Results ✅ Successful checks: App Store connectivity (HTTP 200 from buy.itunes.apple.com) Backend API connectivity (HTTP 200) StoreKit 2 API available AppStore.canMakePayments: true Valid receipt exists Bundle ID matches Product ID matches approved subscription ❌ Failing: Product request times out after 60 seconds No products returned Code Implementation // Direct product request (fails in TestFlight) let products = try await Product.products(for: ["com.streamtime.premium"]) Logs 🔍 App Bundle ID: com.streamtime.StreamTime 🔍 Product ID: com.streamtime.premium 🔍 AppStore.canMakePayments: true 🔍 Apple Store connectivity: HTTP 200 🔵 Direct request for product ID: 'com.streamtime.premium' ⏱️ Direct request start time: 2025-08-30 10:21:32 +0000 ❌ TIMEOUT: Product request took longer than 60 seconds What I've Tried Removed manual in-app-purchase entitlement (per Apple's guidance) Using automatic signing Verified subscription is approved in App Store Connect Using Sandbox Apple ID in TestFlight Verified all network connectivity Questions Why does StoreKit timeout only in TestFlight when all other connectivity works? Are there additional configuration steps needed for macOS apps vs iOS? Could this be related to the automatic in-app purchase entitlement? Any guidance would be greatly appreciated as this is blocking our TestFlight validation.

Is there an App Store Server API available that allows cancellation of specific subscriptions by specifying transaction_id or similar identifiers? Background of these questions: We occasionally suspend user accounts due to violations of our service terms and conditions. In such cases, we would like to forcibly cancel their subscriptions if possible. However, we could not find relevant information in the documentation, which is why we are reaching out with these questions. Please let us know.

Hello. I have setup a StoreKit testing in the app that was and still is perfectly working on iOS 18. Unfortunately when run on iOS 26 the following error gets printed in the console after calling Transaction.currentEntitlement(for:) method: Failed to verify certificate chain due to client recoverable failure: Error Domain=NSOSStatusErrorDomain Code=-67843 "“StoreKit Testing in Xcode” certificate is not trusted" UserInfo={NSLocalizedDescription=“StoreKit Testing in Xcode” certificate is not trusted, NSUnderlyingError=0x109de7e10 {Error Domain=NSOSStatusErrorDomain Code=-67843 "Certificate 0 “StoreKit Testing in Xcode” has errors: Root is not trusted;" UserInfo={NSLocalizedDescription=Certificate 0 “StoreKit Testing in Xcode” has errors: Root is not trusted;}}} I'm not seeting any StoreKit Testing certificates in phone's certificate trust settings. This test was performed on iOS 26.0 (23A341) with app built in Xcode 16.4. FB20339145

代码块 让购买结果=尝试等待购买（产品，选项：[选项]） //处理支付结果 开关购买结果{ 案例让.success（验证结果）： 如果案例让.verified（交易）=验证结果{ await transaction.finish()case .userCancelled: 自我.取消回调？（） 案例.pending： /// 交易可能在未来成功，通过Transaction.updates进行通知。 打印（“苹果支付中待定”） 默认： 打破 } } 抓住 { 自我失败回电话？（”产品购买失败：\(错误)") 打印（“产品购买失败：\（错误）”） } 凭证相关信息如下： transactionid：1230000065994257 appAccountToken：D613C126-4142-4BFF-9960-00AE3F5A6F83 "jwsInfo": ["header": "eyJhbGciOiJFUzI1NiIsIng1YyI6WyJNSUlFTURDQ0E3YWdBd0lCQWdJUWZUbGZkMGZOdkZXdnpDMVlJQU5zWGpBS0JnZ3Foa2pPUFFRREF6QjFNVVF3UWdZRFZRUURERHRCY0hCc1pTQlhiM0pzWkhkcFpHVWdSR1YyWld4dmNHVnlJRkpsYkdGMGFXOXVjeUJEWlhKMGFXWnBZMkYwYVc5dUlFRjFkR2h2Y21sMGVURUxNQWtHQTFVRUN3d0NSell4RXpBUkJnTlZCQW9NQ2tGd2NHeGxJRWx1WXk0eEN6QUpCZ05WQkFZVEFsVlRNQjRYRFRJek1Ea3hNakU1TlRFMU0xb1hEVEkxTVRBeE1URTVOVEUxTWxvd2daSXhRREErQmdOVkJBTU1OMUJ5YjJRZ1JVTkRJRTFoWXlCQmNIQWdVM1J2Y21VZ1lXNWtJR2xVZFc1bGN5QlRkRzl5WlNCU1pXTmxhWEIwSUZOcFoyNXBibWN4TERBcUJnTlZCQXNNSTBGd2NHeGxJRmR2Y214a2QybGtaU0JFWlhabGJHOXdaWElnVW1Wc1lYUnBiMjV6TVJNd0VRWURWUVFLREFwQmNIQnNaU0JKYm1NdU1Rc3dDUVlEVlFRR0V3SlZVekJaTUJNR0J5cUdTTTQ5QWdFR0NDcUdTTTQ5QXdFSEEwSUFCRUZFWWUvSnFUcXlRdi9kdFhrYXVESENTY1YxMjlGWVJWLzB4aUIyNG5DUWt6UWYzYXNISk9OUjVyMFJBMGFMdko0MzJoeTFTWk1vdXZ5ZnBtMjZqWFNqZ2dJSU1JSUNCREFNQmdOVkhSTUJBZjhFQWpBQU1COEdBMVVkSXdRWU1CYUFGRDh2bENOUjAxREptaWc5N2JCODVjK2xrR0taTUhBR0NDc0dBUVVGQndFQkJHUXdZakF0QmdnckJnRUZCUWN3QW9ZaGFIUjBjRG92TDJObGNuUnpMbUZ3Y0d4bExtTnZiUzkzZDJSeVp6WXVaR1Z5TURFR0NDc0dBUVVGQnpBQmhpVm9kSFJ3T2k4dmIyTnpjQzVoY0hCc1pTNWpiMjB2YjJOemNEQXpMWGQzWkhKbk5qQXlNSUlCSGdZRFZSMGdCSUlCRlRDQ0FSRXdnZ0VOQmdvcWhraUc5Mk5rQlFZQk1JSCtNSUhEQmdnckJnRUZCUWNDQWpDQnRneUJzMUpsYkdsaGJtTmxJRzl1SUhSb2FYTWdZMlZ5ZEdsbWFXTmhkR1VnWW5rZ1lXNTVJSEJoY25SNUlHRnpjM1Z0WlhNZ1lXTmpaWEIwWVc1alpTQnZaaUIwYUdVZ2RHaGxiaUJoY0hCc2FXTmhZbXhsSUhOMFlXNWtZWEprSUhSbGNtMXpJR0Z1WkNCamIyNWthWFJwYjI1eklHOW1JSFZ6WlN3Z1kyVnlkR2xtYVdOaGRHVWdjRzlzYVdONUlHRnVaQ0JqWlhKMGFXWnBZMkYwYVc5dUlIQnlZV04wYVdObElITjBZWFJsYldWdWRITXVNRFlHQ0NzR0FRVUZCd0lCRmlwb2RIUndPaTh2ZDNkM0xtRndjR3hsTG1OdmJTOWpaWEowYVdacFkyRjBaV0YxZEdodmNtbDBlUzh3SFFZRFZSME9CQllFRkFNczhQanM2VmhXR1FsekUyWk9FK0dYNE9vL01BNEdBMVVkRHdFQi93UUVBd0lIZ0RBUUJnb3Foa2lHOTJOa0Jnc0JCQUlGQURBS0JnZ3Foa2pPUFFRREF3Tm9BREJsQWpFQTh5Uk5kc2twNTA2REZkUExnaExMSndBdjVKOGhCR0xhSThERXhkY1BYK2FCS2pqTzhlVW85S3BmcGNOWVVZNVlBakFQWG1NWEVaTCtRMDJhZHJtbXNoTnh6M05uS20rb3VRd1U3dkJUbjBMdmxNN3ZwczJZc2xWVGFtUllMNGFTczVrPSIsIk1JSURGakNDQXB5Z0F3SUJBZ0lVSXNHaFJ3cDBjMm52VTRZU3ljYWZQVGp6Yk5jd0NnWUlLb1pJemowRUF3TXdaekViTUJrR0ExVUVBd3dTUVhCd2JHVWdVbTl2ZENCRFFTQXRJRWN6TVNZd0pBWURWUVFMREIxQmNIQnNaU0JEWlhKMGFXWnBZMkYwYVc5dUlFRjFkR2h2Y21sMGVURVRNQkVHQTFVRUNnd0tRWEJ3YkdVZ1NXNWpMakVMTUFrR0ExVUVCaE1DVlZNd0hoY05NakV3TXpFM01qQXpOekV3V2hjTk16WXdNekU1TURBd01EQXdXakIxTVVRd1FnWURWUVFERER0QmNIQnNaU0JYYjNKc1pIZHBaR1VnUkdWMlpXeHZjR1Z5SUZKbGJHRjBhVzl1Y3lCRFpYSjBhV1pwWTJGMGFXOXVJRUYxZEdodmNtbDBlVEVMTUFrR0ExVUVDd3dDUnpZeEV6QVJCZ05WQkFvTUNrRndjR3hsSUVsdVl5NHhDekFKQmdOVkJBWVRBbFZUTUhZd0VBWUhLb1pJemowQ0FRWUZLNEVFQUNJRFlnQUVic1FLQzk0UHJsV21aWG5YZ3R4emRWSkw4VDBTR1luZ0RSR3BuZ24zTjZQVDhKTUViN0ZEaTRiQm1QaENuWjMvc3E2UEYvY0djS1hXc0w1dk90ZVJoeUo0NXgzQVNQN2NPQithYW85MGZjcHhTdi9FWkZibmlBYk5nWkdoSWhwSW80SDZNSUgzTUJJR0ExVWRFd0VCL3dRSU1BWUJBZjhDQVFBd0h3WURWUjBqQkJnd0ZvQVV1N0Rlb1ZnemlKcWtpcG5ldnIzcnI5ckxKS3N3UmdZSUt3WUJCUVVIQVFFRU9qQTRNRFlHQ0NzR0FRVUZCekFCaGlwb2RIUndPaTh2YjJOemNDNWhjSEJzWlM1amIyMHZiMk56Y0RBekxXRndjR3hsY205dmRHTmhaek13TndZRFZSMGZCREF3TGpBc29DcWdLSVltYUhSMGNEb3ZMMk55YkM1aGNIQnNaUzVqYjIwdllYQndiR1Z5YjI5MFkyRm5NeTVqY213d0hRWURWUjBPQkJZRUZEOHZsQ05SMDFESm1pZzk3YkI4NWMrbGtHS1pNQTRHQTFVZER3RUIvd1FFQXdJQkJqQVFCZ29xaGtpRzkyTmtCZ0lCQkFJRkFEQUtCZ2dxaGtqT1BRUURBd05vQURCbEFqQkFYaFNxNUl5S29nTUNQdHc0OTBCYUI2NzdDYUVHSlh1ZlFCL0VxWkdkNkNTamlDdE9udU1UYlhWWG14eGN4ZmtDTVFEVFNQeGFyWlh2TnJreFUzVGtVTUkzM3l6dkZWVlJUNHd4V0pDOTk0T3NkY1o0K1JHTnNZRHlSNWdtZHIwbkRHZz0iLCJNSUlDUXpDQ0FjbWdBd0lCQWdJSUxjWDhpTkxGUzVVd0NnWUlLb1pJemowRUF3TXdaekViTUJrR0ExVUVBd3dTUVhCd2JHVWdVbTl2ZENCRFFTQXRJRWN6TVNZd0pBWURWUVFMREIxQmNIQnNaU0JEWlhKMGFXWnBZMkYwYVc5dUlFRjFkR2h2Y21sMGVURVRNQkVHQTFVRUNnd0tRWEJ3YkdVZ1NXNWpMakVMTUFrR0ExVUVCaE1DVlZNd0hoY05NVFF3TkRNd01UZ3hPVEEyV2hjTk16a3dORE13TVRneE9UQTJXakJuTVJzd0dRWURWUVFEREJKQmNIQnNaU0JTYjI5MElFTkJJQzBnUnpNeEpqQWtCZ05WQkFzTUhVRndjR3hsSUVObGNuUnBabWxqWVhScGIyNGdRWFYwYUc5eWFYUjVNUk13RVFZRFZRUUtEQXBCY0hCc1pTQkpibU11TVFzd0NRWURWUVFHRXdKVlV6QjJNQkFHQnlxR1NNNDlBZ0VHQlN1QkJBQWlBMklBQkpqcEx6MUFjcVR0a3lKeWdSTWMzUkNWOGNXalRuSGNGQmJaRHVXbUJTcDNaSHRmVGpqVHV4eEV0WC8xSDdZeVlsM0o2WVJiVHpCUEVWb0EvVmhZREtYMUR5eE5CMGNUZGRxWGw1ZHZNVnp0SzUxN0lEdll1VlRaWHBta09sRUtNYU5DTUVBd0hRWURWUjBPQkJZRUZMdXczcUZZTTRpYXBJcVozcjY5NjYvYXl5U3JNQThHQTFVZEV3RUIvd1FGTUFNQkFmOHdEZ1lEVlIwUEFRSC9CQVFEQWdFR01Bb0dDQ3FHU000OUJBTURBMmdBTUdVQ01RQ0Q2Y0hFRmw0YVhUUVkyZTN2OUd3T0FFWkx1Tit5UmhIRkQvM21lb3locG12T3dnUFVuUFdUeG5TNGF0K3FJeFVDTUcxbWloREsxQTNVVDgyTlF6NjBpbU9sTTI3amJkb1h0MlFmeUZNbStZaGlkRGtMRjF2TFVhZ002QmdENTZLeUtBPT0iXX0", "payload": "eyJ0cmFuc2FjdGlvbklkIjoiMTIzMDAwMDA2NTk5NDI1NyIsIm9yaWdpbmFsVHJhbnNhY3Rpb25JZCI6IjEyMzAwMDAwNjU5OTQyNTciLCJidW5kbGVJZCI6ImNvbS5taWd1LmNsb3VkYXZwIiwicHJvZHVjdElkIjoibWlndS52aXNpb24uTW92aWUuOCIsInB1cmNoYXNlRGF0ZSI6MTc0NDgwNzYzMjAwMCwib3JpZ2luYWxQdXJjaGFzZURhdGUiOjE3NDQ4MDc2MzIwMDAsInF1YW50aXR5IjoxLCJ0eXBlIjoiTm9uLVJlbmV3aW5nIFN1YnNjcmlwdGlvbiIsImRldmljZVZlcmlmaWNhdGlvbiI6IjdIdUtPRUhRdVd2L0hKZjdLdlBzQnJOWUNoc2V3c3k3enpPZ2k1YjE3UW8wVnd2clhhQ3B5TTNmZTN3cFBqRUwiLCJkZXZpY2VWZXJpZmljYXRpb25Ob25jZSI6ImQ3YzgwOWI2LTFjNDMtNDIwOC1iZWVmLWVhZDUwYzY1ZGIwZCIsImFwcEFjY291bnRUb2tlbiI6ImQ2MTNjMTI2LTQxNDItNGJmZi05OTYwLTAwYWUzZjVhNmY4MyIsImluQXBwT3duZXJzaGlwVHlwZSI6IlBVUkNIQVNFRCIsInNpZ25lZERhdGUiOjE3NDU4MjM1MTU5OTUsImVudmlyb25tZW50IjoiUHJvZHVjdGlvbiIsInRyYW5zYWN0aW9uUmVhc29uIjoiUFVSQ0hBU0UiLCJzdG9yZWZyb250IjoiQ0hOIiwic3RvcmVmcm9udElkIjoiMTQzNDY1IiwicHJpY2UiOjgwMDAsImN1cnJlbmN5IjoiQ05ZIiwiYXBwVHJhbnNhY3Rpb25JZCI6IjcwNDQxMzM2NTEzNjUyNzAzMyJ9", "signature": "SXieZGabBt6xHoSaBsZ1k4AexqkNYzwZel0BEhGqc3mxrd4kzOR5wERRATXySqbqfT3WJzkDAsr9jmCdoz_7-g"], "status": "normal", "transactionId": "1230000065994257"]","Band_Phone_Num":"18653588566","Platform":"124","Oper_Time":"1745823519","verification_time":"1745823519115"},"ISP":"移动","OETM":"1745823519116","CLIENTID":"","CPURATE":"0.257","AMBERUDID":"1f72113ecc704ce4a4cc135e8af71ee6","ANAME":"","MEMRATE":"0.02346919","CITY":"北京","PROMOTION":"\\","CLIENTIP":"192.168.31.74","CLIENTIPV6":"fe80::4e3:40a8:51c3:dbf5","DB":"Apple","APN":"com.migu.cloudavp","ETM":"2025-04-28 14:58:39 116"} 请帮我查一下 是这个订单没关闭成功吗？为什么出现购买新的产品 返回的永远是这个支付凭证。