Hi, You're here because you've had issues with your implementation of Wallet 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 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

I've encountered an issue where we need multiple domain associations with separate Apple Pay implementations. Briefly, we have a /.well-known/apple-developer-merchantid-domain-association already setup with Stripe, and now we need another, different version of the file to get setup with FreedomPay. FreedomPay insists this file represents a three-way relationship between all parties and I have no reason to disbelieve them. I'm wondering if anyone has encountered this or if there is a standard procedure. I'm currently trying to find documentation on the exact way Apple Pay verification interacts with this file to see if we can produce it dynamically.

Does anyone know how to register as a psp for apple pay. My psp is based in the UAE and I cant seem to find an easy way to enroll the psp to apple pay

Hello all, I’m helping a customer integrate Apple Pay, and I’m seeing a behavior I can’t fully explain. I hope someone here can help clarify whether this is expected or whether it’s a bug / misconfiguration on my side. Currency: RSD (Serbian Dinar) Amount: 3.45 RSD (two decimals) Result: Apple Pay cancels the payment automatically when the amount includes decimals, without even displaying the paymentsheet. Things I have checked: ISO 4217 defines RSD with 2 minor units, so fractional amounts like 3.45 should be valid. Processors treat RSD as a two-decimal currency. Apple’s documentation does not provide a per-currency decimal rule table. In testing, whole-number RSD amounts succeed, while fractional amounts (e.g. 3.45 RSD) fail. I did not encounter this problem with other currencies like EUR, USD. Has anyone encountered this issue before?

We are having trouble trying to renew our Apple Pay Merchant Identity Certificate. We can create the CSR file and add to the developer portal. We then convert this to a .pem and then a .p12. When we test the certificate in Postman however, we see the following error: "statusMessage": "Payment Services Exception pspId=xxxx unauthorized to process transactions on behalf of merchantId=xxxx reason=xxxx is not a registered merchant in WWDR and isn't properly authorized via Mass Enablement, either.", "statusCode": "417" We are sending the following POST request to 'https://apple-pay-gateway.apple.com/paymentservices/paymentSession': {"merchantIdentifier": "merchant.com.xxxx.applepaytest", "domainName": "beta-xxxx.com", "displayName": "beta-xxxx.com"} Anyone got any ideas what the issue may be? In the meantime I will look at completing our domain verification as that is also due soon and we thought it may possibly have something to do with the certificate issues we are seeing.

'Company A' is scheduled to merge with its parent company, 'Company B'. Both A and B have Apple accounts. A's account has one domain registered for Apple Pay integration, while Account B has no domain registered. We attempted to register A’s domain under B’s account. However, the notification 'Requested domain name has been verified previously.' appeared, and we could not complete the registration. Please confirm whether it is correct that a domain already registered under Account A cannot be registered again under Account B. If we cannot register same domain in two accounts, we believe that the domain registered under A's account must be deleted first and then registered under B's account. In that case, will payments become unavailable immediately upon deletion of the domain, or will payments still be possible for a certain period of time after deletion? In our testing, we found that payments were not blocked immediately, but we would like to confirm further. We are concerned about the possibility of transaction failures during the short period between deleting the domain from A's Account and registering it under B's Account.

Hi Everyone, My team is working on an online marketplace for FMBs in Saudi Arabia (with a plan to expand to other markets later). We are currently working on integrating multiple payment gateways with embedded Apple Pay support into our platform. We’ve encountered an issue with the apple-developer-merchantid-domain-association file. Based on advice from one of our payment partners, we've ensured that the domain association file is uploaded in the correct format. This works successfully with our first payment gateway. However, for the additional payment gateways we are integrating, we would also like to enable Apple Pay with embedded support. The challenge is that each payment gateway requires its own domain verification, but the verification file uses the same file name. This prevents us from supporting multiple gateways on the same domain. Has anyone in the house been able to implement a similar solution, or know how we can best implement this? Please, I'll appreciate advise on how we can configure Apple Pay domain verification to support multiple payment gateways on the same domain? Any specific guidance or best practices would be greatly appreciated. Best regards,

Hello everyone. I encountered a problem when integrating Apple Pay. I obtained all the renewal orders through the Apple interface, and their purchaseDate is 8 hours later than the actual payment time. Why is this happening? According to the documentation, the purchaseDate value provided by Apple is a millisecond timestamp that represents the actual payment time of the user, so theoretically there shouldn’t be any timezone issues. This works well in client-initiated subscriptions, but in renewal scenarios, the purchaseDate becomes unreliable. Could this be due to some configuration in the configuration center? For example, I actually received an Apple notification at 1746686911000 (2025-05-08 06:48:31 Etc/GMT). However, the data returned by the Apple interface is as shown below: { "appAccountToken": "xxxx", "bundleId": "xxxx", "currency": "GBP", "environment": "Production", "expiresDate": 1762616831000, "inAppOwnershipType": "PURCHASED", "isUpgraded": false, "offerDiscountType": "", "offerIdentifier": "", "offerType": 0, "originalPurchaseDate": 1746456432000, "originalTransactionId": "320002311698411", "price": 39990, "productId": "xxxx", "purchaseDate": 1746715631000, "quantity": 1, "revocationDate": 0, "revocationReason": 0, "signedDate": 1746687092825, "storefront": "GBR", "storefrontId": "xxxx", "subscriptionGroupIdentifier": "xxxx", "transactionId": "320002315815857", "transactionReason": "RENEWAL", "type": "Auto-Renewable Subscription", "webOrderLineItemId": "320001062124562" } You can see that the purchaseDate is 1746715631000 (2025-05-08 14:48:31 Etc/GMT), which is even later than the current time. Can someone explain this behavior that is inconsistent with the documentation, or did I do something wrong? I would be very grateful for any help anyone can provide.

We rely on ApplePaySession.applePayCapabilities() to decide whether to show the Apple Pay button. We use two different merchant IDs for non-prod/prod environments, and encountered a change in behavior where this API now returns different results. These merchant IDs are generated from a third-party provider Adyen. However, Adyen has informed us that they are unable to identify the root cause of the issue and advised us to seek assistance directly from Apple Pay support. Timeline Last known working date: 13/08/2025 Issue first noticed: 18/08/2025 Environment Details Apple Pay JS API version 1.latest Browsers Tested: Third party browsers including Chrome/139.0.0.0, Firefox/141.0 Browsers with ApplePaySession built-in (like iOS Chrome, iOS Safari, and macOS Safari) are working fine Framework Stack: Angular v18.1.3 (important) no configuration setup in Apple dev account, merchantId is generated from a third-party provider Adyen. Current Execution Flow: Apple Pay JS API script element is injected <script type="text/javascript" async="" src="https://applepay.cdn-apple.com/jsapi/1.latest/apple-pay-sdk.js"></script> Triggers below to check apple pay readiness, different ${merchantId_credential} is used: await window.ApplePaySession.applePayCapabilities(`${merchantId_credential}`); (**ApplePaySession is a valid object at this point) Observed that different paymentCredentialStatus is returned // nonprod env { "paymentCredentialStatus": "applePayUnsupported" // unexpected } // prod env { "paymentCredentialStatus": "paymentCredentialStatusUnknown" } The same code is executed in each environment and the behaviour was also the same, but has changed since then. Side notes By checking the SDK’s internal code, we saw that in third-party browsers it makes an extra call to the following endpoint. Responses from this call also come back differently depending on the merchantId. When invoking below: curl -X POST \ https://smp-paymentservices.apple.com/paymentservices/v3/checkStatus/merchant/{merchantId} \ -H 'Content-Type: application/json' \ -d '{ "initiative": "web", "initiativeContext": "env_specific_domain" }' Our non-prod environment returns {"registered":false} while using prod's merchantId and domain it returns {"registered":true}. We thought the issue might be domain-related since the environments are on different domains, but so far, no luck. The main questions we're looking to resolve are: Why did the behavior change at a certain point despite no code changes? How should we approach this investigation, and what specific requests should we be making to the Adyen team? Why does the response from the call to https://smp-paymentservices.apple.com/paymentservices/v3/checkStatus/merchant/{merchantId} return different results? Perhaps this could provide a clue regarding the question above? We noticed that canMakePayments() is returning true, so we could consider using that as a workaround. Would it be safe to change the source of truth relying on canMakePayments() for displaying Apple Pay? There is a concern that this issue may also occur in our production environment, so we would appreciate assistance in understanding what is happening and finding a resolution.

Hi , This is regarding the ApplePayRecurringPayment Request and Apple Pay on Web functionality. Does Apple Pay on web providing functionality that collects payments from the stored credit card issuer bank (or) it only provides secured wallet functionality that provides a token which then has to be utilized to send a seperate payment request through a third party payment gateway to collect the payments from the credit card issuer bank. thanks

Hi, we are implementing ID&V and there is a requirement regarding the flow for Apple Pay. In order to clarify the case I will describe the use case scenario or steps to reproduce first: add a card to the iPhone wallet app (yellow path verification required). Do not complete the ID&V process. add a card to the Watch via the Wallet inside the iPhone Watch app (yellow path verification required). Same as before, do not complete the ID&V complete ID&V process using the Issuer App either from iPhone or Watch. the Issuer app receives the application:openURL:options: callback on its AppDelegate. In the options dictionary, we can not see the UIApplicationOpenURLOptionsSourceApplicationKey populated (it is nil). At this moment, for the card we are adding there are now two tokens, both to be verified via ID&V process. One is on the iPhone and one is on the Apple Watch associated with the same iPhone. The url received at step 4 contains the serial number which identifies the digitized card and matches with both the tokens in the iPhone and in the Apple Watch. We need something to detect programmatically if the digitization process started from the iPhone Wallet app or from the wallet inside the Watch app. Could you please help us to identify how we could discriminate if the ID&V process has been started for the iPhone token or for the Apple Watch token? Thanks

I am working on implementing merchant token notifications. When calling this endpoint https://developer.apple.com/documentation/merchanttokennotificationservices/merchant-token-event-retrieval, the result contains a CardMetadata object with an expirationDate field (see https://developer.apple.com/documentation/merchanttokennotificationservices/cardmetadata). What is the format of this field? The spec only mentions that it has a maximum length of 8 characters.

Hello. we are looking in adding an additional verification method as part of our in app provisioning to apple wallet. the method is called app to app verification method where basically when the customer adds their card (debit or credit) on apple wallet they can be verified through a third party app. does apple support this? where can i find any material related to this?

Hey, Please help us to know how to get our payments of sales with iOS app we have, since beginning, our amount is pending with them and despite sevarel attempts they are providing the real issue and solutions for matter. Please suggest how to fix this issue.

Hi, We have app in which we take donations from people and send to non-profit organisations. I have read that Apple Pay can be integrated on non profit platforms to take donations, but we are middle man, we are not non profit .. we take donations, cut our platform fees and then sent to donations to non profit orgs. My question is can we integrate Apple Pay in our iOS app to take donations from apple? as we have integrated Apple Pay on the web.

Hey everyone, hoping someone here has run into this before. I have a fully functional App Clip (com.didyoucatchit.app.Clip) linked to my main app (com.didyoucatchit.app). The Clip builds and runs perfectly, but I’m seeing issues trying to enable Apple Pay for it. When I try to link my Merchant ID under the “On Demand Install Capable” capability in the Apple Developer portal, I get this error: A relationship in the provided entity is not allowed for this request. The relationship 'undefined' can not be included in a 'bundleIdCapabilities' request. Here’s what I have already configured and confirmed: App Clip capabilities in Xcode include: Apple Pay Payment Processing Associated Domains (appclips:app.didyoucatchit.com) Provisioning profile includes: Apple Pay Payment Processing Associated Domains In-App Purchase On-Demand Install Capable Entitlements file for the Clip: <key>com.apple.developer.associated-domains</key> <array> <string>appclips:app.didyoucatchit.com</string> </array> <key>com.apple.developer.in-app-payments</key> <array> <string>merchant.com.didyoucatchit.app</string> </array> <key>com.apple.developer.parent-application-identifiers</key> <array> <string>$(AppIdentifierPrefix)com.didyoucatchit.app</string> </array> Merchant ID (merchant.com.didyoucatchit.app) is active and connected to Stripe Stripe Apple Pay configuration matches the same merchant ID and certificate Both provisioning profiles have been refreshed and downloaded However: The portal still throws the “relationship 'undefined'” error anytime I try to modify the Clip’s capabilities In testing, Apple Pay doesn’t show up as a payment option in the Clip (using Stripe’s Payment Element integration) Questions: Is this a known issue with the Developer portal when linking App Clips to merchant IDs? Is there a specific way to re-establish the parent–child relationship between the main app and the App Clip so the bundleIdCapabilities request includes the proper relationship JSON? Are there any additional configuration steps required when using Stripe for Apple Pay inside an App Clip? System Setup: Xcode: 16.2 (build 16C5032a) macOS: Sequoia 15.3.1 iOS: 18.5 (testing on physical device) Merchant ID: merchant.com.didyoucatchit.app Main App ID: com.didyoucatchit.app App Clip ID: com.didyoucatchit.app.Clip Any help or insight would be hugely appreciated Thanks in advance!

Hi Team, For last 24 hours one of our team members is unable to login to apple dev portal due to two factor authentication not being sent. Error we are getting is "Verification codes can't be sent to this phone number at this time. Please try again later"

Description: I’m integrating Apple Pay JS (version 3) into an Angular application. Here are the key details: Environment: Angular (latest) Apple Pay JS v3 Chrome (confirmed window.ApplePaySession is available) application region is in US. I'm in Taiwan and using my iPhone Taiwan account to scan the QR Code/ Implemented Handlers: onvalidatemerchant onpaymentmethodselected onpaymentauthorized oncancel Observed Behavior: When I click the Apple Pay button, the console logs: Failed to execute 'postMessage' on 'DOMWindow': The target origin provided ('https://applepay.cdn-apple.com') does not match the recipient window's origin ('https://{our-domain-name}') Despite this, the QR code still appears. Scanning the QR code with an iPhone 13 Pro running iOS 18.4.1 brings up the Apple Pay sheet with the correct amount, but payment never completes. In the browser, none of my Angular event handlers fire except oncancel. Questions: What causes the postMessage origin mismatch with Apple’s CDN frame, and how should my application handle it? Why doesn’t onpaymentauthorized ever fire, and how can I complete the payment flow so that session.completePayment() succeeds? Any guidance or sample code snippets for a proper merchant-validation and payment-completion sequence in this setup would be greatly appreciated. my code onApplePayButtonClicked() { if (!ApplePaySession) { console.error('[ApplePay] ApplePaySession is not supported'); return; } // Define ApplePayPaymentRequest const request : ApplePayJS.ApplePayPaymentRequest = { countryCode: this.currencyCode, currencyCode: Constants.CountryCodeUS, merchantCapabilities: this.merchantCapabilities, supportedNetworks: this.supportedNetworks, total: { label: this.label, type: "final" as ApplePayJS.ApplePayLineItemType, amount: this.orderAmount.toString(), }, }; // Create ApplePaySession const session = new ApplePaySession(3, request); session.onvalidatemerchant = async event => { console.info('[ApplePay] onvalidatemerchant', event); try { const merchantSession = await fetch(`${this.paymentUrl}/api/applepay/validatemerchant`, { method: 'POST', headers: { 'Content-Type': 'application/json', }, body: JSON.stringify({ PKeyCompany: this.paymentAppleMerchantId, ValidationUrl: event.validationURL }) }).then((r) => r.json()); session.completeMerchantValidation(merchantSession); } catch (error) { console.error('[ApplePay] onvalidatemerchant MerchantValidation error', error); session.abort(); } }; session.onpaymentauthorized = (event) => { console.info('[ApplePay] paymentauthorized', event); const token = event.payment.token; this.paymentTokenEmitted.emit({ token: JSON.stringify(token), paymentType: PaymentOptionType.ApplePay }); session.completePayment(ApplePaySession.STATUS_SUCCESS); }; session.onpaymentmethodselected = (event) => { console.info('[ApplePay] paymentmethodselected', event); const update: ApplePayJS.ApplePayPaymentMethodUpdate = { newTotal: request.total }; session.completePaymentMethodSelection(update); }; session.oncancel = (event) => { console.error('[ApplePay] oncancel', event); this.errorEmitted.emit({ error: 'Apple Pay cancel' }); }; session.begin(); }

Does anyone have info about the Retention Messaging API. We've requested access to it, but there's no answer.

We have finished integrating Apple Pay in our app and our payment processor is requiring us to send the 3dSecure version used for apple pay (2.1,2.2,2.3,etc.). I believe this only applies to mastercard but would appreciate if anyone has run into something similar and what you specified. I have not been able to find anything in Apple's documentation specifying the version that is used.

We’re building a usage-based rental flow. The final charge is only known after the session ends (like gas pumps). We want the same Apple Pay UX that gas stations like at a gas station has: the user does not see a pre-authorization amount up front; they only see “approved” and later the final posted amount on the statement. What we observe (gas stations / desired UX) When paying at gas station with Apple Pay (card-present), the user confirms their card (double-tap) but no pre-auth amount is shown in Wallet/notification UI. The small notification is from the bank (not the merchant) and shows only bank + merchant name, no total. After fueling ends, the final amount appears on the statement from the merchant. What happens in our flow (current behavior) Platform: Apple Pay via Stripe (Apple Pay on the Web with QR → mobile Safari Wallet sheet). When a user confirms payment, the pre-authorization amount is shown immediately to the user (appears like a charge from the user’s perspective). We want to avoid showing that amount, matching the pay-at-pump experience.