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,
Apple Pay on the Web
RSS for tagApple Pay on the Web allows you to accept Apple Pay on your website using JavaScript-based APIs.
Posts under Apple Pay on the Web tag
108 Posts
Selecting any option will automatically load the page
Post
Replies
Boosts
Views
Activity
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.
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....
Topic:
Community
SubTopic:
Apple Developers
Tags:
Apple Pay on the Web
Apple Pay
Tap to Pay on iPhone
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?
Doc URL: https://developer.apple.com/documentation/applepayontheweb/requesting-an-apple-pay-payment-session
How can I send a POST request using PHP, and what certificates are required?
Currently, I have downloaded the following files on the backend: merchant_id.cer, apple_pay.cer, and a local cert.p12 file
This my code:
How can I set it as a formal payment environment if I can make the payment now without any deduction?
Doc URL: https://developer.apple.com/documentation/applepayontheweb/requesting-an-apple-pay-payment-session
How can I send a POST request using PHP, and what certificates are required?
Currently, I have downloaded the following files on the backend: merchant_id.cer, apple_pay.cer, and a local cert.p12 file
This my code:
But,run error:cURL Error: unable to set private key file: '***/private.pem' type PEM%
I'm currently integrating Apple Pay with my payment provider, and I'm encountering a signature validation error during the payment flow.
Here's the setup:
I’ve verified that my Merchant Certificate is valid, and I'm able to initialize the Apple Pay session without any issues. Also this curl works fine
The Payment Processing Certificate was created by my PSP.
PSP claims that the payment token signature is invalid during the transaction phase, which prevents payment completion.
The parsed signature starts like this
0:d=0 hl=2 l=inf cons: SEQUENCE
2:d=1 hl=2 l= 9 prim: OBJECT :pkcs7-signedData
13:d=1 hl=2 l=inf cons: cont [ 0 ]
15:d=2 hl=2 l=inf cons: SEQUENCE
17:d=3 hl=2 l= 1 prim: INTEGER :01
20:d=3 hl=2 l= 13 cons: SET
22:d=4 hl=2 l= 11 cons: SEQUENCE
24:d=5 hl=2 l= 9 prim: OBJECT :sha256
35:d=3 hl=2 l=inf cons: SEQUENCE
37:d=4 hl=2 l= 9 prim: OBJECT :pkcs7-data
48:d=4 hl=2 l= 0 prim: EOC
50:d=3 hl=2 l=inf cons: cont [ 0 ]
52:d=4 hl=4 l= 995 cons: SEQUENCE
56:d=5 hl=4 l= 904 cons: SEQUENCE
60:d=6 hl=2 l= 3 cons: cont [ 0 ]
62:d=7 hl=2 l= 1 prim: INTEGER :02
65:d=6 hl=2 l= 8 prim: INTEGER :16634C8B0E305717
75:d=6 hl=2 l= 10 cons: SEQUENCE
77:d=7 hl=2 l= 8 prim: OBJECT :ecdsa-with-SHA256
87:d=6 hl=2 l= 122 cons: SEQUENCE
89:d=7 hl=2 l= 46 cons: SET
91:d=8 hl=2 l= 44 cons: SEQUENCE
93:d=9 hl=2 l= 3 prim: OBJECT :commonName
98:d=9 hl=2 l= 37 prim: UTF8STRING :Apple Application Integration CA - G3
I'm looking for guidance on what could be causing this signature failure.
Does anyone know what else I can check regarding the merchant or payment processing certificates, private keys, or key usage that might cause Apple Pay signature validation to fail, even if the session initializes successfully? Domains are also verified.
Any help or suggestions would be greatly appreciated.
What am I missing in my checking for whether or not to offer Apple Pay on my website?
<script async crossorigin
src="https://applepay.cdn-apple.com/jsapi/v1.1.0/apple-pay-sdk.js"
></script>
...
<style>
apple-pay-button {
display: none;
}
</style>
...
<apple-pay-button buttonstyle="black" type="plain" locale="en-US" onclick="startApplePay('${APPLE_PAY_MERCHANT_ID}','${paymentForm.amount}');"></apple-pay-button>
So, the button is not displayed by default. I only change the style to displayed if:
window.onload = function() {
if (isApplePaySupported()) {
document.querySelector("apple-pay-button").style.display = "inline-block";
};
}
function isApplePaySupported() {
return (window.PaymentRequest &&
window.ApplePaySession &&
ApplePaySession.canMakePayments() &&
ApplePaySession.supportsVersion(applePayVersion));
}
Yet, once in a while a click comes through that tries to create a PaymentRequest with
const applePayMethod = {
"supportedMethods": "https://apple.com/apple-pay",
"data": {
"version": applePayVersion,
"merchantIdentifier": merchantIdentifier,
"merchantCapabilities": [
"supports3DS"
],
"supportedNetworks": [
"amex",
"discover",
"masterCard",
"visa"
],
"countryCode": "US"
}
};
and results in:
NotSupportedError, The payment method is not supported
What else might be "not supported" in the request for this particular user/device/wallet? In particular, that could be known immediately when the PaymentRequest is created, but before any payment instrument from the wallet is selected?
And, is there anything I could detect before showing the button?
Or, is it even possible for the button to be clicked by some kind of automation, even if it's not displayed?
I built a web application using the Apple Pay on the Web Interactive Demo with the Payment Request API, but encountered a few issues:
The initiated web Apple Pay interface shows a spinning circle at the bottom and cannot proceed with payment(Bottom display:正在处理). What could be causing this?
How to set up sandbox testing for payments?
How to asynchronously and synchronously retrieve payment results (backend code to fetch payment results)? The demo only shows frontend code using await response.complete("success"); for retrieving payment results
my demo URL: https://shop.wowseer.com/rsolomakhin/pr/applepay/
我使用Apple Pay on the Web Interactive Demo构建了一个web应用使用的是Payment Request API方式,但是遇到了几个问题:
拉起的web Apple Pay 底部一直转圈圈无法付款,这个是什么问题?
如何设置sandbox测试付款呢?
如何异步、同步获取支付结果(后端代码获取支付结果)?demo只有await response.complete("success");前端代码获取支付结果的操作
demo网址: https://shop.wowseer.com/rsolomakhin/pr/applepay/
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!
I am facing an issue with Apple Pay js while doing the integration
we are using reference
https://applepaydemo.apple.com/apple-pay-js-api
In this I can generate the merchantSession correctly
But when I pass that merchantSession in
session.completeMerchantValidation(merchantValidation) as per documentation
It is getting failed and also no appropriate error is being shown in the console
Hello I'm getting an error when the Apple Pay sheet opens on a third party browser like Chrome when completeShippingMethodSelection is called
'DataCloneError: Failed to execute 'postMessage' on 'Window': #<Object> could not be cloned.'
I'm also seeing this warning when the apple pay sheet opens
Failed to execute 'postMessage' on 'DOMWindow': The target origin provided ('https://applepay.cdn-apple.com') does not match the recipient window's origin
although I also see this warning on https://applepaydemo.apple.com/