We test Apple Pay in the sandbox on supervised iPhones in a device lab (Apple Configurator supervision, no MDM enrollment, no SIM, iOS 26.x). Since late September two of the test cards from the Sandbox Testing page no longer add to Wallet. Discover test cards still add fine on the same devices and accounts. Filed as FB24994276 (Visa) and FB24994258 (Mastercard), with device logs and timestamps. Visa 4622 9431 2318 9285 (FB24994276), only on our lab devices: eligibility → 412 → TSM sync → 200, "received eligibility status: 1" terms shown and accepted provision → HTTP 403 → PKProvisioningErrorDomain Code=3 → "Invalid Card" Same result on two different lab iPhones, including one signed in to a brand-new sandbox account. The same new account and the same card add successfully on an unsupervised iPhone on a home network (iOS 18.2.1). Neither side sends location data. Mastercard 5204 2452 5046 0049 (FB24994258), on every device we tried, lab and home, iOS 18.2.1 and 26.x: eligibility → 412 → TSM sync → retry → HTTP 500 → PKProvisioningErrorDomain Code=5 Questions: What does the 403 at the provisioning step mean for the Visa card? Does supervision, the iOS version, our network egress, or the fact that our devices re-provision cards every test session play a role? Is the Mastercard sandbox environment currently broken, or is there a Mastercard test card that works? Happy to capture a sysdiagnose with the Wallet logging profile if that helps.

When I use my iPhone to scan the apple pay QR code in chrome, the url is https://applepaydemo.apple.com/apple-pay-js-api, I keep geting the "Service Unavailable" error. Wonder know if you guys meet this error as well? Btw, the QR code feature needs IOS 18.

We're an ecommerce/payments platform where tenants embed our Apple Pay checkout into their existing website via an iframe. Our checkout is served entirely from our own domain (b.com) - none of our code runs in the tenant's top-level context. We manage Merchant Identity certificate and Payment Processing certificate, shared across tenants, and tenants are onboarded by registering their domain against our Merchant Id. Our specific scenario: a tenant's domain (a.com) already has its own, independent Apple Pay integration - their own Merchant ID, their own Merchant Identity/Payment Processing certs, and their own apple-developer-merchantid-domain-association file already hosted at a.com/.well-known/, used for a different part of their business with a different PSP. We now want to embed our checkout (iframe source = b.com) into a different part of a.com's site, registered under our own Merchant ID, without disrupting a.com's existing integration. We understand that per Apple's iframe guidance, the parent/top-level page domain must be registered and passed as initiativeContext during merchant validation - so b.com (our iframe source) being registered isn't sufficient on its own; a.com (the top-level document) also needs to be registered, under our merchant bucket, concurrently with its own existing registration under its separate Merchant ID. Given that: Is it supported for the same domain (a.com) to be registered concurrently under two unrelated Payment Merchant IDs - ours for the embedded flow, and the tenant's own for their existing flow? Our analysis says no, but we'd appreciate a definitive answer. If so, how is domain verification expected to work in that case? The well-known path (a.com/.well-known/apple-developer-merchantid-domain-association) can only serve one file - how should a.com host verification for two independent registrations at the same domain and path? Is there a documented or recommended pattern for this "platform iframe on domain X, where domain X already has its own separate, unrelated Apple Pay merchant registration" case, distinct from the general "PSP registers a merchant's domain" flow? We've read the Web Merchant Registration API docs and the "Apple Pay Web and Ecommerce site hosting Multiple Merchants on a Single Domain Site" thread, but those address a single integrator managing many merchants, not two independent integrators needing to register the same top-level domain simultaneously.

After updating my iPhone 15 to iOS 27, the AssistiveTouch button no longer works to confirm Apple Pay payments or other actions that require confirmation through AssistiveTouch. I normally use the following sequence: Long-press the AssistiveTouch button to open Apple Pay. After Apple Pay opens, use the same long-press gesture on AssistiveTouch to confirm the payment. Before updating to iOS 27, this worked normally. When navigating through the AssistiveTouch menu step by step, the behavior seems to indicate that the Apple Pay action is supposed to be followed by the AssistiveTouch confirmation action. However, on my device, after Apple Pay opens, the AssistiveTouch button no longer performs the confirmation action. It seems as if the long-press gesture is no longer being recognized for the confirmation step. This is particularly noticeable because the Apple Pay interface opens correctly, but there is no response when I perform the same long-press gesture that previously confirmed the payment. Has anyone else experienced this behavior on iOS 27? Could this be a bug or an intentional change in how AssistiveTouch handles Apple Pay confirmation? Device: iPhone 15 OS: iOS 27

We are attempting to integrate the Apple Pay service into our website and have successfully verified our domain with Apple manually. However, we consistently receive an 'ApplePay reverify failed' email a month before the expiration time. Upon checking, we updated the SSL certificate for the domain before receiving the email, and the link still works fine in the browser. We would greatly appreciate any feedback from someone who can help us with this issue.

We are getting this error frequently and our customers are getting increasing frustrated when they are unable to add their credit card to Apple Wallet. There is no clear explanation on when this error arises. I sincerely request help to understand the cause of this issue. Device info: Apple iOS 26.6.1.

Hello, we are developing in app provisioning of our American Express network cards. After clicking add to apple wallet in our app, I launch the PKAddPaymentPassViewController and click next. It loads for a few seconds and then I get: [<private>] ProvisioningOperationComposer: Step '<private>' failed with error Error Domain=PKProvisioningErrorDomain Code=5 UserInfo={PKErrorHTTPResponseStatusCodeKey=500} Does anyone have any insight on what this error means?

Hello, We are the developers of UbiFit Go, a fitness marketplace app (Portugal/EU). We offer live, real-time group fitness classes via video call, purchased as a credit pack exclusively on our external website (Stripe), and consumed in-app via a native button — with no links, buttons, or WebViews pointing to our website inside the app (only static informational text, e.g. "manage your credits from your account on our website"). Guideline 3.1.3(d) states that "one-to-few and one-to-many real-time services must use in-app purchase." We would like to confirm: Does this static-text-only pattern (no in-app link of any kind) still fall under 3.1.3(d), or is it exempt because there is no purchase flow or redirection happening inside the app at all? If it does fall under 3.1.3(d), does the EU External Purchase Link Entitlement (per the Digital Markets Act) apply to real-time one-to-many services such as live group fitness classes, or is that entitlement limited to non-real-time digital goods? We want to ensure full compliance before implementing this feature. Thank you.

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!

Good morning, We are experiencing issues with timeouts during the certificate handshake. We have checked the certificates and they are valid. Please could you assist us? Details are as follows: 2026-08-25T06:32:08.163472945Z – first error 2026-08-25T06:42:42.649765367Z 2026-08-25T15:53:01.713486959Z 26 August 2026 14:54:20.693697592Z 26 August 2026 15:09:43.343099296Z 26 August 2026 15:42:55.565622994Z An SSLHandshakeException has occurred. The certificates provided may not be valid {message={I/O error on POST request for ‘https://apple-pay-gateway.apple.com/paymentservices/paymentSession’: Remote host terminated the handshake}}} After one minute, we observe an error: 2026-08-25T15:56:35.280529678Z Calling Apple {url=https://apple-pay-gateway.apple.com/paymentservices/paymentSession} Then: 25 August 2026 15:57:35.504558588Z An SSLHandshakeException has occurred. The certificates provided may not be valid {message={I/O error on POST request for ‘https://apple-pay-gateway.apple.com/paymentservices/paymentSession’: Remote host terminated the handshake

I would like to sell physical printed books via my app on Apple. Is it permitted to do this? Can I link out to my physical bookstore outside of the App? What details or documentation do I need to provide to Apple to get this approved on the App Store?

I am seeing a reproducible Apple Pay card provisioning failure on iOS 27 Beta 6 (24A5418b). The card eligibility check succeeds and the Apple Pay provisioning response contains a valid termsID, but provisioning subsequently enters the Secure Element storage-management stage and fails with: SEStorageManagementSheet Code 4 SES.presentationTimedOut The Terms & Conditions screen therefore never appears and provisioning cannot continue. I reproduced the same system-level failure through multiple independent provisioning paths: First-party Apple Wallet provisioning with manual card entry Wallet-initiated provisioning that redirects to the issuer app Issuer-app initiated in-app provisioning The issue affects multiple issuers, including East West Bank and Mercury. The same iPhone successfully provisioned Chase UK and HSBC Hong Kong cards on an earlier iOS 27 beta build, and Apple Pay provisioning worked normally on iOS 26. I have already tested different network conditions, reset network settings, and removed two existing Apple Pay cards before reproduction. The behavior remains unchanged. Two separate sysdiagnoses show the same failure path. During the latest reproduction, SESUIServiceApp was successfully launched, but provisioning ultimately failed during SEStorageManagementSheet presentation with SES.presentationTimedOut. The captured RunningBoard state also showed SESUIServiceApp in a background/suspended state rather than maintaining a successful remote presentation. I have submitted the complete diagnostics and sysdiagnose files through Feedback Assistant: FB24403156 Could an Apple Wallet / Apple Pay engineer please review this Feedback and investigate the SESUIServiceApp / SEStorageManagementSheet remote presentation path on iOS 27? For privacy reasons, I am not attaching the full sysdiagnose publicly here; the diagnostic files are attached to FB24403156

Hello. We are an acquirer and we have timeouts in about 7-8% of requests to https://apple-pay-gateway.apple.com/paymentservices/paymentSession in the last 30 minutes since 07:00 EET. Our timeout is 60 seconds. We've checked and don't see any issues on our side. There were no changes in our infrastructure setup.

Our issuer app's in-app provisioning fails at ProvisioningStepEligibility with PKPaymentWebServiceErrorDomain Code=40001 "Invalid Card - Check the information on your card and try again." (HTTP 403), before Terms & Conditions are presented. Setup: Mastercard/US, PNO Payment Data Configuration 3 (Encrypted FPAN), EV_ECC_V2, TestFlight build, initiated from the issuer app. The certificate fetch (issuerProvisioningCertificates?encryptionVersion=EV_ECC_v2) returns 200, the ephemeral public key is uncompressed 65 bytes with a leading 0x04, and the Configuration 3 payload contains all eight required keys with correctly hex-encoded nonce and nonceSignature. Since the request reaches the eligibility step and returns a card-level error rather than a cryptography error, the rejection appears to be on the card data itself rather than the envelope. Filed with sysdiagnose, timestamps, and full correlation identifiers as FB24418152. We would appreciate help determining whether errorCode 40001 originates from Apple's validation of the decrypted payload or is relayed from the PNO, and if Apple decrypted it, which field failed validation. Thank you

Please take a look at: FB22280049

Hello, We are an acquirer and payment service provider offering Apple Pay to our merchants through our hosted checkout page. We started processing Apple Pay transactions in production at the beginning of this month. However, we cannot find our company name on the Payment Service Providers list below: https://developer.apple.com/apple-pay/payment-platforms/ Could you please advise us on the process and requirements for having our company added to this Payment Service Providers list?

Hi, I uploaded the files for the domain verification and the domains got verified, now when the ssl certificate is about to expire i get emails for it but after i renewed it before it expired the emails wont stop and when i try to reverify through the portal I get "Domain verification failed.". When i redownload new domain files and upload them to my server and try to reverify, it works. can someone think why would this happen?

Posting this here because I lost way too many hours on it and hopefully someone finds this before going down the same rabbit hole. Apple Support's support was basically asking me to check the docs and this forum for solutions. I guess it's better than saying "google it yourself", but not much better ;) The issue was that Apple Pay merchant domain verification kept failing, both automated and manual. I checked pretty much everything: domain association file HTTPS DNS TLS App Service configuration Merchant ID openssl verification The interesting part was that everything looked perfectly healthy. Browsers were happy, OpenSSL reported Verify return code: 0 (ok), and there were no TLS errors. Turned out the problem was Apple's verification mechanism incompatibility with the new Generation Y cert chain, which is used as default by Let's Encrypt. My site was using a Let’s Encrypt ECDSA certificate with this chain: → YE1 → Root YE → ISRG Root X2 I reissued it as RSA (still Let’s Encrypt), which resulted in: → YR2 → Root YR → ISRG Root X1 Apple Pay domain verification started working immediately. If you’re using Certbot: sudo certbot certonly --manual --preferred-challenges http --key-type rsa --rsa-key-size 2048 --force-renewal --cert-name yourdomain.com -d yourdomain.com I don’t know whether Apple Pay currently has an issue with Let’s Encrypt’s newer Generation Y ECDSA hierarchy, or whether something in their merchant validation infrastructure doesn’t like that chain. If you’ve already checked the usual stuff and everything looks correct, this is definitely worth trying before spending another day debugging.

unable to add sandbox mastercard to iwatch wallet, no issue for amex. slightly difficult and failed but in the end managed to add visa after several manual input sandbox test card. Please take a look at 23315137

We are implementing In-App Provisioning functionality for our Bank but there is always 500 Internal Server Error respond by Apple server once we tried to add card to apple wallet. Our code let request = PKAddPaymentPassRequest() request.activationData = try decodeBase64(payload.activationDataText, field: "activationDataText") request.encryptedPassData = try decodeBase64(payload.encryptedDataText, field: "encryptedDataText") request.ephemeralPublicKey = try decodeBase64(payload.ephemeralPublicKeyText, field: "ephemeralPublicKeyText") return request Because of fPanId is not required so we are not pass it to Apple server and that field generated once the card already added to wallet. Please help us investigate the issue, thanks! FeedbackId 24065847 (In-App Provisioning 500 Internel Error)