Hello, I'm experiencing an irregular issue with Apple Pay merchant domain verification. As you know, Apple requires domain verification every two months to maintain Apple Pay functionality. The problem is that while the verification sometimes happens automatically without any issues, other times it fails to complete, even though the required file "apple-developer-merchantid-domain-association.txt" is correctly available on our server. When automatic verification fails, the Apple Pay service becomes non-functional on our website, forcing us to perform a manual verification to restore the pending service. Is it normal to encounter such inconsistent automatic verification processes? What could be causing these intermittent verification failures, whereas manual verification always succeed? suggesting this might not be related to IP address restrictions described on the Apple documentation. Thank you in advance,

Is there a way to allow ApplePay to make deferred payments to a suite of stores, or will each store need the user to initially approve a payment manually?

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, I am following up on my previous feedback (Feedback ID: FB17175593) regarding the in-app provisioning failure for Apple Pay. In that report, I detailed errors encountered during the card addition process (notably issues related to a missing teamID and cryptographic material errors). Could you please provide an update on the investigation progress? I appreciate your assistance and look forward to your response.

I am encountering an issue with the in-app provisioning flow using PKAddPaymentPassViewController. Specifically, when presenting the controller to allow users to add a pass to Apple Wallet, the device selection screen is showing all the devices, even after setting the primaryAccountIdentifier on the PKAddPaymentPassRequestConfiguration. Here's the context: I'm using PKAddPaymentPassViewController for in-app provisioning. I provide a valid primaryAccountIdentifier in the configuration. But after adding the pass, if i print back the primaryAccountIdentifier it displays some other value different than the identifier i had set(Example masked identifier: FAPLMC1GB000000066aa4xxxxxxxxxxxa744f16axxxxxxxx). The provisioning flow works, but the device list shown to the user includes all the devices (e.g., Apple Watches and iPhone even though it is already added to Apple Watch or iPhone).

Hello All - I'm attempting to enable my companies app to add credit card to Apple Wallet. Part of our app enables customers to generate new virtual cards on demand and I'm attempting to enable the ability to add these cards to the Apple Wallet. Everything seems to be working all the way to the final stage of the process where I get a PKPassKitErrorDomain systemCancelled and I can't seem to find any clues as to why the system is canceling. For context - I have the com.apple.developer.payment-pass-provisioning entitlement. I have both the Wallet and In-App Provisioning capabilities enabled in the App. I have defined a PKAddPaymentPassViewControllerDelegate class that implements both the generateRequest and didFinishAdding methods. I'm leveraging PKAddPaymentPassViewController in SwiftUI by using a UIViewControllerRepresentable implementing class that returns the view controller properly when makeUIViewController is called. I build a PKAddPaymentPassRequest object and ensure that it is properly filled with encryptedPassData, activationData, and ephemeralPublicKey. As a user I'm able to go to the virtual card view, open the instance of PKAddPaymentPassViewController, select the destination for the card, see the Add Card information. I get to the point where the view tells me it's contacting the card issuer and then I get an error message "Could Not Add Card - Try again later or contact your card issuer for more information" with a "Set Up Later" button. I then get the system canceled error. I should mention that I'm able to add these virtual cards manually via the Apple Wallet. The process works similarly but requires me to provided an OTP to conclude the process. This flow works and I have active cards in my wallet. I'm having a very hard time figuring out how to try and debug this issue further. The only error that the system returns is the system canceled notice. Any insight into where I might be missing something or how to debug the issue further would be greatly appreciated. Any thought on how I could debug this further would also be greatly appreciated. Thanks in advance - AYAL

Hello, I am setting up a feature for my company's banking app that allows users to add their payment/debit card they have with us to the Apple Wallet on their device. We have the in-app provisioning entitlement setup and configured in the app and configured with our banking partner/TSP. We are able to manually provision production environment cards via the Wallet app. I am using test card data from my TSP. I send them the two certificates, nonce, and nonce signature data and am given activationData, encryptedPassData, and an ephmeralPublicKey that we then set on an instance of PKAddPaymentPassRequest. We call the handler on the delegate method that is called with that request object and get an error: The operation couldn’t be completed. (PKPassKitErrorDomain error 2.) Looking at the PassKit library shows this is PKUnsupportedVersionError - Unsupported pass version. Our TSP hasn't been super helpful in troubleshooting this issue and just said we should contact Apple as it is an Apple error. I am trying to figure out if the issue is with how we are implementing the feature or with the test data itself given to us.

Hello, I am developing an Apple Pay and In-App Provisioning integration for the bank where I work. All entitlements are properly configured, and we are integrated correctly with our Payment Network Operator (PNO). We are using PKAddPaymentPassViewControllerDelegate to handle the provisioning process. The flow progresses as expected up to the Terms and Conditions screen. However, after accepting the terms, the process fails with the message: "Could not add card." Upon checking the device logs using the Wallet profile configuration, I observed the following response from Apple's backend: Response: https://nc-pod10-smp-device.apple.com:443/broker/v4/devices/041315032816900221610987313158566F368A9CEBA1291E/cards/745f792b9d0644e5a6e713d54f505296/enable 500 Time profile: 1.80458 seconds { x-conversation-id = "6ec59a63424f4035915e32f22ea645e4" Vary = "accept-language" Content-Type = "application/json" x-pod = "nc-pod10" x-keystone-correlationid = "E3DD5A5A-FD18-4500-8570-2BD1334E281C" Date = "Thu, 17 Apr 2025 07:05:03 GMT" x-apay-service-response-details = "via_upstream" Content-Length = "49" x-envoy-upstream-service-time = "964" x-pod-region = "paymentpass.com.apple" } { errorCode = 40456; statusCode = 500; } This seems to indicate that the card enablement step is failing on the server side. Our internal systems have not logged any request failure from Apple at this step, which makes it difficult to pinpoint whether the issue is in the PNO integration, entitlement configuration, or something else. We are currently testing in a production environment on a physical device (not using sandbox), and provisioning flows are initiated through our iOS app using PKAddPaymentPassRequest. Could you please help us interpret error code 40456 and identify what steps we should take to resolve this issue? If needed, we can also provide the full device log and additional details. Thank you in advance for your support. Best regards, Mansur Bagwan

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.

During our Apple Pay integration testing, we encountered an issue that we're unsure how to resolve. Below are the steps we followed: Created an Apple Pay sandbox test account for Raul and added a test card, following the documentation here: https://developer.apple.com/apple-pay/sandbox-testing/ Opened the Golfmanager platform and initiated a booking. For payment, selected Apple Pay as the method. Raul clicked the Apple Pay button on the Golfmanager UI. He scanned the QR code using his iPhone, logged in with the test account. Apple Pay began validating our merchant identity and retrieved the wallet token to proceed with payment. The Apple Pay payment sheet appeared on Raul's iPhone, showing the card details and the amount requested by Golfmanager. Suddenly, the Apple Pay sheet closed unexpectedly, and we have no insight into what went wrong or what might be missing on our end. Here is the video: https://drive.google.com/file/d/1r-73edQ9eBZzXi6HoSYYGjKO8LbxBrZi/view?usp=drive_web

Hi guys, We are trying to implement a solution that would allow users to subscribe to other users in our app. The system should work the same way as Twitch's subscription model works. Users should be able to subscribe to anyone and each subscription should have different tiers. From what we were able to gather, users cannot have multiples of the same subscription on applestoreconnect. Meaning that we would probably need to make a custom subscription per every user? Here we have also learned that there is a limit of 10 000 types of subscriptions and that it is not possible to dynamically create/delete them for users. (correct me if I am wrong) Is there a solution for handling this type of a scenario? Appreciate all answers.

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(); }

I am writing regarding an issue I have encountered while attempting to complete a payment using test users created within the Sandbox environment of Apple Pay. The problem persists specifically when trying to make payments through the demo page at https://applepaydemo.apple.com/. Problem Description: When initiating a payment process with either of the following test user accounts. The flow proceeds as follows: The Apple Pay window appears correctly. Processing begins but does not conclude successfully. After processing concludes, there is no prompt for 'Pay with Touch ID'. Additional Information: Device & OS Version: MacOS 15.3.2 Browser & Version: Safari 18.3.1 Real Device or Simulator: Real device used First Occurrence: Before January 1st, 2025 Custom Configurations or Backend Used: No custom configurations or backend modifications are being utilized during interaction with the demo page. Could you please provide assistance in resolving this issue?

please bear with me, i am NOT a developer. we have third party developer creating a banking app that is throwing an error when trying to provision MasterCard for Apple Pay. MasterCard says they do not see the request come in at all. our developer says the issue is between mastercard and apple - and asked us to reach out to Apple. Information provided from our developer: “Error code 2 is 'system cancelled' from the PKAddPaymentPassError enum. Basically, there is an issue between Apple and Mastercard (using the encrypted card info from...” Response from Mastercard Connect: Upon further research with the examples you shared we are not seeing any attempt that reached to MC

For the pushToken sent by APNS to register a wallet pass for update notifications, is there a max length or size that APNS will send? I save the token in my database and have it defined as varchar(256), but I have had some instances where the pushToken is larger than that. I'd like to know if there's an absolute max size that APNS will send. Then I'll know if I should reject requests with tokens larger than what's expected, and/or if I need to make the token size larger in the database.

We have an app that uses the pass-presentation-suppression entitlement and calls requestAutomaticPassPresentationSuppression to prevent the Wallet app from being presented when the device is displaying a barcode to a barcode/nfc reader. This works as expected for users of the standard Apple Wallet app. However, it does not prevent third-party wallet apps from being launched, which hides the barcode and prevents it from being scanned properly. What options do I have to prevent third-party wallet apps from launching or interfering while our app is actively presenting a barcode?

We are an issuer attempting to implement In-App Provisioning of Payment Cards leveraging Mastercard MDES and have successfully obtained our entitlement from Apple, but have not received the documentation titled "Getting Started with Apple Pay In-App Provisioning, Verification & Security". The latest copy I have found has been via Scribd for a version 3.0 from June 2020. I've tried contacting Apple Support and the In-App Provisioning Entitlements group but have had no luck. Thank you!

Hi Team, I have merchant session object - {"epochTimestamp":1748333121032,"expiresAt":1748336721032,"merchantSessionIdentifier":"SSH7CCD205FEEDD45AD84B77374D098B335_916523AAED1343F5BC5815E12BEE9250AFFDC1A17C46B0DE5A943F0F94927C24","nonce":"2d18eab4","merchantIdentifier":"8535F497EC92999BAD63C6F213F0F32DEEB5DBF8A0A91007F6C1128537B6FB19","domainName":"f7071159c1tst-store.occa.ocs.oraclecloud.com","displayName":"DDF Test","signature":"308006092a864886f70d010702a0803080020101310d300b0609608648016503040201308006092a864886f70d0107010000a080308203e43082038ba003020102020859d8a1bcaaf4e3cd300a06082a8648ce3d040302307a312e302c06035504030c254170706c65204170706c69636174696f6e20496e746567726174696f6e204341202d20473331263024060355040b0c1d4170706c652043657274696669636174696f6e20417574686f7269747931133011060355040a0c0a4170706c6520496e632e310b3009060355040613025553301e170d3231303432303139333730305a170d3236303431393139333635395a30623128302606035504030c1f6563632d736d702d62726f6b65722d7369676e5f5543342d53414e44424f5831143012060355040b0c0b694f532053797374656d7331133011060355040a0c0a4170706c6520496e632e310b30090603550406130255533059301306072a8648ce3d020106082a8648ce3d030107034200048230fdabc39cf75e202c50d99b4512e637e2a901dd6cb3e0b1cd4b526798f8cf4ebde81a25a8c21e4c33ddce8e2a96c2f6afa1930345c4e87a4426ce951b1295a38202113082020d300c0603551d130101ff04023000301f0603551d2304183016801423f249c44f93e4ef27e6c4f6286c3fa2bbfd2e4b304506082b0601050507010104393037303506082b060105050730018629687474703a2f2f6f6373702e6170706c652e636f6d2f6f63737030342d6170706c65616963613330323082011d0603551d2004820114308201103082010c06092a864886f7636405013081fe3081c306082b060105050702023081b60c81b352656c69616e6365206f6e207468697320636572746966696361746520627920616e7920706172747920617373756d657320616363657074616e6365206f6620746865207468656e206170706c696361626c65207374616e64617264207465726d7320616e6420636f6e646974696f6e73206f66207573652c20636572746966696361746520706f6c69637920616e642063657274696669636174696f6e2070726163746963652073746174656d656e74732e303606082b06010505070201162a687474703a2f2f7777772e6170706c652e636f6d2f6365727469666963617465617574686f726974792f30340603551d1f042d302b3029a027a0258623687474703a2f2f63726c2e6170706c652e636f6d2f6170706c6561696361332e63726c301d0603551d0e041604140224300b9aeeed463197a4a65a299e4271821c45300e0603551d0f0101ff040403020780300f06092a864886f76364061d04020500300a06082a8648ce3d0403020347003044022074a1b324db4249430dd3274c5074c4808d9a1f480e3a85c5c1362566325fbca3022069369053abf50b5a52f9f6004dc58aad6c50a7d608683790e0a73ad01e4ad981308202ee30820275a0030201020208496d2fbf3a98da97300a06082a8648ce3d0403023067311b301906035504030c124170706c6520526f6f74204341202d20473331263024060355040b0c1d4170706c652043657274696669636174696f6e20417574686f7269747931133011060355040a0c0a4170706c6520496e632e310b3009060355040613025553301e170d3134303530363233343633305a170d3239303530363233343633305a307a312e302c06035504030c254170706c65204170706c69636174696f6e20496e746567726174696f6e204341202d20473331263024060355040b0c1d4170706c652043657274696669636174696f6e20417574686f7269747931133011060355040a0c0a4170706c6520496e632e310b30090603550406130255533059301306072a8648ce3d020106082a8648ce3d03010703420004f017118419d76485d51a5e25810776e880a2efde7bae4de08dfc4b93e13356d5665b35ae22d097760d224e7bba08fd7617ce88cb76bb6670bec8e82984ff5445a381f73081f4304606082b06010505070101043a3038303606082b06010505073001862a687474703a2f2f6f6373702e6170706c652e636f6d2f6f63737030342d6170706c65726f6f7463616733301d0603551d0e0416041423f249c44f93e4ef27e6c4f6286c3fa2bbfd2e4b300f0603551d130101ff040530030101ff301f0603551d23041830168014bbb0dea15833889aa48a99debebdebafdacb24ab30370603551d1f0430302e302ca02aa0288626687474703a2f2f63726c2e6170706c652e636f6d2f6170706c65726f6f74636167332e63726c300e0603551d0f0101ff0404030201063010060a2a864886f7636406020e04020500300a06082a8648ce3d040302036700306402303acf7283511699b186fb35c356ca62bff417edd90f754da28ebef19c815e42b789f898f79b599f98d5410d8f9de9c2fe0230322dd54421b0a305776c5df3383b9067fd177c2c216d964fc6726982126f54f87a7d1b99cb9b0989216106990f09921d00003182018930820185020101308186307a312e302c06035504030c254170706c65204170706c69636174696f6e20496e746567726174696f6e204341202d20473331263024060355040b0c1d4170706c652043657274696669636174696f6e20417574686f7269747931133011060355040a0c0a4170706c6520496e632e310b3009060355040613025553020859d8a1bcaaf4e3cd300b0609608648016503040201a08193301806092a864886f70d010903310b06092a864886f70d010701301c06092a864886f70d010905310f170d3235303532373038303532315a302806092a864886f70d010934311b3019300b0609608648016503040201a10a06082a8648ce3d040302302f06092a864886f70d01090431220420c11c8025910403d6691af195664f47b606df9ccb351237d0de4e7c31e8a5067b300a06082a8648ce3d04030204483046022100ea8d2bb74b4960f17e4e45b99fec3f0539565fd3169091c6b39fbfb3e11a952a022100a4a4a3ff6d91caf8fa7d9b18179e0cc2156c90d4f719ae52734b4799c2b1beea000000000000","operationalAnalyticsIdentifier":"DDF Test:8535F497EC92999BAD63C6F213F0F32DEEB5DBF8A0A91007F6C1128537B6FB19","retries":0,"pspId":"8535F497EC92999BAD63C6F213F0F32DEEB5DBF8A0A91007F6C1128537B6FB19"} After sending this to session.compleMerchant I am getting the invalid access error. Regards, Varsha

When I use my iPhone to scan the apple pay QR code in chrome, the url is https://applepaydemo.apple.com/apple-pay-js-api, I keep geting the "Service Unavailable" error. Wonder know if you guys meet this error as well? Btw, the QR code feature needs IOS 18.

I have a question regarding the file apple-developer-merchantid-domain-association.txt. I understand that this file is used during API access for Apple Pay Web payments. However, is it necessary for our company to access this file during the payment process? Also, this domain validation file is expected to be placed in the publicly accessible “.well-known” folder on our web server. Is it acceptable for this file to remain readable by third parties on the Internet, including Apple’s servers, without posing any security risks? Since this file is generated during domain registration on the Apple Developer site and is unique to our domain, we believe there should be no security concerns even if accessed by third parties. However, are there any specific security requirements for this domain validation file? Please note that the domain validation has already been successfully completed. We appreciate your time and look forward to your guidance. Best regards,