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!

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

Hi, we are trying to verify our domain and we uploaded the file to our domain {DOMAIN}/.well-known/apple-developer-merchantid-domain-association.txt and we can access it. But when we want verify the domain in your platform we can't do it and you see the message "Domain verification failed". How can we verified or if we need change something in our side to verify it? thanks!

Why did my sandbox test fail due to not being able to obtain the product list?

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.

Hello -- We're preparing to roll out Apple Pay on website in the next week but encountered some issues during testing. While we successfully processed transactions using a VISA card, we ran into errors when testing with other card brands. Has anyone come across this issue before?

We’ve an implementation of apple pay with asia pay as gateway . We want to access that from external iframe . although we’ve been able to load the apple pay widget not able to validate merchant and tokenize in iframe. Please let us know if apple pay with asia pay is available to be used within iframe.

We are looking for sample payload for merchant registration API. We have tried to test the api and getting an error. Request: curl --location 'https://apple-pay-gateway-cert.apple.com/paymentservices/registerMerchant' --header 'Content-Type: application/json' --data '{ "domainNames": "https://checkout.dev.sandbox-netvalve.com", "encryptTo": "platformintegrator.com.netvalve.uat", "partnerInternalMerchantIdentifier": "merchant.test.netvalve", "partnerMerchantName": "Test" }' Response: { "statusMessage": "Payment Services Exception invalid or Malformed Json Received", "statusCode": "400" }

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.

Hi there, is there a way, or a list of test cards, to simulate error on payment in an Apple Pay sandbox environment ? I tried different cards mentioned here but every try was successful : https://developer.apple.com/apple-pay/sandbox-testing/

When apple pay on the web does a onshippingcontactselected it appears to truncate the zip code. If I enter: 11111 or 11111-1111 I always get 11111. Is there any way to get the plus 4?

Hi, We are trying to make payment from ecomm merchant. The last request during process is { "sessionData": { "epochTimestamp": "1741082241", "expiresAt": "1741092241", "merchantSessionIdentifier": "SSH88312C485D_7E0DD10173", "nonce": "3f6dc197", "merchantIdentifier": "5F9BC6BAF8", "domainName": "libertybank.ge", "displayName": "Apple Pay Purchase", "signature": "3080060000", "operationalAnalyticsIdentifier": "Apple Pay Purchase:5F9BC6BAF8", "retries": 0, "pspId": "5F9BC6BAF8" } } which is successfully validated applePaySession.completeMerchantValidation(data.sessionData) After this, the "oncancel" handler is triggered in applePay. Please help us to understand what is wrong. Please note the domain where the applepay button is located is at txpg.libertypay.ge Which is successfully verified.

Hello Apple Devs, We’re currently trying to integrate Apple Pay on the web using Apple Pay JS. We've followed the official documentation closely, but we're running into a blocker during the merchantSession validation phase. We successfully retrieved a merchantSession, which looks like this: json { "displayName": "Our Name", "domainName": "https://pay.ourdomain.co", "epochTimestamp": , "expiresAt": ****************, "merchantIdentifier": "", "merchantSessionIdentifier": ", "nonce": "", "operationalAnalyticsIdentifier": our name "t:", "pspId": "", "retries": 0, "signature": "*****************..." } Issue: Shortly after initiating the session, we receive a cancel event with the following info: ApplePayCancelEvent { type: "cancel", sessionError: { code: "unknown", info: {} } } We're unsure what causes the cancellation. There are no clear error messages or hints in the logs to identify what went wrong. What We’ve Checked: The merchantSession is returned successfully from our backend. The domainName matches our frontend domain (https://pay.durdomain.co). The session hasn’t expired when tested. We're using Apple Pay JS APIs as described in the documentation. Help Needed: What can trigger an ApplePayCancelEvent with an "unknown" error code? Any insight or guidance would be deeply appreciated. Thanks in advance!

Hello, I'm trying to make changes to my website's apple pay flow and an unable to verify if the flow works because I get the following error in the console when trying to pay: TypeError: undefined is not an object (evaluating 'applePaySession.completeMerchantValidation') By following this error message, I try to setup an ngrok proxy to verify my local development domain and that fails as well even though as you can see, the file does actually exist. Can anyone help with A) giving me a different way to develop locally aka having a "successful" apple pay payment so I can verify my website's flow after payment or B) help me figure out why the domain verification is failing. Thanks!

I have a question regarding the file apple-developer-merchantid-domain-association.txt. I understand that this file is used during API access for Apple Pay Web payments. However, is it necessary for our company to access this file during the payment process? Also, this domain validation file is expected to be placed in the publicly accessible “.well-known” folder on our web server. Is it acceptable for this file to remain readable by third parties on the Internet, including Apple’s servers, without posing any security risks? Since this file is generated during domain registration on the Apple Developer site and is unique to our domain, we believe there should be no security concerns even if accessed by third parties. However, are there any specific security requirements for this domain validation file? Please note that the domain validation has already been successfully completed. We appreciate your time and look forward to your guidance. Best regards,

We created apps for many credit unions in Canada. Some of those apps has the feature to directly add users' debit cards to Apple Wallet (which is called by Apple as "in-app provisioning"). The feature has been working fine for at least 6 years for many credit unions. Recently, after updating one of those existing apps, we found out that the in-app provisioning is no longer working. Found it very strange, as we didn't touch the code base related to this feature for a very long time. One thing we found out is that the option to add in-app provisioning entitlement is missing during generating "provisioning profile" for the app. Is this a misconfiguration by App? Or do we need to request for additional entitlement migration as mentioned in the page: https://developer.apple.com/help/account/reference/provisioning-with-managed-capabilities ? Apple, please help, it's rather urgent.

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?

We request your support in enabling the extended entitlement feature for our team when creating provisioning profiles. This is because we need to include the ApplePay In-App Provisioning Development extended entitlement in our Bancoagricola app. Currently, when creating new provisioning profiles, the screen to configure Additional Entitlements is not displayed for our team. However, we have verified with our provider HST (https://hst.com.br/) that this screen does appear in their Apple account. Thank you very much for your support.

Hello Dear Network, We are developing a banking application and are implementing Apple Wallet In-App Provisioning with Wallet UI and Non-UI extensions. Our App Store submission fails with the error: "Missing entitlement com.apple.developer.payment-pass-provisioning" for both Wallet UI and Non-UI extensions. In the Apple Developer portal, we do not see the "Apple Pay" or "In-App Provisioning" capabilities available for our App ID or extension App IDs. We would like to request enablement of: Apple Pay Payment Pass Provisioning In-App Provisioning for our Apple Developer Team and related App IDs. Please let us know what we need to do for can upload build with that Entitlements, what can be problem? Thank you.

We’re attempting to call the Apple Pay Web Merchant Registration API using our Platform Integrator flow and consistently receive 401 Unauthorized, despite successful TLS/mTLS. Details: Endpoint: https://apple-pay-gateway-cert.apple.com/paymentservices/registerMerchant (POST) Payload: { "domainNames": ["breakerfy.com"], "encryptTo": "platformintegrator.ai.packman", "partnerInternalMerchantIdentifier": "merchant.ai.packman.1", "partnerMerchantName": "breakerfy", "merchantUrl": "https://breakerfy.com" } Domain association: URL: https://breakerfy.com/.well-known/apple-developer-merchantid-domain-association What we tried: We created a Payment Platform Integrator ID (platformintegrator.ai.packman) We created a CertificateSigningRequest We used the certificate signing request to create an Apple Pay Platform Integrator Identity Certificate and downloaded the signed certificate. We exported the Private Key from keychain access in PKCS 12 format We converted both the private key and the signed certificate to PEM format We created a merchant id We used the converted keys to send requests to the API We received { "statusMessage": "Payment Services Exception Unauthorized", "statusCode": "401" } we also tried curl with the original p12 file and also had no luck. What could be the issue ?