We are on a .NET ecommerce site hosted on AWS on a windows 2012R2 server. We have apple pay for the web integrated on the site and the certificates (merchant id and apple pay) were set to expire shortly. We created a new merchant id and apple pay cert, however we are now stuck as the new merchant ID certificate doesn't appear to be working although the old one did. Note there have been no code changes. Basically the apple pay process is failing on the merchant validation.
Here are the steps we took:
Created a CSR in Keychain Access
Generated a Merchant ID cert in the Apple Developer account with that CSR.
Imported the Merchant ID cert back into Keychain Access and exported as a p12 file the cert and the private key used to generate the CSR.
Imported the p12 file into Windows 2012 R2.
I can see in our debugging that the new certificate is being loaded but a SSL/TSL connection couldn't be made. So it seems there is an issue with the cert.
Has anyone encountered this? I'm out of ideas at this point and under a lot of pressure from management to fix what was supposed to be a routine maintenance issue.
If anyone has any ideas, that would be greatly appreciated.
Apple Pay
RSS for tagDiscuss how to integrate Apple Pay into your app for secure and convenient payments.
Selecting any option will automatically load the page
Post
Replies
Boosts
Views
Activity
Hello, we are trying to extend the dates of verified domains following the docs of https://developer.apple.com/documentation/applepayontheweb/maintaining-your-environment#Renew-Your-Domain-Verification and configured the server following https://developer.apple.com/documentation/ApplePayontheWeb/setting-up-your-server
we've download the apple-developer-merchantid-domain-association.txt and update them on their respective locations, click 'ok' button and we get redirected to the main page of the merchant certificate, but the expiration dates have not been extended, we can see on our web crawler that Apple Requested the file and it return a 200.
No popup errors are shown, no console developer error we only get redirected to the merchant certificate information page.
Topic:
App & System Services
SubTopic:
Apple Pay
When running the test app with test flight before actually opening the app, the execution region is Korea and the country code is Korea, but the currency code on the payment screen is displayed as dollars or euros instead of won. In the payment settings, the currency code is set to won for Korea and dollars for the United States, and the European region is not set at all, but in some phones it is displayed as euros, and in some phones it is not like this, and in some cases it is displayed as won normally.
Hello,
On my website, I have a button to make a payment via Apple Pay. When I click on it, the Touch ID window opens correctly. However, when I place my finger on the Touch ID, I get a payment error.
This issue only occurs in production mode. In sandbox mode, everything works perfectly.
Here is a log file :
log.txt
Thank you in advance for your help.
we are currently using the requestAutomaticPassPresentationSuppression API in my app. to prevent the Wallet interface from appearing when an NFC/RF reader is detected during active app usage.
Recently, a new transit card supporting Express Mode (T-money Transit Card) was released in Korea, and we are seeing an increasing number of users enabling Express Mode.
However, this has introduced an issue where users are unable to use the BLE-based functionality we provide via our widget. Specifically, when the user taps our widget, it triggers a BLE signal broadcast for approximately 10 seconds. In this scenario, when the user brings their iPhone close to our reader, Express Mode is activated before the BLE interaction can be established. This prevents the BLE signal from being successfully received and processed.
We would like to ask:
Is it possible to suppress Express Mode behavior (similar to requestAutomaticPassPresentationSuppression) even when the app is launched via a widget interaction?
Alternatively, is there any way to delay or defer Express Mode activation temporarily when launching from a widget or during BLE communication?
We would appreciate any guidance or best practices you can share regarding this scenario.
Thank you.
Topic:
App & System Services
SubTopic:
Apple Pay
Hi team at Apple, here is a scenario we came across:
The order of priority of payment methods in Apple Wallet follows:
Credit
Debit
Apple Cash
Our app displays a payment sheet that excludes credit cards. Instead of a debit card, the default payment option shown to the user on the payment sheet is Apple Cash.
Is this a known issue or have we configured something wrong in our end?
We have recently begun testing in our production environment and have been unable to push provision any cards, receiving a 500 error:
default 11:15:59.136742-0300 PassbookUIService Response:
https://pr-pod9-smp-device.apple.com:443/broker/v4/devices/SEID_NUMBER/cards 500 Time profile: 0.486102 seconds
{
x-conversation-id = "52463d9f488e428f829633a1518ea72d"
Vary = "accept-language"
Content-Type = "application/json"
x-pod = "pr-pod9"
x-keystone-correlationid = "058F11DE-839F-47AC-A623-741BF32CEA80"
Date = "Thu, 16 Jan 2025 14:15:58 GMT"
x-apay-service-response-details = "via_upstream"
Content-Length = "81"
x-envoy-upstream-service-time = "172"
x-pod-region = "paymentpass.com.apple"
}
{
statusCode = 500;
statusMessage = "Broker Service Response exception";
}
In 05/2024 we received an e-mail from applepayentitlementsapple.com confirming the granting of in-app provisioning entitlements for our production apps.
We've already sent a feedback on Feedback Assistant. Here is the code to track: FB16344669.
Also, we sent another e-mail to applepayentitlementsapple.com, Case-ID: 11317916, but we haven't received a reply yet.
Can you help us? We are concerned, since our pre-certification starts on January 27th.
Thanks in advance.
We are developing a native iOS financial application called Tradu: Stocks, Forex, and CFDs (Apple ID: 6473443264), which embeds a WKWebView to render all user-facing logic. All user interactions—including authentication with MFA—occur inside this WKWebView.
To access native functionality, we use postMessage() to communicate between the web and native layers. This approach has worked successfully for biometric authentication, for example.
We are currently integrating Apple Pay In-App Provisioning and have a few questions regarding compliance with the documentation provided by our Issuer Host (Modulr). In the document titled Getting Started with Apple Pay: In-App Provisioning, Verification, Security, and Wallet Extensions (Version 4.0, February 2023), all examples are based on a fully native application.
We’ve managed to integrate most of the In-App Provisioning flow via postMessage() up to the point of passing encryptedData to the Payment View.
Apple Pay button inside WKWebView
In Section 7: Frontend Overview, the user initiates the provisioning by tapping a native PKPaymentButton (SwiftUI example).
In our case, this button is rendered inside the WKWebView, styled according to the Apple Style Guide.
While the document references this approach as a “raw mark text supplement,” is this method acceptable and compliant with Apple’s UX and technical guidelines?
MFA requirement before provisioning
In Section 4: Security Guidelines, it is stated that the user must have passed MFA at least once before starting the provisioning flow.
In our implementation, users must complete MFA on every login (including on recognized devices) before the provisioning UI becomes available.
Even though this is not tied specifically to “unrecognized devices,” is our MFA requirement sufficient to satisfy Section 4.2?
Summary:
Is using a web-rendered Apple Pay button inside WKWebView (instead of a native PKPaymentButton) considered compliant?
Is our MFA enforcement model (required on every login) aligned with the security requirements outlined in Section 4.2 of the Apple Pay In-App Provisioning documentation?
I am adding Apple Pay to my eCommerce site and I am having a lot of difficulty with the PaymentsRequest API in Microsoft Edge browser.
I have a partial implementation that displays the Apple Pay button and creates a PaymentRequest when the button is clicked. That's all.
On Safari, this is enough to display the Apple Pay dialog. The process doesn't proceed further because I haven't implemented a handler for the merchantvalidation event. With Chrome on a Mac, the behavior is the same, I can scan the code and see the Apple Pay dialog.
On Microsoft Edge, I never see the code to scan. In my web console, I'm seeing errors like
InvalidStateError: Failed to execute 'canMakePayment' on 'PaymentRequest': Cannot query payment request
and
NotSupportedError: The payment method "https://apple.com/apple-pay" is not supported. No "Link: rel=payment-method-manifest" HTTP header found at "https://www.apple.com/apple-pay/"
Is Apple Pay not supported on Windows?
I see the demo site here, which gets farther than I have gotten. It does display the scan code, but payment still never completes. I see the same payment-method-manifest error in the console.
If Apple Pay is not supported on any PCs other than Macs, is there any reason to use the PaymentRequest API instead of Apple Pay JS?
I started digging into the W3C standards and it turns out that merchantvalidation event is deprecated. Chrome on Mac does catch it, so it seems like it's supported there. But I have concerns about the long term future. Is it going to remain supported? If so, I would imagine that the interface could change.
It seems like the only benefit of the W3C PaymentRequest API is that Mac users with non-Safari browsers may still be able to use Apple Pay. In theory, that's something I'd still like to support, even if it's only a small number of users, but I only have time for one integration right now, and I need to pick the best one.
How much faith should I have in the W3C PaymentRequest API?
Is it reasonable to pursue it with the goal of including all Mac users regardless of browser? Or is it likely a dead API and I should stick to Apple Pay JS instead to provide a better experience to Safari users?
It also looks like the PaymentRequest API isn't fully finalized yet, so maybe that's the source of my issues. Maybe I should just use Apple Pay JS for now with an eye to supporting PaymentRequest when the spec is finalized.
I greatly appreciate your input.
In the docs, I see a button type with label "Pay With [apple logo]. https://developer.apple.com/design/human-interface-guidelines/apple-pay
Although I don't see this type as an option here: https://developer.apple.com/documentation/PassKit/PKPaymentButtonType
Wondering if I'm looking in the right place and if this button type is still available?
Topic:
App & System Services
SubTopic:
Apple Pay
Hi everyone,
I have a question regarding App Store approval. In my country, Apple In-App Purchases are not supported, so for users in unsupported regions we need to use a third-party payment provider. For countries where In-App Purchases are supported, we plan to use Apple IAP.
Could you please advise on the correct approach to ensure the app complies with App Store guidelines and can be approved?
Topic:
App & System Services
SubTopic:
Apple Pay
We are attempting to integrate the Apple Pay service into our website and have successfully verified our domain with Apple manually. However, we consistently receive an 'ApplePay reverify failed' email a month before the expiration time. Upon checking, we updated the SSL certificate for the domain before receiving the email, and the link still works fine in the browser. We would greatly appreciate any feedback from someone who can help us with this issue.
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?
Hi, I am the developer of this app and I was shared this receipt which strangely does not list my name as the merchant but instead says "The flow network" as you can see below:
What is going on?
Topic:
App & System Services
SubTopic:
Apple Pay
Dear Apple team and developers,
We integrated Apple Pay E-Commerce on our system and made successful transaction at January using following certificates.
Merchant Identity Certificate (generated from our Apple developer account)
Payment Processing Certificate (generated from our Apple developer account)
Payment Session Server Certificate (used following command and generated from apple-pay-gateway-cert.apple.com:443 test URL)
Command: openssl s_client -connect apple-pay-gateway-cert.apple.com:443 -key MIC_priv.key -cert MIC_merchant_id.pem -showcerts | openssl x509 -outform DER > apay_ident_trusted_cert_test.der
Root CA G3 (Downloaded “Apple Root CA – G3 Root” from https://www.apple.com/certificateauthority/ )
But at this month, we got new certificate problem (please check following) when we try to execute Apple Pay E-Commerce transaction.
Certificate 'C=US,O=Apple Inc.,OU=Apple Certification Authority,CN=Apple Application Integration CA - G3' is not valid Certificate.
What is this certificate? And Where can I download or generate this certificate from? Could you please advise/give us good information for this certificate problem?
Best Regards,
Bilguun Enkhbaatar
Topic:
App & System Services
SubTopic:
Apple Pay
Tags:
Developer Tools
Apple Pay on the Web
Apple Pay
We have developed Apple Wallet Extension for our App. The in-app provisioning for the card is working. However when we try to add the card from Wallet extension it gives error saying "Your issuer does not yet offer support for this card".
From the apple documentation we can see the issues is same as mentioned in Scenario 2 at following link https://applepaydemo.apple.com/in-app-provisioning#8.4
We are getting eligibilityStatus as 0
Below is the response from Wallet captured using SysDiagnosis
https://crt-pod1-smp-device.apple.com:443/broker/v4/devices/0434320BCB1A90022306073796318273728D0A367FA927F4/cards 200 Time profile: 1.77856 seconds
{
x-conversation-id = ......
Content-Type = "application/json"
x-pod = "crt-pod1"
x-xss-protection = "1; mode=block"
Server = "Apple"
x-pod-region = "paymentpass.com.apple"
regionbrokerurl = "https://crt-pod1-smp-device.apple.com:443/broker"
Date = "Wed, 06 Aug 2025 11:39:30 GMT"
Content-Length = "488"
x-envoy-upstream-service-time = "1400"
Strict-Transport-Security = "max-age=31536000; includeSubdomains"
cross-origin-opener-policy = "same-origin"
x-keystone-correlationid = ......
x-content-type-options = "nosniff"
Vary = "accept-language"
x-frame-options = "SAMEORIGIN"
}
{
applicationIdentifier = ......;
auxiliaryCapabilities = {
};
cardType = 4;
deviceProvisioningDataExpected = 1;
eligibilityStatus = 0;
identifier = ......;
learnMoreURL = "https://www.apple.com/ae/apple-pay/banks/ae/en-ae.html";
nonce = ......;
paymentApplications = (
{
appletTypeIdentifier = Argon;
paymentType = Credit;
}
);
region = "paymentpass.com.apple";
sanitizedPrimaryAccountNumber = 7008;
sanitizedPrimaryAccountPrefix = "";
}
Hi Support,
When the applepay express transit option is used on emv payment cards,
like this
iPhone - Open “Settings” → “Wallet & Apple Pay” → “Express Transit Card”.
And a emv single card has been enabled under Express Transit
And on transit reader Apple Enhanced contactless Polling support is provided, ( with VAS not supported, user authentciation not supported)
Sometimes ATQB response also comes from the iPhone or iWatch instead of the ATQA response, and then it causes the transit reader to report as collision error in the polling.
Sequence of the packets:
WUPA
WUPB
ECP frame
WUPA
WUPB
ATQB
WUPA
ATQA
Topic:
App & System Services
SubTopic:
Apple Pay
We are an acquirer/payment provider offering Apple Pay. Our merchants use our hosted checkout to accept payments. After a user pays with Apple Pay on our checkout, the Wallet transaction record shows our checkout domain as the payee. We would like it to display the merchant’s brand/name so users can recognize or contact the merchant.
Is there any parameter or configuration that controls what Wallet shows as the payee? For example, can this be set via a specific field/parameter, or is it strictly derived from the Merchant ID’s display name (or other Apple Pay configuration)? What is the correct approach for a PSP/acquirer to have the merchant’s brand shown in Wallet transaction record?
Additional detail: The field in question is the merchant/payee name shown in the Apple Wallet receipt—directly under the transaction amount at the top of the receipt, and again beneath the “Total” line.
What is the version policy for the Apple Pay SDK Javascript ?
The documentation refers to this link :
https://applepay.cdn-apple.com/jsapi/1.latest/apple-pay-sdk.js
The future updates will overrride the file on that link ? Is there a way to be notified of any changes ?
We are using a previous version named v1 :
https://applepay.cdn-apple.com/jsapi/v1/apple-pay-sdk.js
What are the risks not using changing to the lastesdt link ?
Thank you for your help.
We are writing to report a recurring stability issue with the Apple Pay sandbox environment. We are using the official sandbox test cards provided on the Apple Developer website for our testing:
https://developer.apple.com/apple-pay/sandbox-testing/
We are experiencing frequent, intermittent failures when attempting to add these sandbox cards to the Wallet for testing purposes. The issue typically occurs a couple of times per day. When the failure occurs, the card provisioning process fails unexpectedly.
The issue is not limited to a single card; we have observed this behavior across all available card networks. In some instances, all cards (Visa, Mastercard, Discover, Amex) fail to provision simultaneously. At other times, the issue appears to be isolated to specific networks while others work correctly.
Crucially, the issue appears to be temporary. After some time passes (ranging from minutes to an hour), we are able to add the exact same card successfully without making any changes to our test environment or configuration.
We have diligently checked our setup to rule out configuration errors on our end. This includes verifying:
The device is set to a supported region.
We are signed in with a valid sandbox tester Apple ID.
All other prerequisites for sandbox testing are met.
The fact that the process works correctly at other times strongly suggests that this is a server-side stability issue within the Apple Pay sandbox environment rather than a persistent misconfiguration on our part.
To help with your investigation, we have attached an image that demonstrates a failed attempt to add a card.
Could you please investigate the stability of the sandbox card provisioning service? Please let us know if this is a known issue or if there is any further information we can provide.
Thank you for your time and assistance.