Hey everyone, hoping someone here has run into this before. I have a fully functional App Clip (com.didyoucatchit.app.Clip) linked to my main app (com.didyoucatchit.app). The Clip builds and runs perfectly, but I’m seeing issues trying to enable Apple Pay for it. When I try to link my Merchant ID under the “On Demand Install Capable” capability in the Apple Developer portal, I get this error: A relationship in the provided entity is not allowed for this request. The relationship 'undefined' can not be included in a 'bundleIdCapabilities' request. Here’s what I have already configured and confirmed: App Clip capabilities in Xcode include: Apple Pay Payment Processing Associated Domains (appclips:app.didyoucatchit.com) Provisioning profile includes: Apple Pay Payment Processing Associated Domains In-App Purchase On-Demand Install Capable Entitlements file for the Clip: <key>com.apple.developer.associated-domains</key> <array> <string>appclips:app.didyoucatchit.com</string> </array> <key>com.apple.developer.in-app-payments</key> <array> <string>merchant.com.didyoucatchit.app</string> </array> <key>com.apple.developer.parent-application-identifiers</key> <array> <string>$(AppIdentifierPrefix)com.didyoucatchit.app</string> </array> Merchant ID (merchant.com.didyoucatchit.app) is active and connected to Stripe Stripe Apple Pay configuration matches the same merchant ID and certificate Both provisioning profiles have been refreshed and downloaded However: The portal still throws the “relationship 'undefined'” error anytime I try to modify the Clip’s capabilities In testing, Apple Pay doesn’t show up as a payment option in the Clip (using Stripe’s Payment Element integration) Questions: Is this a known issue with the Developer portal when linking App Clips to merchant IDs? Is there a specific way to re-establish the parent–child relationship between the main app and the App Clip so the bundleIdCapabilities request includes the proper relationship JSON? Are there any additional configuration steps required when using Stripe for Apple Pay inside an App Clip? System Setup: Xcode: 16.2 (build 16C5032a) macOS: Sequoia 15.3.1 iOS: 18.5 (testing on physical device) Merchant ID: merchant.com.didyoucatchit.app Main App ID: com.didyoucatchit.app App Clip ID: com.didyoucatchit.app.Clip Any help or insight would be hugely appreciated Thanks in advance!

Description: I’m integrating Apple Pay JS (version 3) into an Angular application. Here are the key details: Environment: Angular (latest) Apple Pay JS v3 Chrome (confirmed window.ApplePaySession is available) application region is in US. I'm in Taiwan and using my iPhone Taiwan account to scan the QR Code/ Implemented Handlers: onvalidatemerchant onpaymentmethodselected onpaymentauthorized oncancel Observed Behavior: When I click the Apple Pay button, the console logs: Failed to execute 'postMessage' on 'DOMWindow': The target origin provided ('https://applepay.cdn-apple.com') does not match the recipient window's origin ('https://{our-domain-name}') Despite this, the QR code still appears. Scanning the QR code with an iPhone 13 Pro running iOS 18.4.1 brings up the Apple Pay sheet with the correct amount, but payment never completes. In the browser, none of my Angular event handlers fire except oncancel. Questions: What causes the postMessage origin mismatch with Apple’s CDN frame, and how should my application handle it? Why doesn’t onpaymentauthorized ever fire, and how can I complete the payment flow so that session.completePayment() succeeds? Any guidance or sample code snippets for a proper merchant-validation and payment-completion sequence in this setup would be greatly appreciated. my code onApplePayButtonClicked() { if (!ApplePaySession) { console.error('[ApplePay] ApplePaySession is not supported'); return; } // Define ApplePayPaymentRequest const request : ApplePayJS.ApplePayPaymentRequest = { countryCode: this.currencyCode, currencyCode: Constants.CountryCodeUS, merchantCapabilities: this.merchantCapabilities, supportedNetworks: this.supportedNetworks, total: { label: this.label, type: "final" as ApplePayJS.ApplePayLineItemType, amount: this.orderAmount.toString(), }, }; // Create ApplePaySession const session = new ApplePaySession(3, request); session.onvalidatemerchant = async event => { console.info('[ApplePay] onvalidatemerchant', event); try { const merchantSession = await fetch(`${this.paymentUrl}/api/applepay/validatemerchant`, { method: 'POST', headers: { 'Content-Type': 'application/json', }, body: JSON.stringify({ PKeyCompany: this.paymentAppleMerchantId, ValidationUrl: event.validationURL }) }).then((r) => r.json()); session.completeMerchantValidation(merchantSession); } catch (error) { console.error('[ApplePay] onvalidatemerchant MerchantValidation error', error); session.abort(); } }; session.onpaymentauthorized = (event) => { console.info('[ApplePay] paymentauthorized', event); const token = event.payment.token; this.paymentTokenEmitted.emit({ token: JSON.stringify(token), paymentType: PaymentOptionType.ApplePay }); session.completePayment(ApplePaySession.STATUS_SUCCESS); }; session.onpaymentmethodselected = (event) => { console.info('[ApplePay] paymentmethodselected', event); const update: ApplePayJS.ApplePayPaymentMethodUpdate = { newTotal: request.total }; session.completePaymentMethodSelection(update); }; session.oncancel = (event) => { console.error('[ApplePay] oncancel', event); this.errorEmitted.emit({ error: 'Apple Pay cancel' }); }; session.begin(); }

We have finished integrating Apple Pay in our app and our payment processor is requiring us to send the 3dSecure version used for apple pay (2.1,2.2,2.3,etc.). I believe this only applies to mastercard but would appreciate if anyone has run into something similar and what you specified. I have not been able to find anything in Apple's documentation specifying the version that is used.

Our company sells insurance and we'd like to offer annual renewals via Apple Pay on the Web. Most of the docs seem to point towards using recurringpaymentrequest but this method required an amount value which would only be calculated at renewal time. It appears that Shopify is doing something akin to what we want where they do auto payments so my question is can we do annual payments with unknown renewal prices with Apple Pay for Web ? What we cannot do is show the renewal price like this as it being insurance is almost certain to change. This is our current code which works but won't get past the regulator. const applePayPaymentRequestAnnual = { countryCode: 'GB', currencyCode: 'GBP', supportedNetworks: ['visa', 'masterCard'], merchantCapabilities: ['supports3DS'], requiredBillingContactFields: ['postalAddress', 'email'], requiredShippingContactFields: ['phone'], recurringPaymentRequest: { paymentDescription: 'Annual Insurance Renewal', regularBilling: { label: 'Annual Renewal Premium', amount: price, paymentTiming: "recurring", recurringPaymentIntervalUnit: "year", recurringPaymentStartDate: year + "-" + month + "-" + day + "T00:00:00.000Z", type: 'final' }, managementURL: window.location.protocol + '//' + window.location.host + '/manage-policy', tokenNotificationURL: window.location.protocol + '//' + window.location.host + '/apple-pay-notifications' }, lineItems: [{ label: alabel, amount: price, }], total: { label: alabel, amount: price, type: "final" }, }

Cybersource production support has clarified issue as below "On the BAD Case, it seems that the Apple Payload did not contain the "onlinePaymentCryptogram" object within the JSON. The Cryptogram is critical and mandatory. Since the merchant cannot really control this, and since CYBS is just decrypting the payload and uses it, we cannot comment as to why it was missing. The merchant would need to reach out to Apple and/or decrypt the payment themselves locally to check if and why this data was not present, for troubleshooting purposes."

Cybersource production support has clarified issue as below "On the BAD Case, it seems that the Apple Payload did not contain the "onlinePaymentCryptogram" object within the JSON. The Cryptogram is critical and mandatory. Since the merchant cannot really control this, and since CYBS is just decrypting the payload and uses it, we cannot comment as to why it was missing. The merchant would need to reach out to Apple and/or decrypt the payment themselves locally to check if and why this data was not present, for troubleshooting purposes."

Dear Apple Developer Support, I would like to request a technical escalation to the engineering team regarding an ongoing issue with Apple Pay domain verification. Error returned by Apple Even though Apple’s request to our domain returns HTTP 200, the verification still fails with: resultCode: 13014 resultString: "Domain verification failed. Review your TLS Certificate configuration to confirm that the certificate is accessible and a supported TLS Cipher Suite is used." requestUrl: https://developer.apple.com/services-account/QH65B2/account/ios/identifiers/verifyDomain TLS Certificate Validation We performed a full TLS analysis: Certificate issued by Sectigo Public Server Authentication CA DV E36 (public trusted CA) Full and correct certificate chain No handshake errors Configuration fully valid SSL Labs rating: A From our side, the TLS configuration is confirmed to be correct. Accessibility of the .well-known file The file is publicly and accessible It returns 200 OK and the content is exactly identical to the file downloaded from the Apple Developer Portal, without any modification. Our network team confirmed that Apple’s verification request also receives HTTP 200 when pressing “Verify” in the Apple Developer Console. Network-side findings We monitored Apple’s request in real time. Findings: TLS handshake succeeds No cipher mismatch File delivered correctly Status: 200 OK No redirect or transformation applied Despite this, Apple still returns error 13014. Request for engineering review We kindly request that an Apple engineer verify the following: The actual TLS handshake performed by Apple's verification service (cipher suite, protocol negotiation, SNI, trust chain). Whether the Sectigo issuing CA is fully trusted and supported by your domain-verification backend. If there is an internal reason behind error 13014—since the external message does not provide actionable details. Whether the response is rejected for reasons other than TLS, given that the file is accessible and the request returns 200. The exact condition that leads Apple to report “TLS Certificate configuration is incorrect” in this case. This issue is blocking an urgent deployment and must be resolved as soon as possible. Existing case reference Case ID: 102760005987 We are fully available to provide: full response headers packet captures (PCAP) SSL/TLS diagnostics file integrity checks server configuration details or join a technical call (Teams / WebEx) Thank you in advance for the escalation. Andrea

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.

We have updated the PNO metadata to include the associatedApplicationIdentifiers for our wallet extensions and the issuer app. While we are able to successfully provision the card to Apple Wallet via pull provisioning, we are unable to retrieve the payment passes that have already been provisioned. How can we address this issue? let passLibrary = PKPassLibrary() let paymentPassLibrary = self.passLibrary.passes(of: .secureElement) paymentPassLibrary is an empty array even though we have passes provisioned.

Hello, I'm trying to make changes to my website's apple pay flow and an unable to verify if the flow works because I get the following error in the console when trying to pay: TypeError: undefined is not an object (evaluating 'applePaySession.completeMerchantValidation') By following this error message, I try to setup an ngrok proxy to verify my local development domain and that fails as well even though as you can see, the file does actually exist. Can anyone help with A) giving me a different way to develop locally aka having a "successful" apple pay payment so I can verify my website's flow after payment or B) help me figure out why the domain verification is failing. Thanks!

Hi all, I’m running into a confusing issue with Apple Pay domain verification. Apple’s documentation says to host the verification file at: https://yourdomain.com/.well-known/apple-developer-merchantid-domain-association And the portal itself seems to expect the file to be served with .txt extension during verification. My first verification passed, but subsequent checks are failing — and I’m wondering if this mismatch is the cause. Should I Keep the .txt and configure my server to serve it at both paths? Would appreciate any insights or official clarification. Thanks!

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 are a regulated financial institution and Apple Pay issuer seeking clarification on the in-app push provisioning requirement and the January 15, 2026 timeline. Like many community financial institutions: Our mobile banking app is issuer-branded but provided by a third-party vendor Apple Pay enablement and tokenization are handled by a separate card processor While we support Apple’s goals and understand the issuer is ultimately responsible, delivery of in-app provisioning is dependent on third-party vendor roadmaps and cross-vendor integrations that are outside our direct control. Despite active, good-faith efforts with both vendors, current platform constraints make the January 15, 2026 deadline challenging. We would appreciate clarification on: How Apple evaluates compliance when an issuer’s mobile app is built and maintained by a third party Whether any transitional flexibility or phased enforcement is expected for issuers showing documented progress Whether approved web-based provisioning may be acceptable as an interim option How issuers should document due diligence when vendor dependencies delay implementation Additional guidance would help many credit unions and community banks plan appropriately and remain compliant. Thank you for your guidance.

Hello, Apologies if this has been asked before but I have a website that takes subscriptions and payments through PayPal. It's a platform where authors can sell ebooks and anyone who purchaes an ebook, the money goes pretty much directly from the buyer's PayPal to the seller PayPal through the use of PayPal Multiparty where my platform acts as a third party that takes a fee. I'm currently building a React-Native app for my website and coming close to needing to integrate payment solutions. As far as I'm aware, Apple only allows Apple Pay payments for IAP and subscriptions? How would this work for my model? Can I integrate PayPal into Apple Pay like I do with my website? If not, what's the alternative?

Recently, we completed a merger with our parent company. We are currently integrated with Apple Pay in accordance with the “Apple Pay Payment Processing on the Web” guidelines. Due to the change in the legal entity, we proceeded with the account migration process as outlined below: Creation of a new Apple Developer account and a new Apple Pay Identifier Removal of the Merchant Domain (dc2-web.happy.co.kr) from the existing Identifier Registration of the Merchant Domain (dc2-web.happy.co.kr) under the new Identifier Using the Merchant Domain registered under the new Identifier and the Apple Pay Merchant Identity Certificate issued from the new Identifier, we attempted to obtain an Apple Pay session by sending requests to the following endpoint: https://apple-pay-gateway.apple.com/paymentservices/startSession However, we are intermittently receiving failure responses with an HTTP 400 status code. With regard to these intermittent failures, we would like to inquire whether there is any propagation delay on Apple’s servers when an Apple Pay Identifier is removed and re-registered under a new account, or if there could be any other possible causes for this behavior. We would appreciate your guidance on this matter.

We are facing an issue with Apple Pay address details while customers are placing orders on our production site. By default, the following values are being passed during checkout: First Name: ApplePay Last Name: Express Address: ApplePay Street When we manually enter these same details, our validation correctly prevents the order from being placed and displays an appropriate error message. However, on our production site, real customers are still able to successfully place orders with these exact details. Could you please help us understand: How these orders are being allowed to proceed despite the validation? Is this behaviour expected from Apple Pay ? How can we prevent orders from being placed with such placeholder address details? Please let us know if you need any additional information from our side. We have also attached an image showing the address details and the corresponding order number for reference. Thanks in advance for your support.

We are implementing Apple Pay on our website, but we only sell services and would prefer that the shipping address section of the Apple Pay modal doesn't require the shipping address and just show the billing address. Is there any way to achieve this?

I’m having an issue verifying a domain for a Merchant ID. I’m implementing Apple Pay on the web for a demo, and I’ve configured the Azure server to match Apple’s requirements for domain verification, such as the TLS configuration, not requiring client certificates, and ensuring there are no redirects. I’ve run tests with OpenSSL and PowerShell and all responses return HTTP/1.1 200 OK. I also tested the URL Apple says it uses to validate the file under .well-known, and it does show the expected result. I already have the Apple Pay Payment Processing Certificate and the Apple Pay Merchant Identity Certificate approved; the only thing missing is the domain verification. I’m not sure what else to test—if you could help me with a possible solution, I’d really appreciate it. (The project is built in .NET 8 and hosted on Azure App Service.)

Hi, Somebody knows how to decode / decrypt emvData on Apple Pay e-commerce when paymentDataType=EMV? Thanks. Reference: https://developer.apple.com/documentation/passkit/payment-token-format-reference#Detailed-payment-data-keys-EMV

Hello, We are implementing Apple Wallet extensions (PKIssuerProvisioningExtensionHandler). While our UI extension works as expected, our Non-UI extension is unable to detect payment passes provisioned by our app. Specifically, PKPassLibrary().passes(of: .secureElement) returns an empty array when called from the Non-UI extension, even though the same call correctly returns the passes when executed from the Main iOS App. Our Payment Network Operator has confirmed that our extension bundle identifiers are correctly registered in the metadata on their side. They suggested that the Wallet Extensions entitlement (com.apple.developer.payment-pass-provisioning) may require additional backend enablement for these specific Extension App IDs. Is there a known reason why PKPassLibrary would behave differently in the Non-UI extension vs the Main App? Beyond the standard entitlement request, is there a specific process to "activate" these IDs for extension visibility? Does anyone have guidance on reaching the appropriate team for backend entitlement activation issues? Any insights would be greatly appreciated.