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

Bank Accounts details are outdated and status is stack on processing with error: "Your banking updates are processing, and you should see the changes in 24 hours. You won't be able to make any additional updates until then." This is now stack for a few years since we activated a previous Apple developer account. we must change banking details as it holds up development of an app with in-app purchases. Finance department has been contacted and they do not answer What shall we do? senior support staff keep referring to finance department and is not helping

We have an Apple Pay account and have successfully created and verified the payment processing certificate in our Apple Developer account. When initiating an Apple Pay payment, the Apple session is created successfully with the correct data return from api , but it is not accepted with the error: “Payment not completed.” The issue occurs even though the merchant validation step works without errors. Our websites where this is happening are: https://magicdeliver.com/ https://www.pulsarmodular.com/ Could you please help us identify the cause of the issue and guide us on resolving it?

Hi, We are trying to make the PKAddPaymentPassViewController to show the correct list of devices to where the pass can be added. We have analysed the documentation and we are using the PrimaryAccountIdentifier field which is the field that supposedly controls this behavior but the list of devices presented in the view controller always include one iPhone and one Apple Watch, regardless of where the card has been already added. We are initializing the PKAddPaymentPassRequestConfiguration object with: PKEncryptionScheme PrimaryAccountIdentifier CardholderName PrimaryAccountSuffix LocalizedDescription PaymentNetwork PrimaryAccountIdentifier CardholderName PrimaryAccountSuffix LocalizedDescription We have also verified the configuration in our payment pass processor and everything should be ok. We would like to have some help on achieving the desired flow for Apple Pay, which is to present the PKAddPaymentPassViewController with the correct list of available devices and not the full list. Thank you.

We are working with two types of wallet passes. Provisioning works successfully for one pass type via wallet extensions, but the same process is not functioning for the other. For the second pass type, we are able to generate the required data for pull provisioning and send it to Apple. Additionally, in-app push provisioning for this pass type completes without issue. We would appreciate guidance on how to further debug and resolve this provisioning problem.

When accessing https://applepaydemo.apple.com/payment-request-api, the "Approve with Side Button" prompt is displayed, but it does not appear when using our test domain. I implemented the Payment Request API based on the sample source code from the following URL. On an iPhone device, the Apple Pay payment screen is displayed, but the "Approve with Side Button" icon below the amount does not appear, and instead a spinning loading icon is shown continuously. Could you please help identify the cause? ■ Reference URL: https://applepaydemo.apple.com/payment-request-api ■ Changed parameter: "merchantIdentifier": "〇〇.dev" ■ Accessed domain: 〇〇test.com ■ Test device: iPhone 13 iOS: 18.4.1

Hi, We're experiencing an issue with verifying our domain for Apple Pay on the web. It's currently stuck in the "Pending" state despite meeting the listed requirements. The domain in question has been verified once successfully but one month later when we renewed the SSL, we were unable to verify the domain again. Please note that the new certificate's CA chain has been changed. A) The "apple-developer-merchantid-domain-association.txt" file is publicly accessible at the following location: /.well-known/apple-developer-merchantid-domain-association.txt B) We've also ensured that the following IP ranges are whitelisted: 17.32.139.128/27 17.32.139.160/27 17.140.126.0/27 17.140.126.32/27 17.179.144.128/27 17.179.144.160/27 17.179.144.192/27 17.179.144.224/27 17.253.0.0/16 17.23.4.96/27 17.132.108.64/26 17.23.24.32/27 17.23.19.0/27 17.157.40.128/27 17.157.44.128/27 17.157.32.0/27 C) Our servers support TLS 1.2 already. D) "ECDHE-RSA-AES128-GCM-SHA256" cipher suite has been used, so we believe all necessary criteria are satisfied. However, when we attempt to verify the domain, we receive the following error message: "Domain verification failed. Review your TLS Certificate configuration to confirm that the certificate is accessible and a supported TLS Cipher Suite is used." Could you please advise why the verification is failing, or let us know if there's anything we might have missed? Best regards, Mehdi

Hi, Somebody knows how to decode / decrypt emvData on Apple Pay e-commerce when paymentDataType=EMV? Thanks. Reference: https://aninterestingwebsite.com/documentation/passkit/payment-token-format-reference#Detailed-payment-data-keys-EMV

I'm successfully using Apple subscriptions in my app, but I'm encountering SKErrorCodeDomain error 18 when trying to apply a subscription offer. I want apply offer code first time only for subscription. Below are details of what i set in appstore and what i have tested. Subscription Offer Details Offer Type: For the first month Customer Eligibility: New, Existing, and Expired Subscribers Code Status: Active Offer Code Creation Steps: App Store Connect → App → Subscription → Select Subscription Product → Offer Codes → Add → Add Custom Codes Signature Generation for Promotional Offers I'm following Apple's documentation to generate a signature: https://aninterestingwebsite.com/documentation/storekit/generating-a-signature-for-promotional-offers I’ve constructed the payload as instructed: appBundleId + '\u2063' + keyIdentifier + '\u2063' + productIdentifier + '\u2063' + offerIdentifier + '\u2063' + appAccountToken + '\u2063' + nonce + '\u2063' + timestamp Keys and Identifiers keyIdentifier, issuerId, and .p8 file are obtained from: App Store Connect → Users and Access → Integrations → In-App Purchase Test user created under: App Store Connect → Users and Access → Sandbox → Test Accounts Logged in with this account on the iPhone What I’ve Tried Verified all values used in the payload are correct Tried both seconds and milliseconds for the timestamp (as per documentation, it should be in milliseconds) Tried setting appAccountToken to: a valid UUID an empty string not setting it at all Used Apple’s sample code to generate a signature: https://aninterestingwebsite.com/documentation/storekit/generating-a-promotional-offer-signature-on-the-server Verified the generated signature locally, and it validated successfully: https://aninterestingwebsite.com/documentation/storekit/generating-a-signature-for-promotional-offers#Validate-locally-and-encode-the-signature Apple’s sample code to generate a signature Downloaded from const express = require('express'); const router = express.Router(); const crypto = require('crypto'); const ECKey = require('ec-key'); const secp256k1 = require('secp256k1'); const uuidv4 = require('uuid/v4'); const KeyEncoder = require('key-encoder'); const keyEncoder = new KeyEncoder('secp256k1'); const fs = require('fs'); function getKeyID() { return "KEYIDXXXXX"; } router.post('/offer', function(req, res) { const appBundleID = req.body.appBundleID; const productIdentifier = req.body.productIdentifier; const subscriptionOfferID = req.body.offerID; const applicationUsername = req.body.applicationUsername; const nonce = uuidv4(); const currentDate = new Date(); const timestamp = currentDate.getTime(); const keyID = getKeyID(); const payload = appBundleID + '\u2063' + keyID + '\u2063' + productIdentifier + '\u2063' + subscriptionOfferID + '\u2063' + applicationUsername + '\u2063'+ nonce + '\u2063' + timestamp; // Get the PEM-formatted private key string associated with the Key ID. // const keyString = getKeyStringForID(keyID); // Read the .p8 file const keyString = fs.readFileSync('./SubscriptionKey_47J5826J8W.p8', 'utf8'); // Create an Elliptic Curve Digital Signature Algorithm (ECDSA) object using the private key. const key = new ECKey(keyString, 'pem'); // Set up the cryptographic format used to sign the key with the SHA-256 hashing algorithm. const cryptoSign = key.createSign('SHA256'); // Add the payload string to sign. cryptoSign.update(payload); /* The Node.js crypto library creates a DER-formatted binary value signature, and then base-64 encodes it to create the string that you will use in StoreKit. */ const signature = cryptoSign.sign('base64'); /* Check that the signature passes verification by using the ec-key library. The verification process is similar to creating the signature, except it uses 'createVerify' instead of 'createSign', and after updating it with the payload, it uses `verify` to pass in the signature and encoding, instead of `sign` to get the signature. This step is not required, but it's useful to check when implementing your signature code. This helps debug issues with signing before sending transactions to Apple. If verification succeeds, the next recommended testing step is attempting a purchase in the Sandbox environment. */ const verificationResult = key.createVerify('SHA256').update(payload).verify(signature, 'base64'); console.log("Verification result: " + verificationResult) // Send the response. res.setHeader('Content-Type', 'application/json'); res.json({ 'keyID': keyID, 'nonce': nonce, 'timestamp': timestamp, 'signature': signature }); }); module.exports = router; Postman request and response Request URL: http://192.168.1.141:3004/offer Request JSON: { "appBundleID":"com.app.bundleid", "productIdentifier":"subscription.product.id", "offerID":"OFFERCODE1", "applicationUsername":"01234b43791ea309a1c3003412bcdaaa09d39a615c379cc246f5f479760629a1" } Response JSON: { "keyID": "KEYIDXXXXX", "nonce": "f98f2cda-c7a6-492f-9f92-e24a6122c0c9", "timestamp": 1753510571664, "signature": "MEYCIQCnA8UGWhTiCF+F6S55Zl6hpjnm7SC3aAgvmTBmQDnsAgIhAP6xIeRuREyxxx69Ve/qjnONq7pF1cK8TDn82fyePcqz" } Xcode Code func buy(_ product: SKProduct) { let discountOffer = SKPaymentDiscount( identifier: "OFFERCODE1", keyIdentifier: "KEYIDXXXXX", nonce: UUID(uuidString: "f98f2cda-c7a6-492f-9f92-e24a6122c0c9")!, signature: "MEYCIQCnA8UGWhTiCF+F6S55Zl6hpjnm7SC3aAgvmTBmQDnsAgIhAP6xIeRuREyxxx69Ve/qjnONq7pF1cK8TDn82fyePcqz", timestamp: 1753510571664) let payment = SKMutablePayment(product: product) payment.applicationUsername = "01234b43791ea309a1c3003412bcdaaa09d39a615c379cc246f5f479760629a1" payment.paymentDiscount = discountOffer SKPaymentQueue.default().add(payment) } Issue Even following instructions to the documentation and attempting various combinations, the offer keeps failing with SKErrorCodeDomain error 18. Has anyone else experienced this? Any suggestions as to what may be amiss or how it can be corrected?

Hello Apple Devs, We’re currently trying to integrate Apple Pay on the web using Apple Pay JS. We've followed the official documentation closely, but we're running into a blocker during the merchantSession validation phase. We successfully retrieved a merchantSession, which looks like this: json { "displayName": "Our Name", "domainName": "https://pay.ourdomain.co", "epochTimestamp": , "expiresAt": ****************, "merchantIdentifier": "", "merchantSessionIdentifier": ", "nonce": "", "operationalAnalyticsIdentifier": our name "t:", "pspId": "", "retries": 0, "signature": "*****************..." } Issue: Shortly after initiating the session, we receive a cancel event with the following info: ApplePayCancelEvent { type: "cancel", sessionError: { code: "unknown", info: {} } } We're unsure what causes the cancellation. There are no clear error messages or hints in the logs to identify what went wrong. What We’ve Checked: The merchantSession is returned successfully from our backend. The domainName matches our frontend domain (https://pay.durdomain.co). The session hasn’t expired when tested. We're using Apple Pay JS APIs as described in the documentation. Help Needed: What can trigger an ApplePayCancelEvent with an "unknown" error code? Any insight or guidance would be deeply appreciated. Thanks in advance!

During the in‑app provisioning flow, we successfully obtain the provisioning certificates and generate object for posting. However, in the production environment the flow fails when posted to a broker. broker/v4/devices/{SEID}/cards The staging environment works correctly and provisioning completes without issues. Object {encryptedCardData, activationData, ephemeralPublicKey} is build. The T&C screen never appears. FB22332303

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

We have used the ApplePayRecurringRequest parameter required for Apple Pay subscriptions, but during testing the payment, the Apple Pay payment page shown to the user remains the same as the one-time payment page, without any subscription information. Could you please check if there is an issue with our parameters or if there is an issue with the merchantIdentifier being used? Here is the ApplePayRequestData that we are using. { "supportedMethods": "https://apple.com/apple-pay", "data": { "version": 3, "merchantIdentifier": "***", "merchantCapabilities": [ "supports3DS", "supportsCredit", "supportsDebit" ], "supportedNetworks": [ "visa", "masterCard" ], "countryCode": "US", "recurringPaymentRequest": { "paymentDescription": "A description of the recurring payment to display to the user in the payment sheet.", "regularBilling": { "label": "Recurring", "amount": "4.99", "paymentTiming": "recurring", "recurringPaymentStartDate": "2025-06-02T16:00:00.000Z" }, "trialBilling": { "label": "7 Day Trial", "amount": "0.00", "paymentTiming": "recurring", "recurringPaymentEndDate": "2025-06-02T16:00:00.000Z" }, "billingAgreement": "A localized billing agreement displayed to the user in the payment sheet prior to the payment authorization.", "managementURL": "https://applepaydemo.apple.com", "tokenNotificationURL": "https://applepaydemo.apple.com" }, "additionalLineItems": [ { "label": "7 Day Trial", "amount": "0.00", "paymentTiming": "recurring", "recurringPaymentEndDate": "2025-06-02T16:00:00.000Z" }, { "label": "Recurring", "amount": "4.99", "paymentTiming": "recurring", "recurringPaymentStartDate": "2025-06-02T16:00:00.000Z" } ] }

We have verified our domain but if the file is removed from the deployed site after verification will this impact using ApplePaySession.applePayCapabilities in real time? We use that method from the JS api in our React app to determine whether or not to show the apple pay button. When that function is called in the browser, do the apple servers ping the https://our.domain.com/.well-known/apple-developer-merchantid-domain-association URL at that time? Or do they check for it periodically? The reason for asking is that with our many environments we wonder if we can verify each environment's domain by adding the file once. The file will be wiped out by our CICD process as it goes up the environment stack through our development workflow. Or do we need to maintain that file for each environment and add something to our build process?

Cybersource production support has clarified issue as below "On the BAD Case, it seems that the Apple Payload did not contain the "onlinePaymentCryptogram" object within the JSON. The Cryptogram is critical and mandatory. Since the merchant cannot really control this, and since CYBS is just decrypting the payload and uses it, we cannot comment as to why it was missing. The merchant would need to reach out to Apple and/or decrypt the payment themselves locally to check if and why this data was not present, for troubleshooting purposes."

There's a purchase I make pretty often on a particular site and I'm trying to automate the boring parts with a macOS app. I can pull the merchant session from their ValidateMerchant endpoint. I can see the Apple Pay dialogue appear, then it will disappear with "Payment Not Completed." Is it fundamentally not possible to use someone else's merchant session in your own app? Thanks

During checkout at apple.com using a non-supported Apple Pay on the Web browser, apple.com presents a QR like code offering to "Scan Code with iPhone" to pay. The payment continues using Apple Pay on the iPhone after scan. We already offer Apple Pay and Apple Pay on the Web. Is this QR code option available for us for non-supported browsers? Could you point me to the docs to add it? Thank you.

We are implementing Apple Pay In-App Provisioning in our issuer iOS application and are encountering a HTTP 500 error returned from Apple servers during the provisioning flow. The issue occurs after generating the encrypted payload and attempting to complete the provisioning process. The Apple service responds with 500 Internal Server Error, preventing the card from being added to Wallet. We would appreciate assistance identifying whether this is caused by: • a payload formatting issue, • cryptographic material mismatch, • entitlement / configuration issue, • or a server-side issue. Environment Platform • iOS: 26.3.1 • Device: iPhone 13 mini • Xcode: 26.3.1 Apple Pay configuration • In-App Provisioning entitlement enabled • Issuer app authorized by Apple for provisioning • Payment Network: Mastercard • Token Service Provider (TSP): MDES Testing environment • Production • App distribution method: TestFlight Provisioning Flow Overview Our implementation follows the standard Apple Pay In-App Provisioning flow: 1. User taps Add to Apple Wallet in issuer app. 2. App presents PKAddPaymentPassViewController. 3. App receives: • Apple public certificates • nonce • nonceSignature 4. Issuer backend generates: • encryptedPassData • activationData • ephemeralPublicKey 5. These values are returned to the app. 6. App constructs PKAddPaymentPassRequest. 7. Wallet attempts provisioning. At this point the request fails and Apple servers return HTTP 500. We see this in the system console, with the phone having Wallet debugging profile installed. Checklist – Common Issues Verified Based on the Apple Pay In-App Provisioning demo guidance, we verified the following configuration items. Entitlements • com.apple.developer.payment-pass-provisioning enabled • Apple Pay capability enabled in Xcode • Correct Team ID and bundle configuration App configuration • PKAddPaymentPassViewController used for provisioning • PKAddPaymentPassViewControllerDelegate implemented • generateRequestWithCertificateChain implemented correctly Cryptographic data • encryptedPassData • activationData • ephemeralPublicKey All values are generated by our issuer backend and returned to the app Feedback ID: FB22249031 (In app provisioning error 500)

Dears, We are developing an apple wallet extension. In the Non-ui extension, in the getPaymentPassEntry overriden function we have to return an object such as: ``PKIssuerProvisioningExtensionPaymentPassEntry(identifier: identifier, title: label, art: getEntryArt(image: uiImage), addRequestConfiguration: requestConfig)!`` What is not clear are the requirements for this "art" parameter. Somewhere in the FAQ it says that the art has to be an image of 1536 x 969 resolution, <4 MB, squared corners, no chip contacts, and so forth) but we set there images of any size and the extension displays them without any problem. Are those requirements (1536 x 969 resolution, and so on) only for the images that are displayed in the wallet only after the card has been added? In this case, are those images coming from the PNO directly and not coming from the function above which is in the wallet extension? Thanks,

I’m having an issue verifying a domain for a Merchant ID. I’m implementing Apple Pay on the web for a demo, and I’ve configured the Azure server to match Apple’s requirements for domain verification, such as the TLS configuration, not requiring client certificates, and ensuring there are no redirects. I’ve run tests with OpenSSL and PowerShell and all responses return HTTP/1.1 200 OK. I also tested the URL Apple says it uses to validate the file under .well-known, and it does show the expected result. I already have the Apple Pay Payment Processing Certificate and the Apple Pay Merchant Identity Certificate approved; the only thing missing is the domain verification. I’m not sure what else to test—if you could help me with a possible solution, I’d really appreciate it. (The project is built in .NET 8 and hosted on Azure App Service.)

We are developing an app which allows users to generate a HSBC virtual card using Mastercard API and add this card to an apple wallet. Staging test was passed successfully, but we are stuck in a production test phase. T&C is not even visible, 'Card is not added' is popped on a screen before that. User taps “Add to Apple Wallet” → we present PKAddPaymentPassViewController → they tap Next → after a few seconds the flow fails with "Set Up Later" alert. FB22332303 (MCDeanPortal app: In-App Provisioning Production Test fails) Thank you