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.

Hi, we are setting up Apple Pay on our website which sells only digital goods. We don't collect a shipping address because we aren't shipping anything. We want to use the user's billing address in order to show them the total amount (including sales tax) before they authorize the purchase. However, it seems that the billing address isn't always provided by Apple Pay before the payment is authorized. With Apple Pay, what is the recommended way of acquiring the user's billing address before they authorize the purchase? -- More details about our setup: We are using the Apple Pay JS API. In createPaymentRequest, we specify requiredBillingContactFields: ['postalAddress'], but per the docs, the address is provided after the user authorizes the transaction. That is too late for us because we want to show the sales tax before the user authorizes the purchase. We have attempted to work around this by getting the billing contact details in session.onpaymentmethodselected. For example: session.onpaymentmethodselected = function (event) { const billingContact = event.paymentMethod.billingContact; // Sometimes `billingContact` exists, but other times it does not } This doc states: Before the user authorizes the transaction, you receive redacted billing contact information in a callback event. The redacted information includes only the necessary data for completing transaction tasks, such as calculating taxes or shipping costs. But in practice, we've observed that sometimes no billing contact information is provided. When a user switches from one card to another, we seem to never get the billing contact associated with the newly selected card. Is there something we're missing?

We are integrating Apple Pay In-App Provisioning in our banking application using an external SDK. The provisioning flow works on the iOS Simulator (mock sheet appears), but fails on real devices via TestFlight with the error: internalInconsistency: "PKAddPaymentPassViewController can not be created" Environment: Xcode 16 iOS 18 Real device: iPhone (tested via TestFlight / Distribution build) Card network: Mastercard What we've verified: com.apple.developer.payment-pass-provisioning entitlement is set to YES in our .entitlements file The entitlement is confirmed present in our Development provisioning profile via security cms -D -i embedded.mobileprovision | grep payment-pass → returns <true/> PKAddPaymentPassViewController.canAddPaymentPass() returns true on the device The card is NOT already in Apple Wallet (0 local/remote Secure Element passes) All provisioning data is present and valid (encryptedPayload, authorizationCode, primaryAccountSuffix, cardholderName) The external SDK is configured successfully at app launch Diagnostic logs from TestFlight build: canAddPaymentPass: true Local SE passes: 0 Remote SE passes: 0 suffix: 6165 name: [redacted] encryptedPayload length: 1130 authCode length: 514 scheme: Mastercard Card already in Wallet: false Error: internalInconsistency("PKAddPaymentPassViewController can not be created") Testing matrix: Environment Result Simulator Mock sheet appears (not a real test) Device + Debugger attached PKAddPaymentPassViewController error Device + Debugger detached (Dev build) SDK error 903: "device environment unsafe" TestFlight (Distribution) PKAddPaymentPassViewController cannot be created Questions: Can PKAddPaymentPassViewController fail to be created even when canAddPaymentPass() returns true? What other conditions could cause this? Is there a way to verify that the Distribution provisioning profile correctly includes the payment-pass-provisioning entitlement after it has been approved by Apple? Are there any additional Apple Pay entitlements or configurations (e.g., Wallet merchant setup, pass type identifiers) required beyond com.apple.developer.payment-pass-provisioning for In-App Provisioning to work? Does regenerating the Distribution provisioning profile on Apple Developer Portal resolve cases where entitlements were added after the profile was originally created? Any guidance would be greatly appreciated. Thank you.

I have some questions related to MPAN. What is the format of an MPAN? Is it the same as DPAN? Is it PAN preserving format? Is a Cryptogram required and if yes, what kind of cryptogram? Is it the same format as DPAN? Thanks in Advance!