We are seeing trial conversions for our auto-renewable monthly subscription wingman_monthly (App ID 6758346525) land in a persistent "Pending" state in users' iOS Purchase History after the 3-day free trial ends, with no debit reaching the user's payment method. App Store Server Notifications V2 indicate the renewals succeeded — each affected transaction is delivered as DID_RENEW (subType BILLING_RECOVERY not present) with is_trial_conversion: true, period_type: NORMAL, a new expires_date set 31 days in the future, AUD 19.99 attributed, no expirationIntent, no is_in_billing_retry_period, and no cancellation_reason. So Apple's billing layer reports the renewals as successful, but settlement does not appear to complete. The same trial-to-paid flow on our yearly product wingman_yearly in the same subscription group converts and debits cleanly. The pattern is specific to wingman_monthly.

We as a PSP register merchantIdentifiers when registering merchants to ApplePay. We then use these identifiers in a multiTokenContexts during ApplePay session creation / validation / payment. "multiTokenContexts": [ { "merchantIdentifier": "ABC-MID-1", "externalIdentifier": "MAIN_PURCHASE", "merchantName": "Main", "amount": "2.50" }, { "merchantIdentifier": "ABC-MID-1", "externalIdentifier": "CONVENIENCE_FEE", "merchantName": "Fee Processing", "merchantDomain": "m2.example.com", "amount": "2.50" } ] in response we get "authenticationResponses": [ { "merchantIdentifier": "0aff534d6d46fd653f60e6161c53101ee8d9cbc20b1bc40533c929d0a6aae6bc", "authenticationData": "AAAIAKnglVRsCyOvcgI*=", "transactionAmount": "250" }, { "merchantIdentifier": "bfc9a63b4ebab8cde90234731cb18a544c306b0af747d93d773fedb603f0945e", "authenticationData": "AAAIANBEqODkDcrDTgI*=", "transactionAmount": "250" } ] We need to know how to match the entries in the request array to the response array. Is the order guarantied? We did not find any documentation on how the response hash for the identifier is computed.

We are an Apple Pay consumer and observed elevated response times and intermittent timeouts affecting the create‑session API (apple-pay-gateway.apple.com/paymentservices/paymentSession) between approximately 8:01 PM and 8:35 PM PST today. We are reaching out to understand whether there were any service disruptions during this timeframe, as we do not see corresponding updates on the system status pages. We would like to confirm whether this behavior was related to a broader Apple Pay issue or specific to our integration.

APP被下架后是否会影响之前已经订阅了自动续费产品用户的定期扣费

In testing in-app push provisioning with a production TestFlight build built with Xcode Cloud (Xcode 26.4.1) the flow is failing when attempting to add cards. I start the flow by choosing the add to wallet button from within the app. I get to the stage “Add Card” and choosing continue fails with “Could Not Add Card” and a button “Set Up Later” Analysing the sysdiagnose logs reveals that the eligibility stage is failing with a HTTP 500 error. [9ix8SPBHSfWEcxLjj+j5bA] ProvisioningOperationComposer: Step 'eligibility' failed with error <PKProvisioningError: severity: 'terminal'; internalDebugDescriptions: '( "eligibility request failure", "Received HTTP 500" )'; underlyingError: 'Error Domain=PKPaymentWebServiceErrorDomain Code=0 "Unexpected error." UserInfo={PKErrorHTTPResponseStatusCodeKey=500, NSLocalizedDescription=Unexpected error.}'; userInfo: '{ PKErrorHTTPResponseStatusCodeKey = 500; }'; > FB22761556

We are currently experiencing a critical issue with our Apple Developer account related to production certificates for live customers using Apple Pay. Each customer integration requires a minimum of two certificates. At present, our account has reached 20 certificates, and we are facing limitations that impact our ability to onboard new customers. Recently, deletion of certain certificates caused a major outage, resulting in service disruption for live customers. This outage has had significant financial implications,  This may be held liable for the revenue lost. We urgently request clarification on the following: What are the official license limit restrictions for production certificates on Apple Developer accounts? Is there a way to extend or increase the certificate limit to support multiple live customer integrations? What best practices should we follow to avoid outages when managing certificates for Apple Pay? Given the severity of this issue, we kindly ask for immediate guidance and support to prevent further disruptions.

I'm on a 16" MacBook Pro M4 Max w/ 36 GB RAM Apple Pay had been working with the beta releases with not issues, but after the macOS 26.6 beta update, Apple Pay was deactivated and is showing an error message: Apple Pay has been disabled because the security settings of this Mac were modified I found suggested fixes on the non-beta Apple forums (since this issue has apparently struck past release-versions of macOS), but none of them have worked. Does anyone here have any notions? Thanks!

Hi guys, we are trying to implement In-App Provisioning for our banking application. After some iterations of determining responsibilities for providing data, we managed to gather all info required, but the process is failing. When user tries to provision a card, the Provisioning UI flow stops after selecting a device to provision the card on. It presents an alert: "Could Not Add Card", and offers just "Set Up Later". Further investigation (Console.app) shows that PassbookUIService has an error saying: [qv4t2XcQQ1G+AWP9HINjFQ] ProvisioningOperationComposer: Step 'eligibility' failed with error <PKProvisioningError: severity: 'terminal'; internalDebugDescriptions: '( "eligibility request failure", "Received HTTP 500" )'; underlyingError: 'Error Domain=PKPaymentWebServiceErrorDomain Code=0 "Unexpected error." UserInfo={PKErrorHTTPResponseStatusCodeKey=500, NSLocalizedDescription=Unexpected error.}'; userInfo: '{ PKErrorHTTPResponseStatusCodeKey = 500; }'; > Also, when filtering Console output by my SEID, I can see that the request is failing with HTTP 500 code: default 15:09:22.599860+0200 PassbookUIService Response: https://pr-pod10-smp-device.apple.com:443/broker/v4/devices/???/cards 500 Time profile: 0.274013 seconds { Server = "Apple" Content-Type = "text/html" X-Content-Type-Options = "nosniff" Strict-Transport-Security = "max-age=31536000; includeSubdomains" Date = "Wed, 03 Jun 2026 13:09:22 GMT" X-Frame-Options = "SAMEORIGIN" X-XSS-Protection = "1; mode=block" Cross-Origin-Opener-Policy = "same-origin" Content-Length = "170" Connection = "close" } <html> <head><title>500 Internal Server Error</title></head> <body> <center><h1>500 Internal Server Error</h1></center> <hr><center>Apple</center> </body> </html> I've submitted a Feedback assistant with the guidelines found here. Feedback ID: FB22924636 (In-App Provisioning failing) Would appreciate if anyone has some pointers as to what to focus on to resolve this issue. Thank you!

Hello, We are implementing in-app provisioning in our banking app but are having trouble getting to the Terms & Conditions screen. User taps on “Add to Apple Wallet” > PKAddPaymentPassViewController > Next > the flow fails quickly with "Could Not Add Card -> Set Up Later" alert. The only notable thing in the logs, as far as I can see is the https://nc-pod12-smp-device.apple.com:443/broker/v4/devices/{SEID}/cards fails with: <html> <head><title>500 Internal Server Error</title></head> <body> <center><h1>500 Internal Server Error</h1></center> <hr><center>Apple</center> </body> </html> and maybe ProvisioningOperationComposer: Step 'eligibility' failed with error <PKProvisioningError: severity: 'terminal'; internalDebugDescriptions: '( "eligibility request failure", "Received HTTP 500" )'; underlyingError: 'Error Domain=PKPaymentWebServiceErrorDomain Code=0 "Unexpected error." UserInfo={PKErrorHTTPResponseStatusCodeKey=500, NSLocalizedDescription=Unexpected error.}'; userInfo: '{ PKErrorHTTPResponseStatusCodeKey = 500; }'; > Feedback Assistant ID: FB22932141 (Error during In-App Provisioning)

Subject: Proposal to Integrate Riyadh Metro Card (Darb) & Package Details Dear Support Team / Management, I would like to propose an update to enhance the user experience for commuters in Riyadh. I suggest integrating the Riyadh Metro Card (Darb Card) directly into the platform/wallet in coordination with the Royal Commission for Riyadh City. To provide users with full clarity, it would be highly beneficial to display the official ticket subscription durations and pricing directly, which are structured as follows: • 2-Hour Pass: 4 SAR (Standard Class) / 10 SAR (First Class) • 3-Day Pass: 20 SAR (Standard Class) / 50 SAR (First Class) • Weekly Pass (7 Days): 40 SAR (Standard Class) / 100 SAR (First Class) • Monthly Pass (30 Days): 140 SAR (Standard Class) / 350 SAR (First Class) • Please note that Students and Persons with Disabilities are eligible for a 50% discount on the Standard Class (Individuals) ONLY. • Children under 6 years old travel for free. Integrating this feature and its detailed info will significantly streamline public transit usage and save time for both residents and visitors. Thank you for your continuous efforts and for considering this feedback. Best regards, SUBMITTED BY: IBRAHIM BIN HUSAYNAN