Hi, You're here because you've had issues with your implementation of In-App Provisioning Extensions for Apple Pay In-App Provisioning or In-App Verification. To prevent sending sensitive credentials in plain text, create a new report in Feedback Assistant to share the details requested below with the appropriate log profiles installed. Gathering Required Information for Troubleshooting Apple Pay In-App Provisioning or In-App Verification Issues While troubleshooting Apple Pay In-App Provisioning or In-App Verification, it is essential that the issuer is able to collect logs on their device and check those logs for error message. This is also essential when reporting issues to Apple. To gather the required data for your own debugging as well as reporting issues, please perform the following steps on the test device: Install the Apple Pay and Wallet profiles on your iOS or watchOS device. If the issue occurs on Mac, continue to Step 2. Reproduce the issue and make a note of the timestamp when the issue occurred, while optionally capturing screenshots or video. Gather a sysdiagnose on the same iOS or watchOS device, or on macOS. Create a Feedback Assistant report with the following information: The bundle IDs App bundle ID Non-UI app extension bundle ID (if applicable) UI app extension bundle ID (if applicable) The serial number of the device. For iOS and watchOS: Open Settings > General > About > Serial Number (tap and hold to copy). For macOS: Open the Apple () menu > About This Mac > Serial Number. The SEID (Secure Element Identifier) of the device, represented as a HEX encoded string. For iOS and watchOS: Open Settings > General > About > SEID (tap and hold to copy). For macOS: Open the Apple () menu > About This Mac > System Report > NVMExpress > Serial Number. The sysdiagnose gathered after reproducing the issue. The timestamp (including timezone) of when the issue was reproduced. The type of provisioning failure (e.g., error at Terms & Conditions, error when adding a card, etc.) The issuer/network/country of the provisioned card (e.g., Mastercard – US) Last 4 digits of the FPAN Last 4 digits of the DPAN (if available) Was this test initiated from the Issuer App? (e.g., yes or no) The type of environment (e.g., sandbox or production) Screenshots or videos of errors and unexpected behaviors (optional). Important: From the logs gathered above, you should be able to determine the cause of the failure from PassbookUIService, PassKit or PassKitCore, and by filtering for your SEID or bundle ID of your app or app extensions in the Console app. Submitting your feedback Before you submit to Feedback Assistant, please confirm the requested information above is included in your feedback. Failure to provide the requested information will only delay my investigation into the reported issue within your Apple Pay client. After your submission to Feedback Assistant is complete, please respond in your existing Developer Forums post with the Feedback ID. Once received, I can begin my investigation and determine if this issue is caused by an error within your client, a configuration issue within your developer account, or an underlying system bug. Cheers, Paris X Pinkney |  WWDR | DTS Engineer

Hi, To ensure the issue is not caused by an error within your app or web service request, please review the Apple Pay Merchant Integration Guide. Additionally, please review the following technotes on Apple Pay: TN3173: Troubleshooting issues with your Apple Pay merchant identifier configuration TN3174: Diagnosing issues with the Apple Pay payment sheet on your website TN3175: Diagnosing issues with displaying the Apple Pay button on your website TN3176: Troubleshooting Apple Pay payment processing issues TN3206: Updating Apple Pay certificates If the resources above don’t help identify the cause of the error, please provide more information about your app or web services to get started. To prevent sending sensitive credentials in plain text, create a report in Feedback Assistant to share the details requested below. Additionally, if the error is something we need to investigate further, the appropriate engineering teams also have access to the same information and can communicate with you directly within Feedback Assistant for more information, as needed. Please follow the instructions below to submit your report. For issues occurring with your native app or web service, perform the following steps: Install the Apple Pay profile on your iOS or watchOS device. If the issue occurs on Mac, continue to Step 2. Reproduce the issue and make a note of the timestamp when the issue occurred, while optionally capturing screenshots or video. Gather a sysdiagnose on the same iOS or watchOS device, or on macOS. Create a Feedback Assistant report with the following information: The serial number of the device. For iOS and watchOS: Open Settings > General > About > Serial Number (tap and hold to copy). For macOS: Open the Apple () menu > About This Mac > Serial Number. The SEID (Secure Element Identifier) of the device, represented as a HEX encoded string. For iOS and watchOS: open Settings > General > About > SEID (tap and hold to copy). For macOS: Open the Apple () menu > About This Mac > System Report > NVMExpress > Serial Number. The sysdiagnose gathered after reproducing the issue. The timestamp of when the issue was reproduced. Screenshots or videos of errors and unexpected behaviors (optional). Important: From the logs gathered above, you should be able to determine the cause of the failure from PassbookUIService, PassKit or PassKitCore, and by filtering for your SEID or merchant domain in the Safari Web Inspector. See Inspecting Safari on macOS to learn more. Submitting your feedback Before you submit to Feedback Assistant, please confirm the requested information above is included in your feedback. Failure to provide the requested information will only delay my investigation into the reported issue within your Apple Pay website. After your submission to Feedback Assistant is complete, please respond in your existing Developer Forums post with the Feedback ID. Once received, I can begin my investigation and determine if this issue is caused by an error within your web implementation, a configuration issue within your developer account, or an underlying system bug. Cheers, Paris X Pinkney |  WWDR | DTS Engineer

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?

Hello, We are trying to provision in apple wallet, I am getting an error "Card can not be added". Please check below and let me know if I am missing anything. SEID: 04401D7BCE578001930001236930311377D86C15D956BBA1 TimeStamp: 2025-08-18 11:53:04.570431-0500. CST Last 4 FPAN: 2345 Thanks

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

Waiting on in-app provisioning approval. First time submitting the app. The process changed after we submitted initially but its been three months now. Every time I reach out I either get a generic response or nothing at all. What is going on? This has been a horrible experience.

We had noticed “paymentCredentialsAvailable” is getting returned more from apple pay capabilities for some unexpected devices (our example is windows + chrome). Based off the documentation this should only be returning if this is linked to a wallet account w/ valid payment. From some investigation this appears to have changed from apple pay js v1.3.7 to v1.3.8 (latest). Previously the above windows + chrome example would return “paymentCredentialStatusUnknown” which is what would be expected in this case. Tried running chrome in icognito mode and clearing cookies just in case this check had some linkage to the apple account via QR code usage, but did not appear to affect the returned response. Unsure if this is a bug or a change to the logic, but doesn’t appear to be appropriately reflected in the documentation, also a change like this should not be appearing in a patch version. Has anyone else experienced this?

Hello, We are implementing in-app provisioning in our banking app but are having trouble getting to the Terms & Conditions screen. User taps on “Add to Apple Wallet” > PKAddPaymentPassViewController > Next > the flow fails quickly with "Could Not Add Card -> Set Up Later" alert. The only notable thing in the logs, as far as I can see is the https://nc-pod12-smp-device.apple.com:443/broker/v4/devices/{SEID}/cards fails with: <html> <head><title>500 Internal Server Error</title></head> <body> <center><h1>500 Internal Server Error</h1></center> <hr><center>Apple</center> </body> </html> and maybe ProvisioningOperationComposer: Step 'eligibility' failed with error <PKProvisioningError: severity: 'terminal'; internalDebugDescriptions: '( "eligibility request failure", "Received HTTP 500" )'; underlyingError: 'Error Domain=PKPaymentWebServiceErrorDomain Code=0 "Unexpected error." UserInfo={PKErrorHTTPResponseStatusCodeKey=500, NSLocalizedDescription=Unexpected error.}'; userInfo: '{ PKErrorHTTPResponseStatusCodeKey = 500; }'; > Feedback Assistant ID: FB22932141 (Error during In-App Provisioning)

We are implementing in-app provisioning in our fintech app; We are reaching out to ask for your help in understanding what is going wrong so we can fix it. What happens: User taps “Add to Apple Wallet” → we present PKAddPaymentPassViewController → they tap Next → after a few seconds the flow fails with "Set Up Later" alert. Device log: "eligibility request failure", "Received HTTP 500" )'; underlyingError: 'Error Domain=PKPaymentWebServiceErrorDomain Code=0 "Unexpected error." UserInfo={PKErrorHTTPResponseStatusCodeKey=500, NSLocalizedDescription=Unexpected error.}'; userInfo: '{ PKErrorHTTPResponseStatusCodeKey = 500; }'; > Feedback Assistant ID: FB22176928 (In-App Provisioning issue 500 Internal Server Error)

Im trying to implement add to Apple Pay feature in my app. I have an issuer bank's credit card as an existing feature. Now question is, say its added successfully already, I relaunch my app, how to tell if already added to Apple Pay? I have made some reads, and asked AIs, but I can't seem to get a clear answer. Passkit's primaryAccountIdentifier - if use this, how will our backend store this? I mean, I don't think its ideal approach for mobile app to be responsible for calling backend api. deviceAccountNumberSuffix - what if my app have other cards that can be added to Apple Pay and has same suffix. Then seems broken flow.

Hi,
 We’re implementing Apple Pay on the Web for a multi-tenant platform via a PSP. The PSP operates multiple HSM/clusters and gave us multiple CSRs, asking us to register all.
Our understanding: a Merchant ID can hold several PPCs over time, but only one is active at once. Questions Is there any supported way to keep more than one PPC active simultaneously for the same Merchant ID? If not, what does Apple recommend for web-only, multi-tenant setups: a single MID with PSP-side decryption & sub-merchant separation, or separate MIDs per brand/region? Any official guidance on PPC rotation and handling many domains for Apple Pay on the Web? links to official docs or prior Apple responses would be appreciated.

We are writing to report a recurring stability issue with the Apple Pay sandbox environment. We are using the official sandbox test cards provided on the Apple Developer website for our testing: https://developer.apple.com/apple-pay/sandbox-testing/ We are experiencing frequent, intermittent failures when attempting to add these sandbox cards to the Wallet for testing purposes. The issue typically occurs a couple of times per day. When the failure occurs, the card provisioning process fails unexpectedly. The issue is not limited to a single card; we have observed this behavior across all available card networks. In some instances, all cards (Visa, Mastercard, Discover, Amex) fail to provision simultaneously. At other times, the issue appears to be isolated to specific networks while others work correctly. Crucially, the issue appears to be temporary. After some time passes (ranging from minutes to an hour), we are able to add the exact same card successfully without making any changes to our test environment or configuration. We have diligently checked our setup to rule out configuration errors on our end. This includes verifying: The device is set to a supported region. We are signed in with a valid sandbox tester Apple ID. All other prerequisites for sandbox testing are met. The fact that the process works correctly at other times strongly suggests that this is a server-side stability issue within the Apple Pay sandbox environment rather than a persistent misconfiguration on our part. To help with your investigation, we have attached an image that demonstrates a failed attempt to add a card. Could you please investigate the stability of the sandbox card provisioning service? Please let us know if this is a known issue or if there is any further information we can provide. Thank you for your time and assistance.

Hello, We are experiencing an issue with Apple Pay integration in our application. We are using WKWebView to handle various payment methods, but we are unable to complete payments via Apple Pay. Upon debugging the WKWebView, we received the following error message: "400 No required SSL certificate was sent" when attempting to process the payment. Currently, we are using a Let's Encrypt SSL certificate. Could you please confirm whether this certificate is suitable for Apple Pay, or if we should be using a different SSL certificate?

Hello, I have recently started exploring the Apple Wallet extension and have a couple of questions I was hoping you could help clarify: Is there any form of communication between the UI extension and the non-UI extension? From my understanding, the UI extension handles the authorization and simply indicates whether the app approves it or not, without passing additional data. However, the non-UI extension is expected to make calls to the issuer app’s backend, which typically require a token obtained through prior authentication services and may even involve an OTP. Is there a recommended way to share this information between extensions within the Apple Wallet Extension framework, or is using App Groups the only option? Additionally, during the provisioning process, is there any possibility of re-invoking the UI extension if further validation is required? Furthermore, according to the documentation, testing is carried out via TestFlight and in production. Is there any way to test these extensions on a physical device directly from Xcode for debugging purposes, or is TestFlight the only available method? Thank you very much in advance for your time and assistance.

Hi, I’ve been trying to integrate Apple Pay, but for some reason, the payment button is not showing up. The project is built with Laravel 11 and Vue. I imported the script as follows: <script crossorigin crossorigin src="https://applepay.cdn-apple.com/jsapi/1.latest/apple-pay-sdk.js" ></script> Then I added the following the steps: <style> apple-pay-button {{ --apple-pay-button-width: --apple-pay-button-width: 150px;; --apple-pay-button-height: --apple-pay-button-height: 30px;; --apple-pay-button-border-radius: --apple-pay-button-border-radius: 3px;; --apple-pay-button-padding: --apple-pay-button-padding: 0px 0px;; --apple-pay-button-box-sizing: border-box; } </style> <apple-pay-button buttonstyle="black" type="plain" locale="en-US"></apple-pay-button> I followed all the steps from the official Apple Pay demo: https://applepaydemo.apple.com/ I also configured the Content Security Policy (CSP) to allow all necessary resources. However, when I test my integration, the button doesn’t appear. I’ve checked the console, but there are no errors. At the same time, I have my certificate imported into the Keychain, and I’ve completed the entire process of creating both the certificate and the private key. However, when I try to validate the session using the certificate and key with Apple’s API, I get an error: 400 The SSL certificate error https://apple-pay-gateway-cert.apple.com/paymentservices/

We are developing a native iOS financial application called Tradu: Stocks, Forex, and CFDs (Apple ID: 6473443264), which embeds a WKWebView to render all user-facing logic. All user interactions—including authentication with MFA—occur inside this WKWebView. To access native functionality, we use postMessage() to communicate between the web and native layers. This approach has worked successfully for biometric authentication, for example. We are currently integrating Apple Pay In-App Provisioning and have a few questions regarding compliance with the documentation provided by our Issuer Host (Modulr). In the document titled Getting Started with Apple Pay: In-App Provisioning, Verification, Security, and Wallet Extensions (Version 4.0, February 2023), all examples are based on a fully native application. We’ve managed to integrate most of the In-App Provisioning flow via postMessage() up to the point of passing encryptedData to the Payment View. Apple Pay button inside WKWebView In Section 7: Frontend Overview, the user initiates the provisioning by tapping a native PKPaymentButton (SwiftUI example). In our case, this button is rendered inside the WKWebView, styled according to the Apple Style Guide. While the document references this approach as a “raw mark text supplement,” is this method acceptable and compliant with Apple’s UX and technical guidelines? MFA requirement before provisioning In Section 4: Security Guidelines, it is stated that the user must have passed MFA at least once before starting the provisioning flow. In our implementation, users must complete MFA on every login (including on recognized devices) before the provisioning UI becomes available. Even though this is not tied specifically to “unrecognized devices,” is our MFA requirement sufficient to satisfy Section 4.2? Summary: Is using a web-rendered Apple Pay button inside WKWebView (instead of a native PKPaymentButton) considered compliant? Is our MFA enforcement model (required on every login) aligned with the security requirements outlined in Section 4.2 of the Apple Pay In-App Provisioning documentation?

I am trying to play around on the Apple Pay demo page (https://applepaydemo.apple.com) and I am getting the following error response. PaymentRequest AbortError: The operation was aborted. I am using the Payment Request API

Hello, We are experiencing a consistent delay when initiating Apple Pay sessions using the https://apple-pay-gateway.apple.com/paymentservices/startSession endpoint. Below is a detailed overview of our setup and the issue. Setup Our web service is hosted in AWS and there is a proxy server between our web service and Apple servers. We are passing the correct domain in the initiativeContext field of the startSession request. The .well-known/apple-developer-merchantid-domain-association file is hosted on a different domain, which is also correctly configured and associated with our merchant ID in the Apple Developer portal. Observed Behavior When the same request is made from a local development environment, Apple responds immediately (under 1 second). When the request is made from our AWS-hosted service, Apple responds with a valid session, but only after a consistent ~15-second delay. The content and response are otherwise identical — only the timing differs. We would appreciate any insights or suggestions from others who have faced similar behavior or from the Apple Pay team. Thank you in advance!

We are experiencing intermittent 403 Forbidden errors during Apple Pay on web merchant validation in our production and sandbox environment. Has anyone else started seeing 403 Forbidden errors recently (since mid-2025)? Why would merchant validation be sometimes successful and sometimes fail with 403? Could this be related to new Apple Pay gateway changes or stricter validation rules? Any additional debug steps or permanent solutions we should try? Thank you.

We are unable to add/remove Merchant IDs in App IDs identifier profile, after pressing "Edit" button on "Apple Pay Payment Processing" section, then choosing desired Merchant ID to check/uncheck from the available Merchant IDs, then pressing Continue/Save/Confirm buttons - nothing happens, the "Save" button text briefly changes to "Processing" and then back To "Save" and we still have previously enabled Merchant IDs and the Save button is still in enabled state, any help?

Hi, I set up a Sandbox Tester account in my company’s Apple Developer Program and signed in on my iPhone under Settings → App Store → Sandbox Account. When I go to Wallet → Add, I only see options for Credit or Debit Card or Travel Card. The option to add an Apple Pay Sandbox Card is missing, and when I try entering the test card numbers from Apple’s documentation (developer.apple.com/apple-pay/sandbox-testing), the card is not valid. Has anyone experienced this and found a solution? Thanks! PS: I can't post this to Wallet Category, I keep getting error that it contains sensitive text.

We are working with a large fintech org on project connected with provisioning payment cards to Apple Wallet. When we add a previously provisioned card to the Wallet (using the Wallet UI, Add card -> Previous card). It adds the card on one device showing the Express Travel card screen after the card is added allowing the user to set the card as an express travel card during the provisioning flow but never on our other devices. All of the test devices are clean and have only the same single card provisioned. What triggers the Express Travel Card screen to be shown during the add previous card flow? (Why is it showing on one device and not another).