Hi, We are trying to make the PKAddPaymentPassViewController to show the correct list of devices to where the pass can be added. We have analysed the documentation and we are using the PrimaryAccountIdentifier field which is the field that supposedly controls this behavior but the list of devices presented in the view controller always include one iPhone and one Apple Watch, regardless of where the card has been already added. We are initializing the PKAddPaymentPassRequestConfiguration object with: PKEncryptionScheme PrimaryAccountIdentifier CardholderName PrimaryAccountSuffix LocalizedDescription PaymentNetwork PrimaryAccountIdentifier CardholderName PrimaryAccountSuffix LocalizedDescription We have also verified the configuration in our payment pass processor and everything should be ok. We would like to have some help on achieving the desired flow for Apple Pay, which is to present the PKAddPaymentPassViewController with the correct list of available devices and not the full list. Thank you.

I'm trying to create an Apple Pay session for my website. I'm starting with curl for now, just to get proof of concept. curl --cert cert.pem --pass {passphrase} --header "Content-Type: application/json" --request POST --data '{"merchantIdentifier":"{merchantIdentifier}","displayName":"testDisplayName", "initiative": "web", "initiativeContext": "{domain}"}' https://apple-pay-gateway.apple.com/paymentservices/paymentSession This is the response I get back { "statusMessage": "Payment Services Exception merchantId={VERY-LONG-ID} not registered for domain={domain}", "statusCode": "400" } I'm not sure why this is happening. {domain} is in the form of sub.site.tld with no protocol, such as https, which matches what I see in the list of the domains in the merchant identity dashboard. The {merchantIdentifier} also matches what I see in the top right, but the merchantId in the response is something I don't recognize. It's a long string of characters that appears to be hexadecimal. I added the apple-developer-merchantid-domain-association file to my .well-known directory and the dashboard does report that the domain is verified. I am making the request from the web server that the domain resolves to, if that matters. I can't think of any reason this would be happening. I'm not sure where the long merchantId in the response is coming from. Does it matter that it doesn't match what I supplied in the request? As far as I can tell, I am using the correct merchantIdentifier. It matches the dashboard and the CN field of the certificate. I found this other post that seems to have a similar error: https://forums.developer.apple.com/forums/thread/671227 The main difference is a 417 status code instead of the 400 I got. But the problem here was that there was no payment processing certificate and I do have one of those. I haven't checked with my processor to verify that the certificate is published, but I will do that soon. I wouldn't expect that to matter. Maybe it does? What other reason could I be getting this error? Could it be a problem with my merchant identity certificate? It took a lot of effort to make it work. But I suspect it's fine, otherwise I wouldn't be getting a response from Apple at all. I can't think of any other possible problems.

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.

During our Apple Pay integration testing, we encountered an issue that we're unsure how to resolve. Below are the steps we followed: Created an Apple Pay sandbox test account for Raul and added a test card, following the documentation here: https://developer.apple.com/apple-pay/sandbox-testing/ Opened the Golfmanager platform and initiated a booking. For payment, selected Apple Pay as the method. Raul clicked the Apple Pay button on the Golfmanager UI. He scanned the QR code using his iPhone, logged in with the test account. Apple Pay began validating our merchant identity and retrieved the wallet token to proceed with payment. The Apple Pay payment sheet appeared on Raul's iPhone, showing the card details and the amount requested by Golfmanager. Suddenly, the Apple Pay sheet closed unexpectedly, and we have no insight into what went wrong or what might be missing on our end. Here is the video: https://drive.google.com/file/d/1r-73edQ9eBZzXi6HoSYYGjKO8LbxBrZi/view?usp=drive_web

So we are developing an NFC reader for a client and one of the requirements was Apple ECP. We submitted a product plan and it was approved and we were given access to the specific documentation for ECP. We are looking to only use Loyalty passes via NFC. Not Apple Pay. We wish to develop passes that have NFC capability and apparently you need another approval for NFC Entitlement. Apple just denied our application. No reason given, just denied. How are we suppose to develop a solution when we can only do one side of the development? Also we are seeing VAS mentioned and believe we also need access to this documentation as well, but no idea where to request it. Nothing in our developer portal or wpc portal. Can someone from Apple please steer us in the right direction. As we understand it we need: Approved hardware product plan (which we have) Access to ECP 2.0 documentation (which we have) Access to VAS protocol documentation (we don't have) NFC entitlement to be able to create NFC enabled passes. Let me know what we need to do or if I am not understanding things correctly. Thanks

all mastercard cards expired in 2024

I am writing regarding an issue I have encountered while attempting to complete a payment using test users created within the Sandbox environment of Apple Pay. The problem persists specifically when trying to make payments through the demo page at https://applepaydemo.apple.com/. Problem Description: When initiating a payment process with either of the following test user accounts. The flow proceeds as follows: The Apple Pay window appears correctly. Processing begins but does not conclude successfully. After processing concludes, there is no prompt for 'Pay with Touch ID'. Additional Information: Device & OS Version: MacOS 15.3.2 Browser & Version: Safari 18.3.1 Real Device or Simulator: Real device used First Occurrence: Before January 1st, 2025 Custom Configurations or Backend Used: No custom configurations or backend modifications are being utilized during interaction with the demo page. Could you please provide assistance in resolving this issue?

Hello, I am following up on my previous feedback (Feedback ID: FB17175593) regarding the in-app provisioning failure for Apple Pay. In that report, I detailed errors encountered during the card addition process (notably issues related to a missing teamID and cryptographic material errors). Could you please provide an update on the investigation progress? I appreciate your assistance and look forward to your response.

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.

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!

I am currently working on decrypting Apple Pay tokens with Laravel PHP, and I have encountered a few uncertainties regarding the decryption process and the usage of AES-GCM. Could you please clarify the following points: Algorithm Confirmation: Am I using the correct algorithm for decrypting the data key? Specifically, I am utilizing AES-256-GCM with the algorithm ID "id-aes256-GCM" (2.16.840.1.101.3.4.1.46), as specified in the documentation. Is this the recommended algorithm for decrypting the Apple Pay token's data key? Authentication Tag: In the decryption process, it seems that an authentication tag is required, but I am not sure where to obtain it from. Could you confirm how the authentication tag is generated or provided during the encryption process? If the tag is part of the token or is transmitted separately, could you clarify where I can retrieve it in order to proceed with the decryption successfully? IV and Other Parameters: I am using an initialization vector (IV) of 16 null bytes (00000000000000000000000000000000) as specified in the documentation. Could you confirm that this is correct and aligns with the expected parameters for the AES-GCM decryption? Are there any other specific parameters or considerations I should be aware of when implementing the decryption of Apple Pay tokens? GCM vs Other Encryption Modes: Can you confirm that AES-GCM is the preferred and required encryption mode, or is there any flexibility to use other modes (e.g., AES-CBC) without compromising security? Your guidance would be greatly appreciated to ensure I am following the correct decryption procedure for Apple Pay tokens. Thank you in advance for your support.

I can’t send or receive money with Apple Cash My account is restricted but only Apple Cash everything else works fine help

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.

I am developing an app to add Discover cards to Apple Wallet. Unlike Visa, MasterCard, etc., Discover does not have APIs that return activationData, encryptedPassData and ephemeralPublicKey for a given card, so I have created a backend server to handle this. In my server, I am unsure how to generate the ephemeralPublicKey. Do I need to use the merchant certificate? If so, how do I use it to generate the ephemeralPublicKey? I would appreciate it if someone could provide me with a step-by-step guide on how to generate ephemeralPublicKey for provisioning a card.

We have an app that uses the pass-presentation-suppression entitlement and calls requestAutomaticPassPresentationSuppression to prevent the Wallet app from being presented when the device is displaying a barcode to a barcode/nfc reader. This works as expected for users of the standard Apple Wallet app. However, it does not prevent third-party wallet apps from being launched, which hides the barcode and prevents it from being scanned properly. What options do I have to prevent third-party wallet apps from launching or interfering while our app is actively presenting a barcode?

I have a question regarding the file apple-developer-merchantid-domain-association.txt. I understand that this file is used during API access for Apple Pay Web payments. However, is it necessary for our company to access this file during the payment process? Also, this domain validation file is expected to be placed in the publicly accessible “.well-known” folder on our web server. Is it acceptable for this file to remain readable by third parties on the Internet, including Apple’s servers, without posing any security risks? Since this file is generated during domain registration on the Apple Developer site and is unique to our domain, we believe there should be no security concerns even if accessed by third parties. However, are there any specific security requirements for this domain validation file? Please note that the domain validation has already been successfully completed. We appreciate your time and look forward to your guidance. Best regards,

Body: Hello, We are currently implementing iOS order verification and have encountered an issue. Some of the receipts we verify return with an empty in_app array, which makes it impossible to determine whether there is a valid in-app purchase. Below is the code we’re using for verification and the result we receive: Code Example: public function iosVerifyReceipt($receipt, $password = '', $sandbox = false) { $url = $sandbox ? 'https://sandbox.itunes.apple.com/verifyReceipt' : 'https://buy.itunes.apple.com/verifyReceipt'; if (empty($password)) { $data = json_encode(['receipt-data' => $receipt]); } else { $data = json_encode(['receipt-data' => $receipt, 'password' => $password]); } $ch = curl_init($url); curl_setopt($ch, CURLOPT_RETURNTRANSFER, true); curl_setopt($ch, CURLOPT_POST, true); curl_setopt($ch, CURLOPT_POSTFIELDS, $data); $result = curl_exec($ch); curl_close($ch); $result = json_decode($result, true); $result = $result ?? []; $result['sandbox'] = $sandbox; if ($result['status'] != 0) { Log::warning('ios verify receipt failed', ['receipt' => $receipt, 'result' => $result, 'sandbox' => $sandbox]); if ($result['status'] == 21007) { return $this->iosVerifyReceipt($receipt, $password, true); } } return $result; } // Order validation check if (empty($result) || $result['status'] != 0) { throw new BadRequestHttpException("Ios Order Verify Error"); } $appItemId = $result['receipt']['app_item_id'] ?? ""; if ($appItemId != MY_APP_ID) { throw new BadRequestHttpException("Ios Order Verify Error"); } $inApp = array_filter( $result['receipt']['in_app'] ?? [], function ($item) use ($transactionId,$order) { return $item['transaction_id'] == $transactionId && $item['product_id'] == $order->getProductId(); } ); if (empty($inApp)) { throw new BadRequestHttpException( "Ios Order Verify Error"); } Array ( [receipt] => Array ( [receipt_type] => Production [adam_id] => * [app_item_id] => * [bundle_id] => * [application_version] => 5511 [download_id] => * [version_external_identifier] => * [receipt_creation_date] => 2025-02-11 04:06:47 Etc/GMT [receipt_creation_date_ms] => * [receipt_creation_date_pst] => 2025-02-10 20:06:47 America/Los_Angeles [request_date] => 2025-02-11 15:54:56 Etc/GMT [request_date_ms] => * [request_date_pst] => 2025-02-11 07:54:56 America/Los_Angeles [original_purchase_date] => 2025-02-11 04:02:41 Etc/GMT [original_purchase_date_ms] => * [original_purchase_date_pst] => 2025-02-10 20:02:41 America/Los_Angeles [original_application_version] => * [preorder_date] => 2025-01-17 21:12:28 Etc/GMT [preorder_date_ms] => * [preorder_date_pst] => 2025-01-17 13:12:28 America/Los_Angeles [in_app] => Array ( ) ) [environment] => Production [status] => 0 [sandbox] => )

When accessing https://applepaydemo.apple.com/payment-request-api, the "Approve with Side Button" prompt is displayed, but it does not appear when using our test domain. I implemented the Payment Request API based on the sample source code from the following URL. On an iPhone device, the Apple Pay payment screen is displayed, but the "Approve with Side Button" icon below the amount does not appear, and instead a spinning loading icon is shown continuously. Could you please help identify the cause? ■ Reference URL: https://applepaydemo.apple.com/payment-request-api ■ Changed parameter: "merchantIdentifier": "〇〇.dev" ■ Accessed domain: 〇〇test.com ■ Test device: iPhone 13 iOS: 18.4.1

Currently, on our Production environment, when calling https://apple-pay-gateway.apple.com/paymentservices/paymentSessio,n we are randomly receiving: "Payment Services Exception merchantId={Value} unauthorized to process transactions on behalf of merchantId={Value} reason={Value} is not a registered merchant in WWDR and isn't properly authorized via Mass Enablement, either." Since launching Apple Pay on our platform we have received a new Domain Verification File and looking at some of the Domain Verification File that are hosted on the domains they are different to ours. Questions around the Domain Verification File Would we have to update every single Domain Verification File every time we receive a new one ? Does the paymentSession verfiy/call the Domain Verification File on the domain listed at https://[DOMAIN_NAME]/.well-known/apple-developer-merchantid-domain-association ? What happens if the Domain Verification File doesnt match the one that we currently have ? Would we have to regrester our Domains everytime we get a new Domain Verification File ?