please bear with me, i am NOT a developer. we have third party developer creating a banking app that is throwing an error when trying to provision MasterCard for Apple Pay. MasterCard says they do not see the request come in at all. our developer says the issue is between mastercard and apple - and asked us to reach out to Apple. Information provided from our developer: “Error code 2 is 'system cancelled' from the PKAddPaymentPassError enum. Basically, there is an issue between Apple and Mastercard (using the encrypted card info from...” Response from Mastercard Connect: Upon further research with the examples you shared we are not seeing any attempt that reached to MC

We are an issuer attempting to implement In-App Provisioning of Payment Cards leveraging Mastercard MDES and have successfully obtained our entitlement from Apple, but have not received the documentation titled "Getting Started with Apple Pay In-App Provisioning, Verification & Security". The latest copy I have found has been via Scribd for a version 3.0 from June 2020. I've tried contacting Apple Support and the In-App Provisioning Entitlements group but have had no luck. Thank you!

Hi Team, I have merchant session object - {"epochTimestamp":1748333121032,"expiresAt":1748336721032,"merchantSessionIdentifier":"SSH7CCD205FEEDD45AD84B77374D098B335_916523AAED1343F5BC5815E12BEE9250AFFDC1A17C46B0DE5A943F0F94927C24","nonce":"2d18eab4","merchantIdentifier":"8535F497EC92999BAD63C6F213F0F32DEEB5DBF8A0A91007F6C1128537B6FB19","domainName":"f7071159c1tst-store.occa.ocs.oraclecloud.com","displayName":"DDF Test","signature":"308006092a864886f70d010702a0803080020101310d300b0609608648016503040201308006092a864886f70d0107010000a080308203e43082038ba003020102020859d8a1bcaaf4e3cd300a06082a8648ce3d040302307a312e302c06035504030c254170706c65204170706c69636174696f6e20496e746567726174696f6e204341202d20473331263024060355040b0c1d4170706c652043657274696669636174696f6e20417574686f7269747931133011060355040a0c0a4170706c6520496e632e310b3009060355040613025553301e170d3231303432303139333730305a170d3236303431393139333635395a30623128302606035504030c1f6563632d736d702d62726f6b65722d7369676e5f5543342d53414e44424f5831143012060355040b0c0b694f532053797374656d7331133011060355040a0c0a4170706c6520496e632e310b30090603550406130255533059301306072a8648ce3d020106082a8648ce3d030107034200048230fdabc39cf75e202c50d99b4512e637e2a901dd6cb3e0b1cd4b526798f8cf4ebde81a25a8c21e4c33ddce8e2a96c2f6afa1930345c4e87a4426ce951b1295a38202113082020d300c0603551d130101ff04023000301f0603551d2304183016801423f249c44f93e4ef27e6c4f6286c3fa2bbfd2e4b304506082b0601050507010104393037303506082b060105050730018629687474703a2f2f6f6373702e6170706c652e636f6d2f6f63737030342d6170706c65616963613330323082011d0603551d2004820114308201103082010c06092a864886f7636405013081fe3081c306082b060105050702023081b60c81b352656c69616e6365206f6e207468697320636572746966696361746520627920616e7920706172747920617373756d657320616363657074616e6365206f6620746865207468656e206170706c696361626c65207374616e64617264207465726d7320616e6420636f6e646974696f6e73206f66207573652c20636572746966696361746520706f6c69637920616e642063657274696669636174696f6e2070726163746963652073746174656d656e74732e303606082b06010505070201162a687474703a2f2f7777772e6170706c652e636f6d2f6365727469666963617465617574686f726974792f30340603551d1f042d302b3029a027a0258623687474703a2f2f63726c2e6170706c652e636f6d2f6170706c6561696361332e63726c301d0603551d0e041604140224300b9aeeed463197a4a65a299e4271821c45300e0603551d0f0101ff040403020780300f06092a864886f76364061d04020500300a06082a8648ce3d0403020347003044022074a1b324db4249430dd3274c5074c4808d9a1f480e3a85c5c1362566325fbca3022069369053abf50b5a52f9f6004dc58aad6c50a7d608683790e0a73ad01e4ad981308202ee30820275a0030201020208496d2fbf3a98da97300a06082a8648ce3d0403023067311b301906035504030c124170706c6520526f6f74204341202d20473331263024060355040b0c1d4170706c652043657274696669636174696f6e20417574686f7269747931133011060355040a0c0a4170706c6520496e632e310b3009060355040613025553301e170d3134303530363233343633305a170d3239303530363233343633305a307a312e302c06035504030c254170706c65204170706c69636174696f6e20496e746567726174696f6e204341202d20473331263024060355040b0c1d4170706c652043657274696669636174696f6e20417574686f7269747931133011060355040a0c0a4170706c6520496e632e310b30090603550406130255533059301306072a8648ce3d020106082a8648ce3d03010703420004f017118419d76485d51a5e25810776e880a2efde7bae4de08dfc4b93e13356d5665b35ae22d097760d224e7bba08fd7617ce88cb76bb6670bec8e82984ff5445a381f73081f4304606082b06010505070101043a3038303606082b06010505073001862a687474703a2f2f6f6373702e6170706c652e636f6d2f6f63737030342d6170706c65726f6f7463616733301d0603551d0e0416041423f249c44f93e4ef27e6c4f6286c3fa2bbfd2e4b300f0603551d130101ff040530030101ff301f0603551d23041830168014bbb0dea15833889aa48a99debebdebafdacb24ab30370603551d1f0430302e302ca02aa0288626687474703a2f2f63726c2e6170706c652e636f6d2f6170706c65726f6f74636167332e63726c300e0603551d0f0101ff0404030201063010060a2a864886f7636406020e04020500300a06082a8648ce3d040302036700306402303acf7283511699b186fb35c356ca62bff417edd90f754da28ebef19c815e42b789f898f79b599f98d5410d8f9de9c2fe0230322dd54421b0a305776c5df3383b9067fd177c2c216d964fc6726982126f54f87a7d1b99cb9b0989216106990f09921d00003182018930820185020101308186307a312e302c06035504030c254170706c65204170706c69636174696f6e20496e746567726174696f6e204341202d20473331263024060355040b0c1d4170706c652043657274696669636174696f6e20417574686f7269747931133011060355040a0c0a4170706c6520496e632e310b3009060355040613025553020859d8a1bcaaf4e3cd300b0609608648016503040201a08193301806092a864886f70d010903310b06092a864886f70d010701301c06092a864886f70d010905310f170d3235303532373038303532315a302806092a864886f70d010934311b3019300b0609608648016503040201a10a06082a8648ce3d040302302f06092a864886f70d01090431220420c11c8025910403d6691af195664f47b606df9ccb351237d0de4e7c31e8a5067b300a06082a8648ce3d04030204483046022100ea8d2bb74b4960f17e4e45b99fec3f0539565fd3169091c6b39fbfb3e11a952a022100a4a4a3ff6d91caf8fa7d9b18179e0cc2156c90d4f719ae52734b4799c2b1beea000000000000","operationalAnalyticsIdentifier":"DDF Test:8535F497EC92999BAD63C6F213F0F32DEEB5DBF8A0A91007F6C1128537B6FB19","retries":0,"pspId":"8535F497EC92999BAD63C6F213F0F32DEEB5DBF8A0A91007F6C1128537B6FB19"} After sending this to session.compleMerchant I am getting the invalid access error. Regards, Varsha

I am trying to play around on the Apple Pay demo page (https://applepaydemo.apple.com) and I am getting the following error response. PaymentRequest AbortError: The operation was aborted. I am using the Payment Request API

Hello, Please help. We have been experiencing what appears to be a TLS handshake error in our Apple Pay merchant validation requests (2-way TLS) since June 25, 2025. We are aware of the encryption algorithm changes made in February 2025, and our system was functioning correctly at that time. However, the error started occurring suddenly and only recently. Could you please clarify the following points? Have there been any changes to the TLS configuration (cipher suites, certificates, protocol versions, etc.) on the Apple Pay server side since June 2025? Have there been any updates to the specifications or recommended settings for merchant validation requests? Is there any way to contact Apple for technical support regarding this issue other than through the Developer Forums? Our Merchant Identity Certificate has already been renewed and is confirmed to be valid.

Hello, we are experiencing issues with adding VISA cards via In-App Provisioning on iOS using PassKit. The same flow works correctly with Mastercard, but for VISA cards the Apple broker endpoint returns HTTP 500. Details Device: iPhone15,3 (iPhone 15 Pro), iOS 18.6.1 (22G90) Region: CZ App: [REDACTED] (version 0.4.3) Issuer ID: [REDACTED] Merchant ID and entitlements are configured and validated. SEID: [REDACTED] Request flow GET /broker/v4/devices/{SEID}/issuerProvisioningCertificates?encryptionVersion=EV_ECC_v2 Request ID: B61363A8-0BFF-4CD6-92BC-52C461DFFAAD Response: 200 OK Conversation ID: e12c64c9a0b54981adfad8d00800d836 Returned nonce: [REDACTED] Timestamp: 2025.08.21_14-01-46+0200 POST /broker/v4/devices/{SEID}/cards Request ID: F29B73CA-CDDE-4C0C-9F40-B87AE006FDDD Payload fields present (values redacted): encryptedCardData [REDACTED], ephemeralPublicKey [REDACTED], publicKeyHash [REDACTED], nonce [REDACTED], issuerIdentifier [REDACTED], encryptionVersion=EV_ECC_v2 Response: 500 Internal Server Error (latency ~0.41s) Timestamp: 2025.08.21_14-01-47+0200 Observation Provisioning succeeds with Mastercard but consistently fails with VISA. The GET issuerProvisioningCertificates succeeds; the POST …/cards returns 500. Request Could you please: Provide internal error details for Request ID F29B73CA-CDDE-4C0C-9F40-B87AE006FDDD (and/or Conversation ID e12c64c9a0b54981adfad8d00800d836), Confirm whether the 500 originates before or after the broker’s call to VTS (Visa Token Service), and Validate that our app/merchant/issuer configuration is fully enabled for VISA push provisioning in our region. Attached privately: sysdiagnose with full traces (can share via secure channel upon request). Kind regards, Martin

Hello, We are experiencing a consistent delay when initiating Apple Pay sessions using the https://apple-pay-gateway.apple.com/paymentservices/startSession endpoint. Below is a detailed overview of our setup and the issue. Setup Our web service is hosted in AWS and there is a proxy server between our web service and Apple servers. We are passing the correct domain in the initiativeContext field of the startSession request. The .well-known/apple-developer-merchantid-domain-association file is hosted on a different domain, which is also correctly configured and associated with our merchant ID in the Apple Developer portal. Observed Behavior When the same request is made from a local development environment, Apple responds immediately (under 1 second). When the request is made from our AWS-hosted service, Apple responds with a valid session, but only after a consistent ~15-second delay. The content and response are otherwise identical — only the timing differs. We would appreciate any insights or suggestions from others who have faced similar behavior or from the Apple Pay team. Thank you in advance!

We are unable to add/remove Merchant IDs in App IDs identifier profile, after pressing "Edit" button on "Apple Pay Payment Processing" section, then choosing desired Merchant ID to check/uncheck from the available Merchant IDs, then pressing Continue/Save/Confirm buttons - nothing happens, the "Save" button text briefly changes to "Processing" and then back To "Save" and we still have previously enabled Merchant IDs and the Save button is still in enabled state, any help?

Hi, I set up a Sandbox Tester account in my company’s Apple Developer Program and signed in on my iPhone under Settings → App Store → Sandbox Account. When I go to Wallet → Add, I only see options for Credit or Debit Card or Travel Card. The option to add an Apple Pay Sandbox Card is missing, and when I try entering the test card numbers from Apple’s documentation (developer.apple.com/apple-pay/sandbox-testing), the card is not valid. Has anyone experienced this and found a solution? Thanks! PS: I can't post this to Wallet Category, I keep getting error that it contains sensitive text.

We’re building a usage-based rental flow. The final charge is only known after the session ends (like gas pumps). We want the same Apple Pay UX that gas stations like at a gas station has: the user does not see a pre-authorization amount up front; they only see “approved” and later the final posted amount on the statement. What we observe (gas stations / desired UX) When paying at gas station with Apple Pay (card-present), the user confirms their card (double-tap) but no pre-auth amount is shown in Wallet/notification UI. The small notification is from the bank (not the merchant) and shows only bank + merchant name, no total. After fueling ends, the final amount appears on the statement from the merchant. What happens in our flow (current behavior) Platform: Apple Pay via Stripe (Apple Pay on the Web with QR → mobile Safari Wallet sheet). When a user confirms payment, the pre-authorization amount is shown immediately to the user (appears like a charge from the user’s perspective). We want to avoid showing that amount, matching the pay-at-pump experience.

For Apple Pay testing, I have tried the following: Sign into the Sandbox Account via Developer Settings: Settings > Developer > Sandbox Account Keep your main Apple ID for everything else Add Test Cards to Wallet: Try adding the test card numbers (MasterCard and Visa Debit, as we support only those) Apple provides in their documentation. Unfortunately, none of them are added to the wallet. All the time it gives 'Could Not Add Card'. I tried on devices with iOS 18+. Can anyone advise on this? Thanks

We have been using ApplePay on the web for years, but we are running into a problem since today in sandbox where domainName is missing from the create payment sessions request. We haven't changed anything related to this request any time recently. Static payment sessions url being hit in sandbox: https://apple-pay-gateway-cert.apple.com/paymentservices/paymentSession request format: "merchantIdentifier": "merchant.com.identifier", "displayName": "Test Store", "initiative": "web", "initiativeContext": "test.example.com", "domainName": "test.example.com" response format: { "epochTimestamp": 1763533367972, "expiresAt": 1763536967972, "merchantSessionIdentifier": "<merchantSessionIdentifier>", "nonce": "<nonce>", "merchantIdentifier": "<merchantIdentifier>", "displayName": "Test Store", "signature": "<signature>", "initiative": "web", "initiativeContext": "test.example.com", "signedFields": [ "merchantIdentifier", "merchantSessionIdentifier", "initiative", "initiativeContext", "displayName", "nonce" ], "operationalAnalyticsIdentifier": "Test Store:<identifier>", "retries": 0, "pspId": "<pspId>" } Production create session request to https://apple-pay-gateway.apple.com/paymentservices/paymentSession is behaving as expected, sending the following fields as response: epochTimestamp, expiresAt, merchantSessionIdentifier, nonce, merchantIdentifier, domainName, displayName, signature, operationalAnalyticsIdentifier, retries, pspId Claude seems to suggest this is a response when Messages for Business is enabled, but this ApplePay Payment Processing merchant is only configured for Apple Pay on the Web. Any ideas or pointers to check for? We are worried this will spill over in production as well, which will break our ApplePay integration. Thanks in advance!

During Apple Pay in-app provisioning (EV_ECC_v2), our iOS app successfully obtains the issuer provisioning certificates and generates cryptographic material. The flow fails when Apple posts the card blob to Apple’s broker (card creation step), returning HTTP 500 from .../broker/v4/devices/{SEID}/cards. Steps: Call issuerProvisioningCertificates?encryptionVersion=EV_ECC_v2 → 200 OK; returns ECC leaf + Apple Root CA chain; nonce=2a831be4. 2. Build {encryptedCardData, activationData, ephemeralPublicKey} 3. POST /broker/v4/devices/{SEID}/cards Expected: 200 OK on /broker/v4/devices/{SEID}/cards, or 5xx with a descriptive error if payload/cryptography is invalid. Observed: 500 Internal Server Error from Apple broker on /cards (labeled “eligibility” in PassKit logs), causing a terminal failure in Wallet UI.

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.

I have a problem generating the domain certificate for a merchant id it gives me an error but when using the URL that Apple uses to validate said within the .well-known if the file can be loaded

Dears, Please take a look at case: FB21940123 (Wallet Extension unable to add card) Thanks

Hello, We are implementing in-app provisioning in our fintech app; the card issuer is a third party, so we have limited control and visibility. We have ruled out the causes we could investigate on our side and on the card issuer’s side. We are reaching out to ask for your help in understanding what is going wrong so we can fix it. What happens: User taps “Add to Apple Wallet” → we present PKAddPaymentPassViewController → they tap Next → after a few seconds the flow fails with "Set Up Later" alert. Device log: ProvisioningOperationComposer: Step 'eligibility' failed with error <PKProvisioningError: severity: 'terminal'; internalDebugDescriptions: '( "eligibility request failure", "Received HTTP 500" )'; underlyingError: 'Error Domain=PKPaymentWebServiceErrorDomain Code=0 "Unexpected error." UserInfo={PKErrorHTTPResponseStatusCodeKey=500, NSLocalizedDescription=Unexpected error.}'; userInfo: '{ PKErrorHTTPResponseStatusCodeKey = 500; }'; Feedback Assistant ID: FB22007923 (Error during the In-App Provisioning process)

Hi Apple Pay Team, We are building a QR-based payment platform and planning to integrate Apple Pay on the Web as a Payment Platform Integrator. Our setup: We operate a single domain (e.g., pay.example.com) where all Apple Pay transactions take place When a customer scans a merchant's QR code, our hosted page opens with the Apple Pay button We process payments on behalf of multiple merchants (receivers), each with a separate merchant ID at our payment processor We want to use a single Payment Platform Integrator ID with one set of certificates (Merchant Identity + Payment Processing) The payment processor handles sub-merchant identification and settlement to the correct receiver via card network (Visa/Mastercard) sub-merchant fields Our question: Since all transactions happen on our single domain, is it mandatory to register each sub-merchant via the Apple Pay Web Merchant Registration API (/paymentservices/registerMerchant) and use their partnerInternalMerchantIdentifier in the payment session request? Or is it acceptable to use our Platform Integrator's own merchant identifier for all payment sessions, given that: Only one domain is involved Sub-merchant identification is handled at the payment processor / card network level Our domain verification file is already hosted and verified We would appreciate clarity on the correct approach before we proceed with our integration. Thank you.

Hello, We are encountering an issue with Apple Pay on the Web in the sandbox environment where payments cannot be completed because the onpaymentauthorized event is not triggered. The same implementation was working normally until March 5, but the issue started occurring consistently from March 6 without any changes to our code, certificates, or merchant configuration. Environment Apple Pay on the Web (JavaScript) Safari (iOS / macOS) Apple Pay Sandbox Merchant domain verified Merchant validation succeeds Observed Flow The Apple Pay flow proceeds normally until authentication: User clicks the Apple Pay button ApplePaySession.begin() is called onvalidatemerchant fires Merchant validation request succeeds completeMerchantValidation() is called Apple Pay sheet is displayed User authenticates with Face ID / Touch ID onpaymentauthorized is never triggered Because this event never fires, the payment token is not returned and the payment cannot proceed. ApplePaySession Request { "countryCode": "JP", "currencyCode": "JPY", "merchantCapabilities": ["supports3DS"], "supportedNetworks": ["visa", "masterCard"], "total": { "label": "Test Payment", "type": "final", "amount": "100" } } Merchant Validation Merchant validation succeeds and returns a valid session from Apple. Relevant fields from the merchant session: merchantIdentifier: 35A786BE6AB4... domainName: secure.telecom-awstest.com displayName: ApplePay Additional Notes Apple Pay sheet appears normally Authentication completes successfully No JavaScript errors are logged onpaymentauthorized is never fired Issue occurs consistently in the sandbox environment Confirmed across multiple iOS versions Question Has anyone experienced a similar issue recently in the Apple Pay sandbox environment, or are there any known changes that could cause the onpaymentauthorized event not to fire after authentication? Any insights would be greatly appreciated. Thank you.

We already have an apple pay integration with a psp.
We have a merchant id with an identity certificate, a processing certificate and merchant domains. We are working to integrate an other psp. This psp have one csr (processing certificate) by customer. All the payment will be processed on the same domain. We have understood that it is not possible to have different processing certificates for a merchant id. So we can not reused our existing merchant id.

 On the other hand, it seems that it is not possible to have different merchant ids on the same domain (because of the domain verification). But all payments are processed on the same domain.

 Do you think there is a solution ?
Is there a recommended workaround for this scenario?