Apple Pay for Partners brings together the latest news, features, and fraud protection information for issuers, merchants, and platforms — all designed to support your integration and help you deliver the payment experience customers know and trust. Available in English only. Explore Apple Pay for Partners >

I am working on In-App-Verification. I am able to add my cards manually in the Apple Wallet Sandbox. I am getting the option to Verify using App. When I click on the Verify Button, I am able to redirect to my Testflight App. But when I use the API PKPassLibrary().pass(withPassTypeIdentifier: passTypeIdentifier, serialNumber: serialNumber) its not returning me the expected Pass. It is infact giving an empty result The entitlements which I already have added are: com.apple.developer.pass-type-identifiers com.apple.developer.payment-pass-provisioning So I have below questions: Do I need to do something else for PassKit API's to work? Is it even possible to test In-App-Verification in the TestFlight App using sandbox Wallet? Is it possible to redirect user to debug and enterprise builds also as currently the redirection from Apple Wallet is not working for debug and enterprise builds? The PassKit API which I indicated earlier is working in debug build when I sideload from Xcode. But since deeplink from Wallet does not work for debug builds, I am not able to proceed with testing. What will be behavior in App-Store build production environment without using sandbox, by using real cards? Will it work there?

I am working on In-App-Verification. I am able to add my cards manually in the Apple Wallet Sandbox. I am getting the option to Verify using App. When I click on the Verify Button, I am able to redirect to my Testflight App. But when I use the API PKPassLibrary().pass(withPassTypeIdentifier: passTypeIdentifier, serialNumber: serialNumber) its not returning me the expected Pass. It is in-fact giving an empty result So I have below questions: Do I need to do something else for PassKit API's to work? Is it even possible to test In-App-Verification in the TestFlight App using sandbox Wallet?

I am a PSP for Apple Pay, and I have been experiencing timeouts while registering a domain for my merchant. What configurations should my merchant make?

Hi, We recently applied for the Web Merchant Registration API and created our platform integrator ID. I am trying to register a domain in sandbox with the API: POST https://apple-pay-gateway-cert.apple.com/paymentservices/registerMerchant Content-Type: application/json { "domainNames": ["<URL>"], "partnerInternalMerchantIdentifier": "<merchant_id>", "partnerMerchantName": "<merchant_name>", "encryptTo": "<platform_integrator_id>" } Client certificate is provided via curl --cert/--key; the TLS 1.3 handshake completes successfully — the server requests the client cert, our Certificate + CERT verify are accepted, and the connection is established. But the response is { "statusMessage": "Payment Services Exception Unauthorized", "statusCode": "401" } How do I go about debugging this?

We are unable to verify our Apple Pay merchant domains. Apple Developer Portal returns: “Domain verification failed. Review your TLS Certificate configuration to confirm that the certificate is accessible and a supported TLS Cipher Suite is used.” We have confirmed that the verification endpoints are publicly accessible, return HTTP 200, and support TLS 1.2/1.3 with valid certificates and supported cipher suites. The domains are behind Cloudflare. However, when verification is triggered, we do not see an HTTP request from Apple in our Cloudflare request logs. Has anyone experienced a similar issue with Apple Pay merchant domain verification, especially with domains behind Cloudflare? We have also submitted a report through Feedback Assistant.

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!

Does anyone know how to implement Apple Account Binding for Wallet Pass function like https://www.ticketswest.com/customer-service/nfc-apple-account-binding/apple-account-bin

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.