We are working with two types of wallet passes. Provisioning works successfully for one pass type via wallet extensions, but the same process is not functioning for the other. For the second pass type, we are able to generate the required data for pull provisioning and send it to Apple. Additionally, in-app push provisioning for this pass type completes without issue. We would appreciate guidance on how to further debug and resolve this provisioning problem.

Hi everyone, I’m encountering a strange issue with Apple Pay in our React Native iOS app using the Stripe React Native SDK. Summary of the Problem: • Apple Pay shows up as an available payment method inside the Stripe Payment Sheet. • When I tap Apple Pay, the Apple Pay sheet opens normally. • After confirming payment, the Apple Pay sheet immediately closes, and nothing happens. • No payment is created and no request reaches Stripe’s servers. On Stripe Dashboard the PaymentIntent remains incomplete, with no errors, which means the failure happens before Stripe receives anything. Environment • React Native with @stripe/stripe-react-native • StripeProvider configured with: <StripeProvider publishableKey={...} merchantIdentifier="merchant.com.app.venga" stripeAccountId={...} urlScheme="venga" > Apple Pay works on our web checkout with the same merchant identifier. We have verified all of the required Apple Pay setup: • Merchant ID exists, active, and matches exactly. • Merchant ID added to the iOS app target in Xcode → Signing & Capabilities. • Apple Pay capability enabled. • Merchant domain is verified (web checkout works). • Apple Pay certificate and merchant certificate are valid. • Stripe publishable key and merchantIdentifier are correct. • Stripe SDK correctly initialized. • Device region supports Apple Pay. Extra Observations: • The PaymentIntent’s allowed_payment_methods includes "card" and Apple Pay does appear in the payment sheet. • But after tapping Pay → the Apple Pay sheet closes instantly. • There is no callback with an error, and nothing appears in Stripe logs. • We are testing in Sweden. As far as I know Apple Pay should work fine here. Questions: What could cause the Apple Pay sheet to dismiss instantly after attempting a payment? Could this be caused by a merchant ID mismatch—even if Apple Pay appears in the sheet? Is there any Apple-device-level requirement (region, wallet config, card type) that could cause this silent failure? Is there a way to get more detailed logs when Apple Pay closes before Stripe receives anything? Any help or suggestions would be greatly appreciated. Thanks!

We have been using ApplePay on the web for years, but we are running into a problem since today in sandbox where domainName is missing from the create payment sessions request. We haven't changed anything related to this request any time recently. Static payment sessions url being hit in sandbox: https://apple-pay-gateway-cert.apple.com/paymentservices/paymentSession request format: "merchantIdentifier": "merchant.com.identifier", "displayName": "Test Store", "initiative": "web", "initiativeContext": "test.example.com", "domainName": "test.example.com" response format: { "epochTimestamp": 1763533367972, "expiresAt": 1763536967972, "merchantSessionIdentifier": "<merchantSessionIdentifier>", "nonce": "<nonce>", "merchantIdentifier": "<merchantIdentifier>", "displayName": "Test Store", "signature": "<signature>", "initiative": "web", "initiativeContext": "test.example.com", "signedFields": [ "merchantIdentifier", "merchantSessionIdentifier", "initiative", "initiativeContext", "displayName", "nonce" ], "operationalAnalyticsIdentifier": "Test Store:<identifier>", "retries": 0, "pspId": "<pspId>" } Production create session request to https://apple-pay-gateway.apple.com/paymentservices/paymentSession is behaving as expected, sending the following fields as response: epochTimestamp, expiresAt, merchantSessionIdentifier, nonce, merchantIdentifier, domainName, displayName, signature, operationalAnalyticsIdentifier, retries, pspId Claude seems to suggest this is a response when Messages for Business is enabled, but this ApplePay Payment Processing merchant is only configured for Apple Pay on the Web. Any ideas or pointers to check for? We are worried this will spill over in production as well, which will break our ApplePay integration. Thanks in advance!

During checkout at apple.com using a non-supported Apple Pay on the Web browser, apple.com presents a QR like code offering to "Scan Code with iPhone" to pay. The payment continues using Apple Pay on the iPhone after scan. We already offer Apple Pay and Apple Pay on the Web. Is this QR code option available for us for non-supported browsers? Could you point me to the docs to add it? Thank you.

I developed a web app using .net c#. The app runs a workflow which included Apple payment. App can work on any browser of any device (even non-IOS). When the app is browsed using PC windows Chrome browser, the payment sheet will show with QR code to scan using iPhone. If I cancelled the pop-up by clicking on X without scanning the code, and then returned to idle screen and performed another payment, I will reach paymentRequest.Show() but nothing will show and no errors are logged in console. Note that: I use Payment Request API The issue appear on the second payment. The issue will be solved once I refresh the page. My app supports both single and separate pages mode and issue appear on both. I used to see an error "Uncaught NotSupportedError: Failed to execute 'define' on 'CustomElementRegistry': the name apple spinner has already been used with this registry. So I thought the issue might be in loading the apple SDK script multiple times, and solved the issue to be loaded only once. The error disappeared but the issue persist without errors.

My client has provided me with admin access to the Apple Developer console. However, when I log in, I am prompted to enroll in the Apple Developer Program. Should I proceed with the enrollment myself, or does the client need to complete the enrollment from their own account?

Dear Apple Developer Support, I would like to request a technical escalation to the engineering team regarding an ongoing issue with Apple Pay domain verification. Error returned by Apple Even though Apple’s request to our domain returns HTTP 200, the verification still fails with: resultCode: 13014 resultString: "Domain verification failed. Review your TLS Certificate configuration to confirm that the certificate is accessible and a supported TLS Cipher Suite is used." requestUrl: https://developer.apple.com/services-account/QH65B2/account/ios/identifiers/verifyDomain TLS Certificate Validation We performed a full TLS analysis: Certificate issued by Sectigo Public Server Authentication CA DV E36 (public trusted CA) Full and correct certificate chain No handshake errors Configuration fully valid SSL Labs rating: A From our side, the TLS configuration is confirmed to be correct. Accessibility of the .well-known file The file is publicly and accessible It returns 200 OK and the content is exactly identical to the file downloaded from the Apple Developer Portal, without any modification. Our network team confirmed that Apple’s verification request also receives HTTP 200 when pressing “Verify” in the Apple Developer Console. Network-side findings We monitored Apple’s request in real time. Findings: TLS handshake succeeds No cipher mismatch File delivered correctly Status: 200 OK No redirect or transformation applied Despite this, Apple still returns error 13014. Request for engineering review We kindly request that an Apple engineer verify the following: The actual TLS handshake performed by Apple's verification service (cipher suite, protocol negotiation, SNI, trust chain). Whether the Sectigo issuing CA is fully trusted and supported by your domain-verification backend. If there is an internal reason behind error 13014—since the external message does not provide actionable details. Whether the response is rejected for reasons other than TLS, given that the file is accessible and the request returns 200. The exact condition that leads Apple to report “TLS Certificate configuration is incorrect” in this case. This issue is blocking an urgent deployment and must be resolved as soon as possible. Existing case reference Case ID: 102760005987 We are fully available to provide: full response headers packet captures (PCAP) SSL/TLS diagnostics file integrity checks server configuration details or join a technical call (Teams / WebEx) Thank you in advance for the escalation. Andrea

Cybersource production support has clarified issue as below "On the BAD Case, it seems that the Apple Payload did not contain the "onlinePaymentCryptogram" object within the JSON. The Cryptogram is critical and mandatory. Since the merchant cannot really control this, and since CYBS is just decrypting the payload and uses it, we cannot comment as to why it was missing. The merchant would need to reach out to Apple and/or decrypt the payment themselves locally to check if and why this data was not present, for troubleshooting purposes."

Cybersource production support has clarified issue as below "On the BAD Case, it seems that the Apple Payload did not contain the "onlinePaymentCryptogram" object within the JSON. The Cryptogram is critical and mandatory. Since the merchant cannot really control this, and since CYBS is just decrypting the payload and uses it, we cannot comment as to why it was missing. The merchant would need to reach out to Apple and/or decrypt the payment themselves locally to check if and why this data was not present, for troubleshooting purposes."

Hello, we develop a banking app and have successfully provisioned our cards (they are in the Wallet). But the method passes() of PassKit library always returns empty list. What may be the reason of this? Thanks.

I'm seeking clarification on how Requirement 4.1 ("Card Issuers with a Mobile App must support In-App provisioning") applies when the card issuer uses a third-party mobile banking platform rather than a self-developed app. Our situation: We are a small credit union (the card issuer) Our mobile banking app is provided by a third-party digital banking vendor (white-label, but branded with our name) Card processing is handled by a separate vendor The ambiguity: The Apple Pay Specifications define "Card Issuer Mobile App" as: "The Card Issuer-branded, iOS software application made available on a Device that is used by such Card Issuer's customers to manage, administer, or use Cards." Our mobile banking app meets this definition—it's branded with our name and used by our members to manage their accounts and cards. However, we don't develop or directly control the app; our digital banking vendor does. The webinar FAQ stated: "Do we have to implement in-app provisioning? Yes, if you have an app." Our digital banking vendor interprets this as not applying to them because they are "not the issuer." They've stated: "Apple's requirements are at the card-processor level... our credit unions and, by extension, we are not required to support Apple Pay's in-app provisioning." Our card processor has indicated they will support in-app provisioning integrations but notes "this would be digital provisioning and we would need the digital banking vendor to work with us to enable." Specific questions: When a card issuer uses a third-party mobile banking app (branded for the issuer but developed/maintained by a vendor), does Requirement 4.1 apply? If yes, who bears compliance responsibility—the issuer, the mobile app vendor, or both? If the mobile app vendor does not implement in-app provisioning by January 15, 2026, what is the issuer's exposure? Does the issuer face suspension from the Program due to vendor non-compliance? Is there an alternative compliance path under Requirement 4.8 (Web Provisioning) for issuers whose mobile app vendors cannot deliver in-app provisioning by the deadline? This scenario likely affects hundreds of small financial institutions using shared digital banking platforms. Clarity on vendor vs. issuer responsibility would help the entire ecosystem prepare appropriately. Thank you.

Our company sells insurance and we'd like to offer annual renewals via Apple Pay on the Web. Most of the docs seem to point towards using recurringpaymentrequest but this method required an amount value which would only be calculated at renewal time. It appears that Shopify is doing something akin to what we want where they do auto payments so my question is can we do annual payments with unknown renewal prices with Apple Pay for Web ? What we cannot do is show the renewal price like this as it being insurance is almost certain to change. This is our current code which works but won't get past the regulator. const applePayPaymentRequestAnnual = { countryCode: 'GB', currencyCode: 'GBP', supportedNetworks: ['visa', 'masterCard'], merchantCapabilities: ['supports3DS'], requiredBillingContactFields: ['postalAddress', 'email'], requiredShippingContactFields: ['phone'], recurringPaymentRequest: { paymentDescription: 'Annual Insurance Renewal', regularBilling: { label: 'Annual Renewal Premium', amount: price, paymentTiming: "recurring", recurringPaymentIntervalUnit: "year", recurringPaymentStartDate: year + "-" + month + "-" + day + "T00:00:00.000Z", type: 'final' }, managementURL: window.location.protocol + '//' + window.location.host + '/manage-policy', tokenNotificationURL: window.location.protocol + '//' + window.location.host + '/apple-pay-notifications' }, lineItems: [{ label: alabel, amount: price, }], total: { label: alabel, amount: price, type: "final" }, }

Hello, I'm using PassKit with to perform Apple Pay payment in a financial application. Our approach are: On iOS application, define PKMerchantCapability threeDSecure and credit, perform apple pay experience and get the encrypted response. On PCI service, receive the encrypted data Payment token, decrypt this data, and use to perform the payment. The problem is, in MasterCard transaction the eciIndicator is missing. I want to know if has some rule or problem about it.

Hello, I’m experiencing a strange issue with a newly created Subscription Group in my iOS app. For all my existing subscription groups, everything works perfectly — initial purchase, renewals, cancellations, all notifications arrive normally. But for this one newly created group, the first purchase never triggers any server notification from App Store Server Notifications (ASSN). ⸻ 📘 Problem Summary • I created a new Subscription Group in App Store Connect. • The products are all Approved and Published for over a week. • Users can successfully purchase the subscription in production. • The purchase is shown as Purchased in the App Store purchase UI. • The receipt can be fetched locally on device. • But my server receives no notifications, including: • DID_RENEW • DID_CHANGE_RENEWAL_STATUS • SUBSCRIBED • ONE_TIME_CHARGE • CONSUMPTION_REQUEST • etc. The old subscription groups still send notifications normally, so the notification URL and server infrastructure are correct.

For Apple Pay Testing purposes, we're trying out cards from https://developer.apple.com/apple-pay/sandbox-testing/ Visa, AMEX, Discover cards can be added to the wallet. But all 5 of the listed options for Mastercard cannot be added to the wallet with the error "Card Device Limit". How can we resolve this?

Scenario User is actively subscribed to Monthly Package From the Device App (Manage Subscriptions), user upgrades to Yearly Package Purchase completes successfully on device Issue Do not receive any server notification for this action Month Package Purchase Date: 2025-11-11 19:06:45.537 +0600 Month to Yearly Upgradation Date: 2025-12-11 paymentReferenceId: 510002270528780

Bank Accounts details are outdated and status is stack on processing with error: "Your banking updates are processing, and you should see the changes in 24 hours. You won't be able to make any additional updates until then." This is now stack for a few years since we activated a previous Apple developer account. we must change banking details as it holds up development of an app with in-app purchases. Finance department has been contacted and they do not answer What shall we do? senior support staff keep referring to finance department and is not helping

During Apple Pay in-app provisioning (EV_ECC_v2), our iOS app successfully obtains the issuer provisioning certificates and generates cryptographic material. The flow fails when Apple posts the card blob to Apple’s broker (card creation step), returning HTTP 500 from .../broker/v4/devices/{SEID}/cards. Steps: Call issuerProvisioningCertificates?encryptionVersion=EV_ECC_v2 → 200 OK; returns ECC leaf + Apple Root CA chain; nonce=2a831be4. 2. Build {encryptedCardData, activationData, ephemeralPublicKey} 3. POST /broker/v4/devices/{SEID}/cards Expected: 200 OK on /broker/v4/devices/{SEID}/cards, or 5xx with a descriptive error if payload/cryptography is invalid. Observed: 500 Internal Server Error from Apple broker on /cards (labeled “eligibility” in PassKit logs), causing a terminal failure in Wallet UI.

We are a regulated financial institution and Apple Pay issuer seeking clarification on the in-app push provisioning requirement and the January 15, 2026 timeline. Like many community financial institutions: Our mobile banking app is issuer-branded but provided by a third-party vendor Apple Pay enablement and tokenization are handled by a separate card processor While we support Apple’s goals and understand the issuer is ultimately responsible, delivery of in-app provisioning is dependent on third-party vendor roadmaps and cross-vendor integrations that are outside our direct control. Despite active, good-faith efforts with both vendors, current platform constraints make the January 15, 2026 deadline challenging. We would appreciate clarification on: How Apple evaluates compliance when an issuer’s mobile app is built and maintained by a third party Whether any transitional flexibility or phased enforcement is expected for issuers showing documented progress Whether approved web-based provisioning may be acceptable as an interim option How issuers should document due diligence when vendor dependencies delay implementation Additional guidance would help many credit unions and community banks plan appropriately and remain compliant. Thank you for your guidance.

Two subscriptions, Plus and Max, are under the same subscription group, with Max having a higher tier than Plus. Promotional Offers for Max are configured in Apple Store Connect. When a user subscribes to Plus and then upgrades to Max using Promotional Offers, they are prompted with "Upgrade upon expiration" (Figure 1); if they don't use Promotional Offers, they are prompted to "Upgrade immediately" (Figure 2). Question 1: What is the situation with the "upgrade upon expiration" message in Figure 1? Is upgrading using Promotional Offers special? I couldn't find any relevant explanation in Apple's technical documentation. Question 2: Figure 1 shows an "upgrade upon expiration," but after subscribing, the webhook still shows the subscription start time as the current time, meaning the upgrade hasn't started immediately. Is the message incorrect?