We are an acquirer and PSP with our own payment gateway. Merchants can either: Use an Apple Pay payment page hosted by us, or Host their own payment page and submit payment data to us via server-to-server APIs. We are currently implementing Apple Pay on the Web using the Platform Integrator model. The acquirer-hosted payment page flow is clear to us, but we have a few questions regarding merchant-hosted payment pages. Our current understanding (please correct us if any of this is incorrect) We register each merchant using the Web Merchant Registration API as a Platform Integrator, with a unique partnerInternalMerchantIdentifier. Merchants do not have their own Apple Developer accounts. For merchant-hosted payment pages, the merchant's checkout domain is provided in domainNames. The domain verification file is downloaded from our Apple Developer account (Platform Integrator account), and the merchant hosts that file under the /.well-known/ path on their domain. The merchant registration created through the Web Merchant Registration API is then used for Apple Pay eligibility checks and merchant validation. Questions: Domain registration For a merchant-hosted payment page, is it correct to register the merchant's domain against that merchant's partnerInternalMerchantIdentifier registration? Verification file When onboarding multiple merchants: Is the same domain association file used across all merchant domains? Or is a unique verification file generated per merchant registration? Eligibility checks and Apple Pay button The "Supporting Apple Pay on Third-Party Browsers" documentation (Scenario 3) suggests that a payment service provider may provide a JavaScript library that loads apple-pay-sdk.js for merchants. For merchant-hosted pages, is it supported and recommended for the PSP/platform integrator to provide a thin wrapper library around: canMakePayments() applePayCapabilities() Apple Pay button rendering Session creation Or is Apple’s preferred approach that the merchant's checkout page interacts directly with Apple Pay JS APIs? PSP/acquirer decrypts the payment token If the PSP/acquirer is responsible for token decryption, we understand that encryptTo should be set to the Platform Integrator identifier. For merchant-hosted payment pages, are there any additional requirements beyond domain registration and merchant validation? Merchant decrypts the payment token We would also like to support a model where the merchant decrypts Apple Pay tokens directly. In that case, our understanding is that encryptTo must reference the merchant's identifier rather than the Platform Integrator identifier. Is that understanding correct, and are there any additional onboarding or registration requirements for that model? Merchant validation For merchant-hosted checkout pages, what is the expected implementation pattern for onvalidatemerchant? Specifically: Should the merchant's frontend send the validationURL to the PSP/platform integrator backend, which then performs merchant validation with Apple and returns the merchant session? Or is a different flow expected when using the Platform Integrator model? Any clarification or guidance would be greatly appreciated. Thank you.

Our payment processor can't decrypt the Apple Pay payment tokens for some of our recurring payment (continuous payment authority) set-ups. These are Apple Pay on the Web payments where the request includes a recurringPaymentRequest, to set up the agreement without taking a payment. Our payment processor says the decryption fails on their side before the payment is authorised, and they asked us to raise it with Apple. Our one-off Apple Pay payments with the same merchant ID decrypt normally as do a number of our recurring payments. We have reviewed the decryption errors section of troubleshooting-apple-pay-payment-processing-issues and haven't found a cause that explains why only the recurring set-ups fail. We have the transaction identifiers and timestamps for the affected payments, and we can share them privately. Could you confirm whether these tokens were encrypted with our merchant's payment processing certificate, and whether recurring or merchant-token set-ups are handled differently? The code-level support form asked us to post here first because we don't have an Xcode project. If Feedback Assistant would be better for this, we're happy to file a report there and reply with the Feedback ID. Thank you

im developing apple pay in safari and im using iPhone 15 & ios version 26.5 to test. im testing the scenario, when user is logged off apple account and try apple pay, there should be a pop up message, giving user two options: Cancel & Sign In. when im testing on mac, the pop up window works fine with title 'Apple Pay requires icloud' - Sign in your apple account to set up apple pay - cancel & sign in however, when im testing on my iphone, the pop up window vanish very quickly in like 1 second. im wondering how to fix the issue so that user can be redirect to sign in their account.

Hi everyone, I’m hoping someone here can help or advise me on what to do next. I enrolled in the Apple Developer Program and completed the payment on October 1, 2026. However, my account is still showing Pending, and the Developer portal is still asking me to purchase the membership again. My details are: Enrollment ID: X2YRV8DQ57 Order ID: W1988568006 Payment date: October 1, 2026 Current status: Pending Developer portal still shows: “Purchase your membership” I have already contacted Apple Developer Support and sent them all the required details, including the payment information and screenshots, but I am still waiting for a resolution. The frustrating part is that Apple Developer Support is not responding to my follow-up emails, and when I contact Apple customer service by phone, they are unable to help because they apparently do not have access to the Apple Developer enrollment/payment system. I am currently completely blocked because I need the Developer Program membership to continue with App Store Connect and TestFlight testing, but I also do not want to pay for the membership a second time when I have already completed the payment. Has anyone experienced this recently? If so: How long did it take for Apple to activate your account? Was there any specific Developer Support team you contacted? Is there any way to escalate an enrollment/payment issue? Should I continue waiting, or is there another process I should follow? Any guidance would be greatly appreciated. I have already provided Apple with my order and enrollment information, but I have not received any meaningful update yet. Thanks in advance.

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?

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.

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?

Environment macOS 26.5.1 (Build 25F80) Safari 26.5 Apple Pay JS API version 8 Using https://applepay.cdn-apple.com/jsapi/v1/apple-pay-sdk.js Reproduces on the staging website (Does not reproduce on the production website with non sandbox account) Signed into a Sandbox Tester Apple ID, with a test credit card registered exactly per Apple Pay Sandbox Testing — this is the only card in Wallet on the laptop Merchant validation is performed by our staging backend against our real (non-sandbox) merchant identity/certificate — i.e. a sandbox tester card being evaluated against a staging merchant session, which per the sandbox testing documentation is the expected/supported setup for testing on a live site without a separate merchant sandbox environment Summary After completeMerchantValidation() succeeds and the merchant session is accepted, the payment sheet still terminates with PKPaymentAuthorizationStateFatalError a few hundred milliseconds later, right after the native side logs a second "Evaluating merchant session using PROD trust policy." for the same session. The user sees "Payment failed" and the sheet closes. This happens on the very first attempt, with no user interaction beyond tapping the Apple Pay button — no shipping address is even selected before the failure. Since the sandbox tester card + production merchant session combination is the setup the sandbox testing guide describes, we'd expect the sheet to proceed to onpaymentauthorized (Apple's sandbox docs describe payments as being processed as $0 test transactions in this mode) rather than fail natively before that stage is ever reached. Steps to reproduce Visit an item page with an Apple Pay button. Tap the Apple Pay button to open the payment sheet. The sheet presents normally; no interaction with shipping address or payment method is required for the failure to occur. Within ~1 second, the sheet dismisses and displays a "Payment failed" error state. Minimal reproduction of the JS side const session = new ApplePaySession(8, { countryCode: 'US', currencyCode: 'USD', supportedNetworks: ['visa', 'masterCard', 'amex', 'discover'], merchantCapabilities: ['supports3DS'], total: { label: 'Merchant', amount: '10.00' }, }); session.onvalidatemerchant = async () => { const merchantSession = await validateMerchantOnServer(); // succeeds session.completeMerchantValidation(merchantSession); // accepted — see log below }; session.onpaymentmethodselected = () => { session.completePaymentMethodSelection({ newTotal: { label: 'Merchant', amount: '10.00' }, }); }; session.oncancel = event => console.log('cancelled', event); session.begin(); We reproduced this with both our full checkout implementation and this stripped-down request object (no shipping contact required, no line items) — same failure either way, which rules out anything about our order/line-item data. What we expected The sheet to proceed to the biometric authorization step and dispatch onpaymentauthorized once the user confirms. What actually happens The sheet fails immediately with a PKPaymentAuthorizationStateFatalError transition, even though every JS-side completion call (completeMerchantValidation, the payment-method selection) succeeded and returned PKPaymentAuthorizationStatusSuccess. System log (captured via log stream --info --debug --predicate 'process == "Safari" OR process == "passd" OR process == "com.apple.PassKit.PaymentAuthorizationUIExtension"') 21:50:41.544 PaymentCoordinator::beginPaymentSession() -> 1 21:50:41.570 Received prepareWithPaymentRequest: <private> 21:50:42.297 PaymentCoordinator::validateMerchant() 21:50:42.563 PaymentCoordinator::completeMerchantValidation() 21:50:42.564 Received merchant session update with status:PKPaymentAuthorizationStatusSuccess session:<private> 21:50:42.564 Evaluating merchant session using PROD trust policy. <- 1st occurrence, passes 21:50:42.572 PaymentCoordinator::didSelectPaymentMethod() 21:50:42.572 PaymentCoordinator::completePaymentMethodSelection() 21:50:42.653 Evaluating merchant session using PROD trust policy. <- 2nd occurrence 21:50:42.656 State machine change state from ClientCallback to PrepareTransactionDetails with param: <private> 21:50:43.391 Task Completed: <private> 21:50:43.393 State machine change state from PrepareTransactionDetails to PKPaymentAuthorizationStateFatalError with param: <private> 21:50:43.393 Error Payment failed with fatal error <private> 21:50:45.130 PaymentCoordinator::didCancelPaymentSession() The first "Evaluating merchant session using PROD trust policy." line passes (the flow continues to didSelectPaymentMethod). The second occurrence is immediately followed by Task Completed and then the FatalError transition, which suggests PassKit re-validates the merchant session's trust a second time right before PrepareTransactionDetails, and that second check is what's rejecting the session — even though the identical session object was accepted moments earlier at completeMerchantValidation(). What we've tried / ruled out Confirmed every JS completion method (completeMerchantValidation, completePaymentMethodSelection) is called and returns success — no 30-second timeout, no missing completion call, no thrown exception on our side. Reproduced with a minimal, hardcoded ApplePayPaymentRequest (fixed $10.00 total, no shipping fields) — rules out anything about our real order/line-item/sales-tax data. Reproduced on the main branch and independently on our staging deployment running unmodified code — rules out anything specific to our recent frontend changes. The <private> redaction in the system log prevents us from seeing what specifically fails during the second trust evaluation. Confirmed the sandbox tester card and its registration follow the sandbox testing guide exactly — it's the only card on the device, and no other Wallet cards are involved. Question What does PassKit's second "Evaluating merchant session using PROD trust policy" check (immediately before PrepareTransactionDetails) actually validate, beyond what's already checked at completeMerchantValidation() time? Is a sandbox tester card being evaluated against a production merchant session expected to pass this second check, or does sandbox testing per the linked guide require something additional on the merchant/session side (e.g. a specific field on the merchant session, or a specific environment value) that our backend isn't setting? Is there a way to get an unredacted reason for the rejection — e.g. via a private-data-enabled log profile or another diagnostic — since the redacted system log alone doesn't surface one?

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

Hello everyone, We are experiencing an issue with our Apple Pay integration on a Magento 2 store using the Rootways Authorize.net module. Standard Credit Card and Google Pay transactions are processing without issue, but Apple Pay transactions are failing immediately after user authentication. Issue Description The Apple Pay payment sheet opens correctly, and the customer is prompted for biometric verification. Immediately after completing the biometric verification, the UI spins briefly and then states that the payment failed. Technical Details & Console Logs Reviewing the browser developer console during the failure reveals the following sequence: Merchant Validation Success: The rw_onvalidatemerchant function executes successfully. The promise returns as "fulfilled" and generates the proper payload, including the merchantSessionIdentifier, nonce, and signature for our domain (2b5eae029c.nxcli.io). Cancel Event Triggered: Shortly after successful validation, an ApplePayCancelEvent is thrown while a promise is still "pending". Unknown Session Error: Within this cancel event, the sessionError returns a code of "unknown" with an empty info: {} object. Context Error: We are also seeing a strict mode JavaScript error in the object prototype reading: TypeError: 'arguments', 'callee', and 'caller' cannot be accessed in this context. Environment details: Platform: Magento 2 Payment Module: Rootways Authorize.net Domain: 2b5eae029c.nxcli.io Has anyone encountered this specific sequence of events or seen this strict mode JS error trigger an ApplePayCancelEvent? Any guidance on why the session triggers a cancel event post-verification—or suggestions on how to further debug this "unknown" session error—would be greatly appreciated. Thank you!

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.

We manage provisioning for a large number of App IDs across multiple apps via CI, using the App Store Connect API (not session-based Spaceship/Xcode auth). Capability management works well end to end for everything we've tried — Push Notifications, App Groups, Associated Domains, Data Protection, etc. can all be created, updated, and deleted via POST/PATCH/DELETE on /v1/bundleIdCapabilities. Apple Pay is the one exception. We can enable the Apple Pay capability itself via the API the same way as anything else, but there's no way to associate that capability with a specific Merchant ID. /v1/merchantIds exists as its own resource, but nothing in the bundleIdCapabilities or bundleIds schema links to it — no relationship, no include, no dedicated endpoint. In practice this means every new Apple Pay-enabled App ID we provision needs someone to go into the Developer Portal by hand (Identifiers → App ID → Capabilities → Apple Pay → select Merchant ID) before the generated provisioning profile will actually build — otherwise Xcode fails with errors like "doesn't include the Apple Pay capability" / "doesn't support the Merchant ID". Every other capability we use is fully scriptable; this is the one manual step left in an otherwise automated pipeline. Has anyone found a documented (or undocumented) way to do this via the API? If this is a confirmed gap rather than something we're missing, I've filed it as FB24414090 — if you've hit the same thing, adding your own Feedback number to a report on the same gap seems to be one of the few things that actually helps get traction internally, so feel free to reference this thread if you file one too.

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

Hi everyone, I am stuck in a serious account provisioning/sync loop and need some advice or visibility from Apple moderators. The Issue: I purchased and completed the $99 Apple Developer Program subscription directly through the official Apple Developer app on iOS. The charge is fully processed, and the subscription shows as active under my Apple ID subscriptions and bank account. However, when I log into developer.apple.com with the exact same Apple ID, the portal completely ignores my active membership and redirects me to the "Become a member / Start your enrollment" page. Because the web backend doesn't recognize my active subscription, App Store Connect loads a completely blank/white screen on web browsers, and the App Store Connect iOS app throws Error 2002 (Developer Account Required). What I've tried: Double-checked that I am logged into the exact same email/Apple ID across all platforms. Cleared all browser cache, cookies, and tried Incognito/Private mode on multiple browsers (Safari & Chrome) and different devices. Tried waiting out the 48-hour sync window, but the system is completely disconnected. It seems like a critical backend synchronization bug where the App Store subscription ledger failed to update my developer team portal profile status to Active. Has anyone found a way to trigger the sync manually, or do I have to wait for senior developer relations support to do a manual override? Any help or advice would be greatly appreciated. its been 4 days ago and nothing