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

iOS 16 and earlier On iOS 16 and earlier, Apple Pay on the Web required Safari—and all interactions with the Apple Pay API to come from the parent/top level page. In order to facilitate the Apple Pay button in an HTML inline frame (iframe), there will need to be cross frame communication between the child and parent pages. Cross frame communication should be secure and robust, therefore the use of postMessage for this purpose is recommended. The expectation is for all communication with Apple Pay to occur from the parent page, so the iframe must relay all Apple Pay related events to the parent to handle. Some examples: Apple Pay availability: The parent calls applePayCapabilities, then sends the message of the response to the iframe, which then uses the value to toggle the visibility of the Apple Pay button. Apple Pay session: The iframe receives an onclick() event when the Apple Pay button is clicked and sends the message to the parent (providing details about the transaction). The parent create the payment request to obtain the session validation URL, and eventually receive session credentials and invokes completeMerchantValidation() to prevent the payment sheet. After the payment is authorized by the Payment Service Provider (PSP), the parent either: Redirects the parent page to a payment success page; or Sends a message to the iframe to complete the transaction flow itself. iOS 17 and later On IOS 17 and later, the iframe HTML element should include the allow="payment" attribute, which should facilitate the cross frame communications instead of needing a dedicated JavaScript library. This means all of the Apple Pay code/calls can reside in the iframe page—which is typically a hosted page from a Payment Service Provider (PSP), all the parent page—typically a merchant—has to do is add the attribute mentioned above to the iframe element. Important: Regardless of the iOS version, the PSP/merchant always needs to make sure the parent page domain is the one registered in the Developer portal, and used in the request to generate a merchant session via ApplePaySession. Cheers, Paris X Pinkney |  WWDR | DTS Engineer

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?

We are an acquirer/payment provider offering Apple Pay. Our merchants use our hosted checkout to accept payments. After a user pays with Apple Pay on our checkout, the Wallet transaction record shows our checkout domain as the payee. We would like it to display the merchant’s brand/name so users can recognize or contact the merchant. Is there any parameter or configuration that controls what Wallet shows as the payee? For example, can this be set via a specific field/parameter, or is it strictly derived from the Merchant ID’s display name (or other Apple Pay configuration)? What is the correct approach for a PSP/acquirer to have the merchant’s brand shown in Wallet transaction record? Additional detail: The field in question is the merchant/payee name shown in the Apple Wallet receipt—directly under the transaction amount at the top of the receipt, and again beneath the “Total” line.

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)

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)

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)

Hello, I', are trying to add applepay payment on our website using the PSP payxpert. They don't provide any SDK to my knowledge unlike paypal/stripe and their documentation just tell to send a few different data as usual credit card payment. But I'm stuck even before that step, we were able to add the applepay button on the site, we did setup the sandbox account on the iPhone with a test card. We could add the merchant id, created the "Apple Pay Payment Processing Certificate", the "Apple Pay Merchant Identity Certificate" and we verified the marchant domain. We have our backend request the validationURL on onvalidatemerchant. We're using PHP, and send the data in json as the example in: https://developer.apple.com/documentation/ApplePayontheWeb/requesting-an-apple-pay-payment-session The validation url we receive from applepaysession js is: https://apple-pay-gateway-cert.apple.com/paymentservices/startSession The doc mentions to add /paymentSession so I tried that as well as just the raw validationURL. Both sends me a 401 Unauthorized response. I'm not sure what missing, I double checked the merchantIdentifier matches and that the initiativeContext is correct, but no luck. I wonder if we missed a step in the configuring the server, as it say to create certificate and upload them. Then we can download the .cer files, do we need to do something with that? Kind regards

Hi! We recently signed up and activated the Web Merchant Registration API and registered a few of our merchants. We registered them as: { "domainNames" : ["X"], "partnerMerchantName" : "Name", "partnerInternalMerchantIdentifier": "MID-###", "encryptTo" : "platformintegrator.X", "merchantUrl": "https://www.x" } When we make the payment with startsession, we are getting an error 400: Payment Services Exception merchantId=platformintegrator.x not registered for domain=x I suspect that this has to do with the value of merchantIdentifier we are setting in the startsession. What should it be? MID-###? The encryptTo hash of platform? platformintegrator.x? Also, what's the meaning of the property on the sub-merchant I get from the GET API call delegatedCommerce: {enabled=True}?

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)

Hello, We are implementing support for Merchant Initiated Transactions (MIT) classified as Unscheduled Card-on-File (UCOF). Could you please clarify which request object(s) and mandatory field(s) should be provided during the initial Customer Initiated Transaction (CIT) to correctly support future MIT UCOF transactions and mandatory fields also for subsequent UCOF transactions? If ApplePayRecurringPaymentRequest / RecurringTransactionInfo should be used for this scenario, could you please specify how these objects should be populated for UCOF, including the expected values of all mandatory fields? If a different request object or approach is required for UCOF, could you please provide the recommended implementation or reference documentation? Best regards,

Our client's site uses Apple Pay, and once a month we get a series of email notifying us that the domain verification is about to expire: Your website domain that uses Apple Pay has an SSL Certificate that expires on Oct 11, 2020. We were unable to automatically to reverify your domain. To ensure uninterrupted use of Apple Pay on your website, revalidate your domain by Oct 11, 2020 in Certificates, Identifiers & Profiles. The site uses Let's Encrypt to automatically renew its SSL cert monthly. Every time that happens, we need to log into the Apple Developer tools, navigate to Certificates, Identifiers, and Profiles -> Identifiers -> Merchant IDs -> ID -> Merchant Domains, then download the file and drop it onto the server with SFTP. It's a pain. Is there a way to automate this process (or better yet, stop it from happening)? I can't imagine monthly-renewing SSL certificates is a particularly uncommon thing.

Hi everyone, We are integrating Apple Pay on the Web, and we're trying to get the automatic renewal of the domain verification working according to the documentation: https://developer.apple.com/documentation/apple_pay_on_the_web/maintaining_your_environment Initially the domain verification is successful, but then the automatic renewal does not work. We keep getting the emails with the subject "Your domain will expire soon.", but they only say "We were unable to automatically to reverify your domain." without any further details. We confirmed that the site's SSL certificate has already been renewed by the time Apple attempted the renewal of verification, the certs are renewed 30 days before their expiry (using Let's Encrypt). So according to the docs, at least the renewal attempts 15, and then 7 days before the expiry should be successful. One example domain is this one: https://www.kayak.com/.well-known/apple-developer-merchantid-domain-association.txt, but we have the same issue for all our other domains as well. Does anyone have suggestions how to troubleshoot this further? (I tried creating a support ticket, but they basically replied that they're non-technical, and just linked me to the documentation. I've seen others complaining about this too, but couldn't find a conclusive solution, so I thought I'd signal boost and create a fresh topic to see if there are any more recent findings about this problem.) Thanks! Regards, Mark