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

Apple Pay for Partners brings together the latest news, features, and fraud protection information for issuers, merchants, and platforms — all designed to support your integration and help you deliver the payment experience customers know and trust. Available in English only. Explore Apple Pay for Partners >

We are an acquirer and PSP and we are building our Apple Pay on the Web integration, starting in India. Please tell us what is needed to enable merchants in other countries like Singapore, Hongkong, New Zealand, etc. Does one Platform Integrator ID and one set of certificates cover merchants in all countries? Which country code should the payment request carry for a merchant whose acquirer processes in a different country? Are there per-country requirements for networks, currencies or issuer participation that affect acceptance? Is there a published list of countries where the Registration API model is supported? Is any separate onboarding with Apple required per country?

We are an acquirer and PSP with our own payment gateway. Merchants can either: Use an Apple Pay payment page hosted by us, or Host their own payment page and submit payment data to us via server-to-server APIs. We are currently implementing Apple Pay on the Web using the Platform Integrator model. The acquirer-hosted payment page flow is clear to us, but we have a few questions regarding merchant-hosted payment pages. Our current understanding (please correct us if any of this is incorrect) We register each merchant using the Web Merchant Registration API as a Platform Integrator, with a unique partnerInternalMerchantIdentifier. Merchants do not have their own Apple Developer accounts. For merchant-hosted payment pages, the merchant's checkout domain is provided in domainNames. The domain verification file is downloaded from our Apple Developer account (Platform Integrator account), and the merchant hosts that file under the /.well-known/ path on their domain. The merchant registration created through the Web Merchant Registration API is then used for Apple Pay eligibility checks and merchant validation. Questions: Domain registration For a merchant-hosted payment page, is it correct to register the merchant's domain against that merchant's partnerInternalMerchantIdentifier registration? Verification file When onboarding multiple merchants: Is the same domain association file used across all merchant domains? Or is a unique verification file generated per merchant registration? Eligibility checks and Apple Pay button The "Supporting Apple Pay on Third-Party Browsers" documentation (Scenario 3) suggests that a payment service provider may provide a JavaScript library that loads apple-pay-sdk.js for merchants. For merchant-hosted pages, is it supported and recommended for the PSP/platform integrator to provide a thin wrapper library around: canMakePayments() applePayCapabilities() Apple Pay button rendering Session creation Or is Apple’s preferred approach that the merchant's checkout page interacts directly with Apple Pay JS APIs? PSP/acquirer decrypts the payment token If the PSP/acquirer is responsible for token decryption, we understand that encryptTo should be set to the Platform Integrator identifier. For merchant-hosted payment pages, are there any additional requirements beyond domain registration and merchant validation? Merchant decrypts the payment token We would also like to support a model where the merchant decrypts Apple Pay tokens directly. In that case, our understanding is that encryptTo must reference the merchant's identifier rather than the Platform Integrator identifier. Is that understanding correct, and are there any additional onboarding or registration requirements for that model? Merchant validation For merchant-hosted checkout pages, what is the expected implementation pattern for onvalidatemerchant? Specifically: Should the merchant's frontend send the validationURL to the PSP/platform integrator backend, which then performs merchant validation with Apple and returns the merchant session? Or is a different flow expected when using the Platform Integrator model? Any clarification or guidance would be greatly appreciated. Thank you.

This is a rare occurrence on our site, having only detected 4 instances of it over the past few weeks, where 10s of thousands of transactions have occurred successfully. We only call the following PaymentRequest API onClick from the <apple-pay-button>: async function startApplePay(merchantIdentifier, amount) { ... try { const request = new PaymentRequest([ applePayMethod ], paymentDetails); ... catch (e) { // cancel, just stay here if (e.name === "AbortError") { if (consoleLog) console.log("Payment canceled", e); logServer("INFO", "Payment canceled"); } else { handleError("Error caught: " + e.name + ", " + e.cause + ", " + e.message); } } Where the "handleError" else case is what gets triggered: Error caught: SecurityError, undefined, show() must be triggered by user activation. All 4 instances have been from iPads, but with that small of a sample size, we can't tell whether that's relevant or coincidence. Different iOS versions, but looks like same Safari version. Here are the 4 User Agents we've seen thus far: Mozilla/5.0 (iPad; CPU OS 18_2_1 like Mac OS X) AppleWebKit/605.1.15 (KHTML, like Gecko) GSA/352.0.715618234 Mobile/15E148 Safari/604.1 Mozilla/5.0 (iPad; CPU OS 17_6_1 like Mac OS X) AppleWebKit/605.1.15 (KHTML, like Gecko) GSA/352.0.715618234 Mobile/15E148 Safari/604.1 Mozilla/5.0 (iPad; CPU OS 18_3_0 like Mac OS X) AppleWebKit/605.1.15 (KHTML, like Gecko) CriOS/133.0.6943.33 Mobile/15E148 Safari/604.1 Mozilla/5.0 (iPad; CPU OS 18_2_1 like Mac OS X) AppleWebKit/605.1.15 (KHTML, like Gecko) CriOS/133.0.6943.33 Mobile/15E148 Safari/604.1

I am a PSP for Apple Pay, and I have been experiencing timeouts while registering a domain for my merchant. What configurations should my merchant make?

Hi, We recently applied for the Web Merchant Registration API and created our platform integrator ID. I am trying to register a domain in sandbox with the API: POST https://apple-pay-gateway-cert.apple.com/paymentservices/registerMerchant Content-Type: application/json { "domainNames": ["<URL>"], "partnerInternalMerchantIdentifier": "<merchant_id>", "partnerMerchantName": "<merchant_name>", "encryptTo": "<platform_integrator_id>" } Client certificate is provided via curl --cert/--key; the TLS 1.3 handshake completes successfully — the server requests the client cert, our Certificate + CERT verify are accepted, and the connection is established. But the response is { "statusMessage": "Payment Services Exception Unauthorized", "statusCode": "401" } How do I go about debugging this?

We are unable to verify our Apple Pay merchant domains. Apple Developer Portal returns: “Domain verification failed. Review your TLS Certificate configuration to confirm that the certificate is accessible and a supported TLS Cipher Suite is used.” We have confirmed that the verification endpoints are publicly accessible, return HTTP 200, and support TLS 1.2/1.3 with valid certificates and supported cipher suites. The domains are behind Cloudflare. However, when verification is triggered, we do not see an HTTP request from Apple in our Cloudflare request logs. Has anyone experienced a similar issue with Apple Pay merchant domain verification, especially with domains behind Cloudflare? We have also submitted a report through Feedback Assistant.

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.

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.

I've implemented Apple Pay payments in my website. I'm using live environment and real card and not the sandbox. Everything works fine till the last step. When I have to make payment it does not show the pay button or Pay with Touch ID option on Apple paysheet.

Environment macOS 26.5.1 (Build 25F80) Safari 26.5 Apple Pay JS API version 8 Using https://applepay.cdn-apple.com/jsapi/v1/apple-pay-sdk.js Reproduces on the staging website (Does not reproduce on the production website with non sandbox account) Signed into a Sandbox Tester Apple ID, with a test credit card registered exactly per Apple Pay Sandbox Testing — this is the only card in Wallet on the laptop Merchant validation is performed by our staging backend against our real (non-sandbox) merchant identity/certificate — i.e. a sandbox tester card being evaluated against a staging merchant session, which per the sandbox testing documentation is the expected/supported setup for testing on a live site without a separate merchant sandbox environment Summary After completeMerchantValidation() succeeds and the merchant session is accepted, the payment sheet still terminates with PKPaymentAuthorizationStateFatalError a few hundred milliseconds later, right after the native side logs a second "Evaluating merchant session using PROD trust policy." for the same session. The user sees "Payment failed" and the sheet closes. This happens on the very first attempt, with no user interaction beyond tapping the Apple Pay button — no shipping address is even selected before the failure. Since the sandbox tester card + production merchant session combination is the setup the sandbox testing guide describes, we'd expect the sheet to proceed to onpaymentauthorized (Apple's sandbox docs describe payments as being processed as $0 test transactions in this mode) rather than fail natively before that stage is ever reached. Steps to reproduce Visit an item page with an Apple Pay button. Tap the Apple Pay button to open the payment sheet. The sheet presents normally; no interaction with shipping address or payment method is required for the failure to occur. Within ~1 second, the sheet dismisses and displays a "Payment failed" error state. Minimal reproduction of the JS side const session = new ApplePaySession(8, { countryCode: 'US', currencyCode: 'USD', supportedNetworks: ['visa', 'masterCard', 'amex', 'discover'], merchantCapabilities: ['supports3DS'], total: { label: 'Merchant', amount: '10.00' }, }); session.onvalidatemerchant = async () => { const merchantSession = await validateMerchantOnServer(); // succeeds session.completeMerchantValidation(merchantSession); // accepted — see log below }; session.onpaymentmethodselected = () => { session.completePaymentMethodSelection({ newTotal: { label: 'Merchant', amount: '10.00' }, }); }; session.oncancel = event => console.log('cancelled', event); session.begin(); We reproduced this with both our full checkout implementation and this stripped-down request object (no shipping contact required, no line items) — same failure either way, which rules out anything about our order/line-item data. What we expected The sheet to proceed to the biometric authorization step and dispatch onpaymentauthorized once the user confirms. What actually happens The sheet fails immediately with a PKPaymentAuthorizationStateFatalError transition, even though every JS-side completion call (completeMerchantValidation, the payment-method selection) succeeded and returned PKPaymentAuthorizationStatusSuccess. System log (captured via log stream --info --debug --predicate 'process == "Safari" OR process == "passd" OR process == "com.apple.PassKit.PaymentAuthorizationUIExtension"') 21:50:41.544 PaymentCoordinator::beginPaymentSession() -> 1 21:50:41.570 Received prepareWithPaymentRequest: <private> 21:50:42.297 PaymentCoordinator::validateMerchant() 21:50:42.563 PaymentCoordinator::completeMerchantValidation() 21:50:42.564 Received merchant session update with status:PKPaymentAuthorizationStatusSuccess session:<private> 21:50:42.564 Evaluating merchant session using PROD trust policy. <- 1st occurrence, passes 21:50:42.572 PaymentCoordinator::didSelectPaymentMethod() 21:50:42.572 PaymentCoordinator::completePaymentMethodSelection() 21:50:42.653 Evaluating merchant session using PROD trust policy. <- 2nd occurrence 21:50:42.656 State machine change state from ClientCallback to PrepareTransactionDetails with param: <private> 21:50:43.391 Task Completed: <private> 21:50:43.393 State machine change state from PrepareTransactionDetails to PKPaymentAuthorizationStateFatalError with param: <private> 21:50:43.393 Error Payment failed with fatal error <private> 21:50:45.130 PaymentCoordinator::didCancelPaymentSession() The first "Evaluating merchant session using PROD trust policy." line passes (the flow continues to didSelectPaymentMethod). The second occurrence is immediately followed by Task Completed and then the FatalError transition, which suggests PassKit re-validates the merchant session's trust a second time right before PrepareTransactionDetails, and that second check is what's rejecting the session — even though the identical session object was accepted moments earlier at completeMerchantValidation(). What we've tried / ruled out Confirmed every JS completion method (completeMerchantValidation, completePaymentMethodSelection) is called and returns success — no 30-second timeout, no missing completion call, no thrown exception on our side. Reproduced with a minimal, hardcoded ApplePayPaymentRequest (fixed $10.00 total, no shipping fields) — rules out anything about our real order/line-item/sales-tax data. Reproduced on the main branch and independently on our staging deployment running unmodified code — rules out anything specific to our recent frontend changes. The <private> redaction in the system log prevents us from seeing what specifically fails during the second trust evaluation. Confirmed the sandbox tester card and its registration follow the sandbox testing guide exactly — it's the only card on the device, and no other Wallet cards are involved. Question What does PassKit's second "Evaluating merchant session using PROD trust policy" check (immediately before PrepareTransactionDetails) actually validate, beyond what's already checked at completeMerchantValidation() time? Is a sandbox tester card being evaluated against a production merchant session expected to pass this second check, or does sandbox testing per the linked guide require something additional on the merchant/session side (e.g. a specific field on the merchant session, or a specific environment value) that our backend isn't setting? Is there a way to get an unredacted reason for the rejection — e.g. via a private-data-enabled log profile or another diagnostic — since the redacted system log alone doesn't surface one?

Hello. We are an acquirer and we have timeouts in about 7-8% of requests to https://apple-pay-gateway.apple.com/paymentservices/paymentSession in the last 30 minutes since 07:00 EET. Our timeout is 60 seconds. We've checked and don't see any issues on our side. There were no changes in our infrastructure setup.

We manage provisioning for a large number of App IDs across multiple apps via CI, using the App Store Connect API (not session-based Spaceship/Xcode auth). Capability management works well end to end for everything we've tried — Push Notifications, App Groups, Associated Domains, Data Protection, etc. can all be created, updated, and deleted via POST/PATCH/DELETE on /v1/bundleIdCapabilities. Apple Pay is the one exception. We can enable the Apple Pay capability itself via the API the same way as anything else, but there's no way to associate that capability with a specific Merchant ID. /v1/merchantIds exists as its own resource, but nothing in the bundleIdCapabilities or bundleIds schema links to it — no relationship, no include, no dedicated endpoint. In practice this means every new Apple Pay-enabled App ID we provision needs someone to go into the Developer Portal by hand (Identifiers → App ID → Capabilities → Apple Pay → select Merchant ID) before the generated provisioning profile will actually build — otherwise Xcode fails with errors like "doesn't include the Apple Pay capability" / "doesn't support the Merchant ID". Every other capability we use is fully scriptable; this is the one manual step left in an otherwise automated pipeline. Has anyone found a documented (or undocumented) way to do this via the API? If this is a confirmed gap rather than something we're missing, I've filed it as FB24414090 — if you've hit the same thing, adding your own Feedback number to a report on the same gap seems to be one of the few things that actually helps get traction internally, so feel free to reference this thread if you file one too.

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.

Posting this here because I lost way too many hours on it and hopefully someone finds this before going down the same rabbit hole. Apple Support's support was basically asking me to check the docs and this forum for solutions. I guess it's better than saying "google it yourself", but not much better ;) The issue was that Apple Pay merchant domain verification kept failing, both automated and manual. I checked pretty much everything: domain association file HTTPS DNS TLS App Service configuration Merchant ID openssl verification The interesting part was that everything looked perfectly healthy. Browsers were happy, OpenSSL reported Verify return code: 0 (ok), and there were no TLS errors. Turned out the problem was Apple's verification mechanism incompatibility with the new Generation Y cert chain, which is used as default by Let's Encrypt. My site was using a Let’s Encrypt ECDSA certificate with this chain: → YE1 → Root YE → ISRG Root X2 I reissued it as RSA (still Let’s Encrypt), which resulted in: → YR2 → Root YR → ISRG Root X1 Apple Pay domain verification started working immediately. If you’re using Certbot: sudo certbot certonly --manual --preferred-challenges http --key-type rsa --rsa-key-size 2048 --force-renewal --cert-name yourdomain.com -d yourdomain.com I don’t know whether Apple Pay currently has an issue with Let’s Encrypt’s newer Generation Y ECDSA hierarchy, or whether something in their merchant validation infrastructure doesn’t like that chain. If you’ve already checked the usual stuff and everything looks correct, this is definitely worth trying before spending another day debugging.

Hello, I', are trying to add applepay payment on our website using the PSP payxpert. They don't provide any SDK to my knowledge unlike paypal/stripe and their documentation just tell to send a few different data as usual credit card payment. But I'm stuck even before that step, we were able to add the applepay button on the site, we did setup the sandbox account on the iPhone with a test card. We could add the merchant id, created the "Apple Pay Payment Processing Certificate", the "Apple Pay Merchant Identity Certificate" and we verified the marchant domain. We have our backend request the validationURL on onvalidatemerchant. We're using PHP, and send the data in json as the example in: https://developer.apple.com/documentation/ApplePayontheWeb/requesting-an-apple-pay-payment-session The validation url we receive from applepaysession js is: https://apple-pay-gateway-cert.apple.com/paymentservices/startSession The doc mentions to add /paymentSession so I tried that as well as just the raw validationURL. Both sends me a 401 Unauthorized response. I'm not sure what missing, I double checked the merchantIdentifier matches and that the initiativeContext is correct, but no luck. I wonder if we missed a step in the configuring the server, as it say to create certificate and upload them. Then we can download the .cer files, do we need to do something with that? Kind regards

Hi! We recently signed up and activated the Web Merchant Registration API and registered a few of our merchants. We registered them as: { "domainNames" : ["X"], "partnerMerchantName" : "Name", "partnerInternalMerchantIdentifier": "MID-###", "encryptTo" : "platformintegrator.X", "merchantUrl": "https://www.x" } When we make the payment with startsession, we are getting an error 400: Payment Services Exception merchantId=platformintegrator.x not registered for domain=x I suspect that this has to do with the value of merchantIdentifier we are setting in the startsession. What should it be? MID-###? The encryptTo hash of platform? platformintegrator.x? Also, what's the meaning of the property on the sub-merchant I get from the GET API call delegatedCommerce: {enabled=True}?

We are currently supporting an Apple Pay-enabled card program as an issuer/issuer processor and have successfully completed In-App Push Provisioning integration within our iOS application. The in-app flow is fully operational, including issuer-side cryptographic exchange and Mastercard MDES network tokenization. We are now looking to extend this integration to support Apple Pay Web Push Provisioning, allowing cardholders to add eligible cards to Apple Wallet directly from our web application. We would appreciate guidance on: -The process for enrolling in Apple Business Register (if required) -Enabling Web Push Provisioning for an issuer profile Required entitlements or provisioning certificates Any additional onboarding steps specific to issuer-level Web provisioning We understand that Web Push Provisioning requires issuer-level enablement beyond standard Apple Pay on the Web, and we would like clarification on the correct path to activate this capability. Thank you in advance for your guidance.

Our client's site uses Apple Pay, and once a month we get a series of email notifying us that the domain verification is about to expire: Your website domain that uses Apple Pay has an SSL Certificate that expires on Oct 11, 2020. We were unable to automatically to reverify your domain. To ensure uninterrupted use of Apple Pay on your website, revalidate your domain by Oct 11, 2020 in Certificates, Identifiers & Profiles. The site uses Let's Encrypt to automatically renew its SSL cert monthly. Every time that happens, we need to log into the Apple Developer tools, navigate to Certificates, Identifiers, and Profiles -> Identifiers -> Merchant IDs -> ID -> Merchant Domains, then download the file and drop it onto the server with SFTP. It's a pain. Is there a way to automate this process (or better yet, stop it from happening)? I can't imagine monthly-renewing SSL certificates is a particularly uncommon thing.

Hi everyone, We are integrating Apple Pay on the Web, and we're trying to get the automatic renewal of the domain verification working according to the documentation: https://developer.apple.com/documentation/apple_pay_on_the_web/maintaining_your_environment Initially the domain verification is successful, but then the automatic renewal does not work. We keep getting the emails with the subject "Your domain will expire soon.", but they only say "We were unable to automatically to reverify your domain." without any further details. We confirmed that the site's SSL certificate has already been renewed by the time Apple attempted the renewal of verification, the certs are renewed 30 days before their expiry (using Let's Encrypt). So according to the docs, at least the renewal attempts 15, and then 7 days before the expiry should be successful. One example domain is this one: https://www.kayak.com/.well-known/apple-developer-merchantid-domain-association.txt, but we have the same issue for all our other domains as well. Does anyone have suggestions how to troubleshoot this further? (I tried creating a support ticket, but they basically replied that they're non-technical, and just linked me to the documentation. I've seen others complaining about this too, but couldn't find a conclusive solution, so I thought I'd signal boost and create a fresh topic to see if there are any more recent findings about this problem.) Thanks! Regards, Mark