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?

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’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.

I'm currently working on an AppIntent in my app to import Apple Pay transactions via Transaction triggers in Shortcuts. While I can access the transaction name with the following code: @Parameter(title: "Transaction") var transaction: String I'm not sure how to retrieve the full details of the transaction, including: Card or Pass Merchant Amount Name At the moment, transaction only provides the name as a string, but I need access to the complete transaction data. I know that by selecting specific fields like Amount, Merchant, etc., I can retrieve each piece of data individually, but it would be much easier and more user-friendly to simply retrieve the entire transaction object at once. Has anyone successfully retrieved all details of an Apple Pay transaction in this context, and if so, could you share how to do so?

Hello. we are looking in adding an additional verification method as part of our in app provisioning to apple wallet. the method is called app to app verification method where basically when the customer adds their card (debit or credit) on apple wallet they can be verified through a third party app. does apple support this? where can i find any material related to this?

we are experiencing an issue when making an HTTP call to: "https://apple-pay-gateway-cert.apple.com/paymentservices/registerMerchant". The response we are receiving back is HTTP Status Code 401 Unauthorized. We noticed the issues started around "Jan 24, 2025 at 9:51:46.327 am" and is still carrying on. Some other examples of when the calls failed: Jan 27, 2025 at 3:04:31.387 pm Jan 27, 2025 at 9:46:04.068 am Jan 27, 2025 at 3:36 pm All of the above dates and times are UK GMT +0 times. As the problem is around HTTP status code of 401 Unauthorised its tough to show what's actually happening. Like I stated above everything was working correctly before the 24th of Jan and nothing has changed or been modified on our side. I have even tried to do the following: Use the first set of Certs to perform a test Still returns 401 Delete a Cert and re generating them from scratch to perform a test with those set of Certs Still returns 401 I have just tried to process another HTTP call to the paymentservices/registerMerchant and I could inspect the headers of the request and im hoping this helps in your investigation. Headers: x-keystone-correlationid = 8f9a3c16-f78f-4f9b-9484-63190ef14a77 Date = Tue, 28 Jan 2025 10:00:43 GMT x-envoy-upstream-service-time = 4 x-apay-service-response-details = via_upstream We also found an article that has us a bit worried about this issue. Article here: https://developer.apple.com/news/?id=2x8awlvm States that Apple/Apple Pay will be making some changes to the ciphers in the coming months. With this article and the issues we seeing on Sandbox Environment we are worried that come the 4th of February as stated in the article that our Production Environment will be effected and we will stop being able to use Apple Pay so that gives us about a week to fix any issues/change code that might come out of it. Please could you come back with some information around the Article posted and if our Production Environment would be impacted.

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, we are developing in app provisioning of our American Express network cards. After clicking add to apple wallet in our app, I launch the PKAddPaymentPassViewController and click next. It loads for a few seconds and then I get: [<private>] ProvisioningOperationComposer: Step '<private>' failed with error Error Domain=PKProvisioningErrorDomain Code=5 UserInfo={PKErrorHTTPResponseStatusCodeKey=500} Does anyone have any insight on what this error means?

I've encountered an issue where we need multiple domain associations with separate Apple Pay implementations. Briefly, we have a /.well-known/apple-developer-merchantid-domain-association already setup with Stripe, and now we need another, different version of the file to get setup with FreedomPay. FreedomPay insists this file represents a three-way relationship between all parties and I have no reason to disbelieve them. I'm wondering if anyone has encountered this or if there is a standard procedure. I'm currently trying to find documentation on the exact way Apple Pay verification interacts with this file to see if we can produce it dynamically.

Issue Description In our Apple Pay integration process, the validation URL returned from the onvalidatemerchant callback is: https://apple-pay-gateway.apple.com/paymentservices/startSession However, according to Apple’s official documentation (reference link), the correct validation URL is: https://apple-pay-gateway.apple.com/paymentservices/paymentSession We are seeking clarification and assistance regarding the following issues: Issue 1 Will continuing to use the startSession URL cause problems or errors? Are there functional differences between the two URLs (startSession and paymentSession)? Does Apple still officially support startSession, or are we required to switch to paymentSession? Issue 2 We occasionally experience the following 400 error, even though the URL we use for validation is the one returned from the onvalidatemerchant callback: 400: { "statusMessage": "Payment Services Exception merchantId=*** not registered for domain=***.com", "statusCode": "400" } We have verified the following: Our Merchant ID and certificates are valid. All Apple Pay configuration details, including merchant domain verification and placement of the .well-known/apple-developer-merchantid-domain-association file, have been correctly set up and verified. However, we still encounter the error intermittently. Questions: If we need to transition to using paymentSession, how should we do this? Could this error be related to the use of startSession? If not, how should we troubleshoot further? Support Needed Confirmation and clarification on the proper usage and differences between the two URLs: startSession and paymentSession. Guidance on how we can investigate and resolve the 400 error to ensure that the Apple Pay validation process works consistently. We appreciate your assistance and support!

I tried to test In-App Provisioning in Production for our whitelisted app through TestFlight (Internal Testing Track) and we received the following error response from PassBook during the provisioning attempt, Could you please guide us? Error Response from sysdiagnose PassBookUIService during In-App Provisioning attempt: { statusCode = 500; statusMessage = "Broker Service Response exception"; } I reported the error in Feedback Assistant: ID: FB16112348 (500 Broker Service Response exception during Apple Pay In-App Provisioning ). Note:- I am reffering to Getting Started with Apple Pay: In-App Provisioning, Verification, Security, and Wallet Extensions

The Shortcuts app offers the possibility to trigger shortcuts/intends when a wallet credit card is used and a new transaction is created. I would like to add transaction details to one of my apps and use such a shortcut for it. Other apps do the exact same thing, so this should not be a problem. Adding a shortcut to my app was not a big deal. However, how can this be tested on simulator? When trying to add a new automatization in the Shortcuts app using a wallet transaction as trigger I cannot finish the setup dialog since the Next button is disabled. I assume this is because no card is configured. When trying to add a card in Wallet I just receive that this was not successful. I have connected the simulator to a Sandbox Apple ID account using a region which supports Apple Pay (US). Using a real account does not solve the problem. Any idea how to get this working? Using real transaction within a store could obviously not be the solution for debugging.

Apple pay on checkout in iframe is working with test cards while in Private window. However when we go into normal browsing the Apple Pay button is greyed out. Real cards will ask for fingerprint and then decline with "Payment Not Completed". What is the issue?

Hi, I understand that it's possible to add a virtual debit or credit card from a mobile app into the iOS Wallet using PassKit from the Apple SDK. However, I haven't come across documentation on how to achieve this directly from a web app. I found this article on Apple's support site (https://support.apple.com/en-gb/guide/security/secdc2567239/web), which mentions adding cards from a card issuer’s website, but it doesn’t provide details on the process. Could you please confirm if it's possible to add a card directly from a web app without using a mobile app? If so, could you guide me to the relevant documentation? Thanks in advance!

Hi Guys, I am having an issue verifying a card when it is pending verification in the Apple Watch Wallet App and the iPhone Wallet. When the user verifies the card in the wallets, they are redirected to verification in my APP. However, the problem is that I don't know which application is calling, whether it is the Apple Watch or the iPhone, because the URL sends me the same serialNumber from the PKPASS. It is impossible to know if the user wants to verify and activate the card on the watch or the iPhone. Because I only receive the following information in the URL: myapp://app-url? passTypeldentifier=paymentpass.com.apple&action =verify&serialNumber=***** The serialNumber is the same from the iPhone Wallet and the Watch Wallet. func application(_ app: UIApplication, open url: URL, options: [UIApplication.OpenURLOptionsKey : Any] = [:]) -> Bool { let source = options[.sourceApplication] I try to retrieve the source, but it comes back null. It would be the only way to know the originating App. Can someone help me solve this problem?

I am adding In-App provisioning to my app. I am able to access the Apple Pay Sandbox and I have successfully tested adding a secure element/payment pass to Apple Wallet. However, once the pass has been added to the wallet, I can not access or retrieve the pass from my app. I have confirmed with the PNO that the PNO Pass Metadata Configuration in the testing environment include the correct metadata for "associatedApplicationIdentifiers" and "associatedStoreIdentifiers". Does anyone know why I am having this issue and how I can resolve it? Steps used to access pass in Apple Wallet I am unable to view the pass when I attempt to access it using the PKPassLibrary function as follows: let library = PKPassLibrary() if #available(iOS 13.4, *) { // This returns an empty array library.passes(of: .secureElement) } else { // This also returns an empty array library.passes(of: .payment) } // This returns an empty array too library.passes() Steps used to add pass to Apple Wallet These are the steps I follow to add the card: I create a PKAddPaymentPassRequestConfiguration I use this config to instantiate a PKAddPaymentPassViewController. I provide the nonce, nonceSignature, and certificates to my PNO along with the card data. I receive the activationData, encryptedPassData, and ephemeralPublicKey from my PNO and create a PKAddPaymentPassRequest using this data. I add the pass to Apple Wallet. In the addPaymentPassViewController callback, I am able to view the pass data from the .didFinishAdding pass: PKPaymentPass? variable. I am also able to see that the pass has been added from Apple Wallet app. I am not able to access the pass using PKPassLibrary().passes() at this point. I am not able to access the pass at any point after adding it either.

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

Hello everyone. I encountered a problem when integrating Apple Pay. I obtained all the renewal orders through the Apple interface, and their purchaseDate is 8 hours later than the actual payment time. Why is this happening? According to the documentation, the purchaseDate value provided by Apple is a millisecond timestamp that represents the actual payment time of the user, so theoretically there shouldn’t be any timezone issues. This works well in client-initiated subscriptions, but in renewal scenarios, the purchaseDate becomes unreliable. Could this be due to some configuration in the configuration center? For example, I actually received an Apple notification at 1746686911000 (2025-05-08 06:48:31 Etc/GMT). However, the data returned by the Apple interface is as shown below: { "appAccountToken": "xxxx", "bundleId": "xxxx", "currency": "GBP", "environment": "Production", "expiresDate": 1762616831000, "inAppOwnershipType": "PURCHASED", "isUpgraded": false, "offerDiscountType": "", "offerIdentifier": "", "offerType": 0, "originalPurchaseDate": 1746456432000, "originalTransactionId": "320002311698411", "price": 39990, "productId": "xxxx", "purchaseDate": 1746715631000, "quantity": 1, "revocationDate": 0, "revocationReason": 0, "signedDate": 1746687092825, "storefront": "GBR", "storefrontId": "xxxx", "subscriptionGroupIdentifier": "xxxx", "transactionId": "320002315815857", "transactionReason": "RENEWAL", "type": "Auto-Renewable Subscription", "webOrderLineItemId": "320001062124562" } You can see that the purchaseDate is 1746715631000 (2025-05-08 14:48:31 Etc/GMT), which is even later than the current time. Can someone explain this behavior that is inconsistent with the documentation, or did I do something wrong? I would be very grateful for any help anyone can provide.

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 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.