Hello -- We're preparing to roll out Apple Pay on website in the next week but encountered some issues during testing. While we successfully processed transactions using a VISA card, we ran into errors when testing with other card brands. Has anyone come across this issue before?

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,

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

Hi Apple Developer Community and Support, We are implementing Apple Pay on the Web and are encountering a persistent issue with merchant validation when the ApplePaySession is initiated from a JavaScript application running within a cross-origin iframe. Our Setup: Top-Level Domain: https://application.my.com/ (where the Apple Pay button is displayed, and the iframe is embedded) iFrame Content Origin: https://cashier.my.com/ (Our custom JavaScript application that handles the Apple Pay integration and directly calls our Payment Service Provider's (PSP) API for merchant validation). iFrame allow attribute: The iframe correctly includes allow="payment *". The Problem: When a user clicks the Apple Pay button, the ApplePaySession is successfully created and the Apple Pay sheet opens in Safari iOS. This suggests the browser recognizes the allow="payment *" attribute and allows the API calls. However, during the session.onvalidatemerchant callback, our JavaScript code makes a direct API call to our PSP (Nuvei)'s endpoint. This call consistently fails with an "Invalid domain name!" error, and the Apple Pay sheet then shows "Payment Not Completed." PSP's Diagnosis: Our PSP (Nuvei) has investigated and stated that for this specific endpoint (getAppleValidationApiFlow.do), "there is no explicit way to pass domain to the endpoint and domain for which session is issued is based on 'Referer' header." Our Question for Apple: Given that Safari 17+ now supports allow="payment" for cross-origin iframes to enable Apple Pay APIs, we have the following questions: What is Apple's official guidance or expectation regarding the Referer header for ApplePaySession.onvalidatemerchant calls when the ApplePaySession is instantiated from a cross-origin iframe? Is it expected that the Referer header for calls originating from the iFrame will always be the iFrame's origin? Does Apple's merchant validation process (when the PSP calls apple-pay-gateway.apple.com/paymentservices/startSession) itself rely on or interpret the Referer from the initial client-to-PSP call? Are there recommended best practices or standard approaches for PSP integrations in this cross-origin iFrame scenario to ensure the Referer validation (or equivalent domain validation) is correctly satisfied? We're trying to understand if our PSP's specific reliance on the Referer for this validation is a standard requirement implicitly set by Apple for this flow, or if there are other architectural approaches that should allow this scenario to work seamlessly. Thank you for any insights or guidance you can provide.

Hi!!! I can't publish the app as I have a paid membership through Stripe. I have a wordpress site and have a paid membership to access the content... The app is geared by a third party service and I can't put any code into it... What can I do? There is an idea that in the application to display a link to the site where to place the payment for membership... Please advise, I'm not the first to face this....

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?

Hi Team, when launching an ApplePay session from a 3rd party browser where we get the QR code popup - is it possible to affect the popup's language? We are setting the button's language via locale parameter, but when the QR code pop's up it does not respect this setting (seems like it respects browser language). Button in Arabic Corresponding popup Browser language Arabic Coresponding popup I was unable to find anything in the documentation - could you please either point me to the relevant documentation or confirm/deny that it is possible to request a language for the popup via tjr javascript API? Kind regards Tomas

I'm implementing Apple Pay in a Flutter iOS app using the pay plugin and Braintree as the payment processor. I have followed all necessary steps as outlined by Apple and community resources (e.g., Medium articles, official Apple Developer documentation), but the Apple Pay button does not appear on a real device. Here's what I've completed: Created an Apple Pay Merchant ID Created and downloaded the Apple Pay Payment Processing Certificate, then uploaded it to Braintree Downloaded the Braintree-signed certificate and confirmed it's active in the Apple Developer portal Added the Merchant ID under Signing & Capabilities in Xcode Enabled Apple Pay capability in Xcode Added the Merchant ID to Info.plist Installed required Flutter packages (e.g., pay) Using a valid Apple Pay payment configuration file in Flutter (see below) Tested on a real iOS device with a valid Apple Pay test card added to Wallet Flutter Payment Configuration (in Dart JSON): json Copy Edit { "provider": "apple_pay", "data": { "merchantIdentifier": "merchant.com.example", "displayName": "My Store", "merchantCapabilities": ["3DS", "debit", "credit"], "supportedNetworks": ["visa", "masterCard", "amex"], "countryCode": "US", "currencyCode": "USD" } } Despite this complete setup, the ApplePayButton widget remains invisible There are no errors in the console. Can you help identify what may be missing or misconfigured at the code or configuration level?

Hello everyone, I’m currently in the process of implementing Apple Pay on my company’s e-commerce website under a subscription model with recurring payments. I would appreciate some help in clarifying the following points: Is the applicationPrimaryAccountNumber the DPAN and the merchantTokenIdentifier the MPAN? If not, which fields represent each one or how do I recognise them? Is the onlinePaymentCryptogram used only for processing payments with the DPAN, or is it also involved when using the MPAN? Is the onlinePaymentCryptogram single-use or does it have an expiration time? Or is it reusable with no limits? According to Apple’s data policies, is it recommended for our servers to perform the payment token decryption (debundling), or should this only be handled by the payment gateway processor to stay compliant? Below is the payment request I’m using for testing, along with the decrypted payment token returned for a test card: Payment Request: { "countryCode": "US", "currencyCode": "USD", "merchantCapabilities": ["supports3DS", "supportsDebit", "supportsCredit"], "supportedNetworks": ["visa", "masterCard", "amex", "discover"], "requiredBillingContactFields": ["postalAddress", "name"], "lineItems": [ { "label": "Subtotal", "amount": "9" }, { "label": "Taxes", "amount": "1" } ], "total": { "label": "Demo (Card is not charged)", "amount": "10", "type": "final", "recurringPaymentIntervalUnit": "month" }, "recurringPaymentRequest": { "paymentDescription": "Recurring payment", "regularBilling": { "label": "Demo (Card is not charged)", "amount": "10", "type": "final", "paymentTiming": "recurring", "recurringPaymentIntervalUnit": "month" }, "managementURL": "${window.location.origin}/api/managePaymentMethod" } } Decrypted Payment Token: { "applicationPrimaryAccountNumber": "5204240494898922", "applicationExpirationDate": "280630", "currencyCode": "840", "transactionAmount": 0, "deviceManufacturerIdentifier": "050110030273", "paymentDataType": "3DSecure", "paymentData": { "onlinePaymentCryptogram": "MCt5xR+VnQAAAAM/8mUjAAADFIA=" }, "merchantTokenIdentifier": "DM4MMC1US000000042e438d170774669844e732a41c28e97", "merchantTokenMetadata": { "cardMetadata": { "longDescription": "Test Bank for MasterCard MTF", "cardCountry": "US", "shortDescription": "Test Bank 2", "fpanSuffix": "0049" }, "cardArt": [ { "url": "https://nc-crt-smp-device-asset.apple.com:443/broker/v1/assets/174ce63257704d93b00aff8aa09ec0d5", "name": "cardBackgroundCombined@2x.png", "type": "image/png" } ] } } Thanks in advance for your help and guidance.

Apple Sandbox is not available in India, also Apple Pay itself is not supported by Indian Banks. How can I still test using Apple Pay sandbox in India? I am trying to add test cards on my iPhone and it fails to add it. It tries to connect to Issuer, which it should not for sandbox Apple Id. Can anyone help how to achieve this?