Hi Apple Team and Developers, I’ve been testing the Top-up flow in our app via the TestFlight environment. Across multiple devices (around 10 tested), everything works fine with no issues. However, on one specific device — iPhone 14 Pro Max running iOS 18.6.2 — I’ve noticed an intermittent issue: When performing a Top-up, the Apple UI first shows a successful purchase confirmation. Immediately afterward, another UI prompt appears asking the player to re-enter their Apple ID password. At the same time, Apple returns a ghost string that we cannot use to verify the user’s package bundle ID. This creates potential confusion for users, as they see both a success confirmation and an unexpected password prompt. I’m unsure if this behavior is expected or if there’s a recommended way to handle or prevent this issue. Has anyone else encountered something similar, or does Apple have a suggested fix/workaround for this? For reference, here’s a short video of the issue in action: \🔗 https://drive.google.com/file/d/1Ml-QpEu4ocoxn-W3wEMsFMbXy2QdwbHB/view?usp=sharing Any guidance would be greatly appreciated. Thank you for your support!

Hi, For one of my projects, I am using the Web Drop-in component of Adyen PSP on a Salesforce B2B Commerce site. One of the payment methods is Apple Pay. The payment method is rendered, but the Apple Pay button is not clickable. We tried debugging it but could not identify the root cause. Could you advise how this issue can be fixed? Thanks

Hi, I'm developer in fintech company, we have setup process for onboarding merchants for our partner and processing payments with usage of Apple Pay API. Daily system is processing ca. 10k payments but every day ca. 100 of transactions are declined because of merchant validation error: request to https://apple-pay-gateway.apple.com/paymentservices/paymentSession (with all required parameters in body) is returning response with status code 417 "statusMessage": "Payment Services Exception merchantId={root merchant id} unauthorized to process transactions on behalf of merchantId={merchant id hash} reason={merchant id hash} is not a registered merchant in WWDR and isn't properly authorized via Mass Enablement, either." Issue impacts recurring merchants, most of their transactions are processed successfully but randomly some of them are failing with such reason. All prerequisites are met: merchant have deployed 'apple-developer-merchantid-domain-association' certificate, certificates are valid and not expired. Apple Support is not able to provide any information based on provided requests timestamps. We would to know what may be the reason just part of the requests are failing and what 417 error code means.

I am implementing apple pay and the merchant validation is failing with error (error request failed with status code 417). I am using react js in the frontend and node js in backend, this is my code const httpsAgent = new https.Agent({ rejectUnauthorized: false, cert: fs.readFileSync( path.join(__dirname, "../../../certificates/merchant_id_prod.pem") ), key: fs.readFileSync( path.join(__dirname, "../../../certificates/merchant_id_prod.key") ), }); const data = { merchantIdentifier: "merchantId", displayName: "Check", initiative: "web", initiativeContext: "domain.com", }; const response = await axios.post(validationURL, data, { httpsAgent });

We are working with two types of wallet passes. Provisioning works successfully for one pass type via wallet extensions, but the same process is not functioning for the other. For the second pass type, we are able to generate the required data for pull provisioning and send it to Apple. Additionally, in-app push provisioning for this pass type completes without issue. We would appreciate guidance on how to further debug and resolve this provisioning problem.

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.

Hello! We use Apple's "master account" scheme to register new clients trough API due to the fact that the number of merchant IDs in a developer account cannot exceed 100 records. It's been almost a year since we successfully used the master account ( ex. "merchant.com.xxx") and register clients via Postman. At the moment, the certificates for the master merchant ID start to expire on July 11 which will affect all customers which is under Master ID. We know that when updating certificates at the identifier level(our master id), new universal identity certificate files that we use to send to the merchants (merchant_id.pem, privkey.key) will be generated for authentication on the merchant side, as well as a new keystore. Since many of our clients are integrated with current files and keystores and have live traffic, we would like to know—is it possible to update certificates on the master account without changing the keystores and certificate identities? The impossibility of this will entail a large gap when switching to new certificates. Thanks in advance for your answer.

Hello. I have a few questions about the implementation of Apple Pay payments on websites. Could you help me From the documentation: Apple Pay issues an Apple Pay Merchant Token if the user’s payment network supports merchant-specific payment tokens. Otherwise, Apple Pay issues a device token for the payment request. How can we determine whether a token is a merchant token or a device token? Is it possible to determine this by any of the token fields? https://developer.apple.com/documentation/passkit/payment-token-format-reference Is it possible to understand this in other ways? Can I make recurring payments with the device token if it was issued instead of the merchant token? Is it necessary to include the tokenNotificationURL when generating a merchant token, or can we generate one without specifying it? What does the applicationExpirationDate field in the merchant token represent? Is this the date when the device token or merchant token expires and payments cannot be made with it?

Hi, To ensure the issue is not caused by an error within your app or web service request, please review the following documentation: Wallet Passes Wallet Developer Guide 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 Wallet profile on your iOS or watchOS device. 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. Create a Feedback Assistant report with the following information: The serial number of the device. Open Settings > General > About > Serial Number (tap and hold to copy). The SEID (Secure Element Identifier) of the device, represented as a HEX encoded string. Open Settings > General > About > SEID (tap and hold to copy). The sysdiagnose gathered after reproducing the issue. The .pkpass file(s), pass signing certificate(s) and pass type identiifier(s) (optional). 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 pass type identifier 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 Wallet pass implementation. 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

Hello, We are working on integrating billing into our dating app, targeted at the Russian market. Our main requirement is to support subscriptions with automatic renewal and cancellation. We understand that, according to App Store Review Guideline, all digital subscriptions should use Apple In-App Purchase (IAP). However, we are unsure how this applies in Russia, where some local regulations may limit the use of non-Russian payment processors, and where not all Russian bank cards are accepted by Apple. Our question is: -For iOS apps in Russia, is it strictly required to use Apple IAP for subscriptions? -Are there any approved exceptions allowing integration with local processors such as Robokassa or YooKassa? -How are other developers currently handling subscriptions for the Russian market? We want to ensure full compliance and avoid any risk of rejection or removal. Thank you in advance for any clarification. Best regards, Dan

I'm seeking clarification on how Requirement 4.1 ("Card Issuers with a Mobile App must support In-App provisioning") applies when the card issuer uses a third-party mobile banking platform rather than a self-developed app. Our situation: We are a small credit union (the card issuer) Our mobile banking app is provided by a third-party digital banking vendor (white-label, but branded with our name) Card processing is handled by a separate vendor The ambiguity: The Apple Pay Specifications define "Card Issuer Mobile App" as: "The Card Issuer-branded, iOS software application made available on a Device that is used by such Card Issuer's customers to manage, administer, or use Cards." Our mobile banking app meets this definition—it's branded with our name and used by our members to manage their accounts and cards. However, we don't develop or directly control the app; our digital banking vendor does. The webinar FAQ stated: "Do we have to implement in-app provisioning? Yes, if you have an app." Our digital banking vendor interprets this as not applying to them because they are "not the issuer." They've stated: "Apple's requirements are at the card-processor level... our credit unions and, by extension, we are not required to support Apple Pay's in-app provisioning." Our card processor has indicated they will support in-app provisioning integrations but notes "this would be digital provisioning and we would need the digital banking vendor to work with us to enable." Specific questions: When a card issuer uses a third-party mobile banking app (branded for the issuer but developed/maintained by a vendor), does Requirement 4.1 apply? If yes, who bears compliance responsibility—the issuer, the mobile app vendor, or both? If the mobile app vendor does not implement in-app provisioning by January 15, 2026, what is the issuer's exposure? Does the issuer face suspension from the Program due to vendor non-compliance? Is there an alternative compliance path under Requirement 4.8 (Web Provisioning) for issuers whose mobile app vendors cannot deliver in-app provisioning by the deadline? This scenario likely affects hundreds of small financial institutions using shared digital banking platforms. Clarity on vendor vs. issuer responsibility would help the entire ecosystem prepare appropriately. Thank you.

We have been informed by a third-party subscription tracking service(Adjust) that, due to the following specification of App Store Connect, it is not possible to connect an STG app (a non-published testing app) with their server: Specification: Since Apple’s API only allows access for apps that are already published, it is not possible to enable subscription tracking for iOS apps that are not yet published. Could you please confirm if our understanding of this specification is correct? Additionally, is there any method or recommended approach to verify subscription tracking behavior with an STG (non-published) app before the app is released? Thank you very much for your support.

After opening the Apple Pay Popup and try to close the popup (without scanning the QR Code), the oncancel handler (accociated with the created session) doesn't fire. Meanwhile if the merchant scanned the QR code and the UI of the popup changed, then cancel the popup manually (using close (X) button), it fires the session.oncancel event handler. Here is applied setup: const { ApplePaySession } = window; if (!(ApplePaySession && ApplePaySession.canMakePayments())) { return new Error('Apple Pay Session is not available'); } const paymentCapabilities = await ApplePaySession.applePayCapabilities( applePaymentOptionsMetaData.merchantIdentifier, ); if (paymentCapabilities.paymentCredentialStatus === 'applePayUnsupported') { console.error('ApplePaySession is not supported.'); return; } const request = { "countryCode": "KW", "currencyCode": "KWD", "merchantCapabilities": [ "supports3DS" ], "supportedNetworks": [ "VISA", "MASTERCARD" ], "billingContact": { "phoneNumber": "201000000000", "emailAddress": "example@test.com", "givenName": "Ahmed", "familyName": "Sharkawy" }, "total": { "amount": "3.085", "label": "Merchant Testing" } } const session = new ApplePaySession(5, request); session.onvalidatemerchant = async event => { if (debug) { console.info('Creating merchant session and validating merchant session'); console.info('onvalidatemerchant event', event); } try { // Validation Merchant Request session.completeMerchantValidation(data); } catch (error: any) { session.completePayment({ status: ApplePaySession.STATUS_FAILURE }); } }; session.onpaymentauthorized = async (event) => { session.completePayment({ status: ApplePaySession.STATUS_SUCCESS }); }; // This doesn't fire session.oncancel = () => { console.info('EVENT: oncancel'); }; session.begin();

Hey everyone, I wanted to check if anyone else has faced extreme delays when requesting access to Apple Pay Wallet APIs. It was Oct 11 2024 a year ago since we first applied to enable in-app provisioning for virtual cards in our app and we made 1% progress. For context, we already got access from Google for Google Wallet—it was smooth, professional, and timely. But with Apple… it’s been nothing but an endless cycle of waiting. We followed every step, submitted everything correctly, and even called Apple Developer Support multiple times. Their response? "We've escalated it." Again and again. But there’s no real progress. We’re rerouted, ignored, and left in limbo. At this point, I don’t even know if anyone is actually reviewing these requests. If a business like ours—fully compliant and ready to integrate—can’t even get a response in 150 day, how is this process supposed to work? I’m posting this here because I can’t be the only one. Has anyone else faced this? If you finally got access, how did you do it? Because right now, it feels like Apple Pay in-app provisioning is an impossible goal. Hoping someone from Apple sees this and realizes how broken this process is. We’re just trying to innovate and offer Apple users a great experience—why is it so difficult? Looking forward to hearing from anyone in the community who can help, Thanks! 🙏

Hello! We are using "Apple Pay Web Merchant Registration API" https://developer.apple.com/documentation/applepaywebmerchantregistrationapi Recently we successfully updated the Payment/identity certificates at our main merchant ID And we have a few questions: Do we need make the Domain verification for all of our sub-merchants again after the Certificates update? How we can check the expiration of domain verification of merchants that we integrate trough API endpoint (https://apple-pay-gateway.apple.com/paymentservices/registerMerchant), and do verified domains via API have an expiration date??? How we can understand does the our universal domain verification file (apple-developer-merchantid-domain-association) have expiration too? Thanks in advance!

Hi, You're here because you've had issues with your implementation of Wallet 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

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

Hi, I’ve been trying to integrate Apple Pay, but for some reason, the payment button is not showing up. The project is built with Laravel 11 and Vue. I imported the script as follows: <script crossorigin crossorigin src="https://applepay.cdn-apple.com/jsapi/1.latest/apple-pay-sdk.js" ></script> Then I added the following the steps: <style> apple-pay-button {{ --apple-pay-button-width: --apple-pay-button-width: 150px;; --apple-pay-button-height: --apple-pay-button-height: 30px;; --apple-pay-button-border-radius: --apple-pay-button-border-radius: 3px;; --apple-pay-button-padding: --apple-pay-button-padding: 0px 0px;; --apple-pay-button-box-sizing: border-box; } </style> <apple-pay-button buttonstyle="black" type="plain" locale="en-US"></apple-pay-button> I followed all the steps from the official Apple Pay demo: https://applepaydemo.apple.com/ I also configured the Content Security Policy (CSP) to allow all necessary resources. However, when I test my integration, the button doesn’t appear. I’ve checked the console, but there are no errors. At the same time, I have my certificate imported into the Keychain, and I’ve completed the entire process of creating both the certificate and the private key. However, when I try to validate the session using the certificate and key with Apple’s API, I get an error: 400 The SSL certificate error https://apple-pay-gateway-cert.apple.com/paymentservices/

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

To perform the integration, it must be done under the same domain that has been validated. Is it not possible to do it in a local environment? Could that be the reason why I can't display the button or complete the validation with the API?