Hi, You're here because you've had issues with your implementation of In-App Provisioning 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

Hi, To ensure the issue is not caused by an error within your app or web service request, please review the following documentation: Wallet Passes Wallet Developer Guide If the resources above don’t help identify the cause of the error, please provide more information about your app or web services to get started. To prevent sending sensitive credentials in plain text, create a report in Feedback Assistant to share the details requested below. Additionally, if the error is something we need to investigate further, the appropriate engineering teams also have access to the same information and can communicate with you directly within Feedback Assistant for more information, as needed. Please follow the instructions below to submit your report. For issues occurring with your native app or web service, perform the following steps: Install the Wallet profile on your iOS or watchOS device. 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. Create a Feedback Assistant report with the following information: The serial number of the device. Open Settings > General > About > Serial Number (tap and hold to copy). The SEID (Secure Element Identifier) of the device, represented as a HEX encoded string. Open Settings > General > About > SEID (tap and hold to copy). The sysdiagnose gathered after reproducing the issue. The .pkpass file(s), pass signing certificate(s) and pass type identiifier(s) (optional). The timestamp of when the issue was reproduced. 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 pass type identifier in the Safari Web Inspector. See Inspecting Safari on macOS to learn more. 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 Wallet pass implementation. 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 web implementation, a configuration issue within your developer account, or an underlying system bug. Cheers, Paris X Pinkney |  WWDR | DTS Engineer

We're building a SaaS that lets independent businesses issue Apple Wallet stamp-card passes. Our server signs every pass with a single Pass Type ID from our developer account. Each pass shows the merchant's own name and branding, and the back says "Issued by our platform" with a support contact. Updates use the standard web service plus an empty APNs push. Two questions: 1. Is it acceptable for one Pass Type ID to issue passes for many independent merchants, or should each merchant have its own? If a merchant sent abusive promotions, could Apple revoke the shared Pass Type ID and affect all merchants? 2. We use changeMessage on a back field to show merchants' occasional promotions (max one every 48 hours, reviewed by us), as well as on stamp and reward updates. The Wallet HIG discourages changeMessage for marketing. Is a promotional message on a loyalty pass acceptable, and what's the recommended mechanism? Has anyone running a multi-merchant platform dealt with this? Thanks!

Hello, we are ANeT, an EU-based manufacturer and developer of physical access control and attendance systems. We develop our own access control platform, including: our own NFC access readers (PASO), access controllers, backend and management software (Webguard), credential and user management. Our goal is to support employee/access credentials in Apple Wallet so that users can unlock doors using an iPhone or Apple Watch, ideally also using Express Mode. We would like to implement this directly into our own access control ecosystem, without using a third-party credential platform or third-party NFC reader hardware. From the Apple documentation, our understanding is that Access Keys use a credential stored in the Secure Element together with a pass in Apple Wallet, and that communication between Apple Wallet and the reader uses the Aliro protocol over NFC. We also understand that a physical access provider can act as a Credential Manager and that participation in the Apple Wallet Access Program is required. Our intended architecture is: Webguard / ANeT backend → Apple Wallet Access credential → iPhone / Apple Watch → our PASO NFC reader → ANeT access controller → door We would appreciate clarification on the following technical points: Is this architecture supported for a physical access control manufacturer using its own NFC reader hardware and firmware? What technical requirements must our NFC reader meet to communicate with Apple Wallet Access Keys using Aliro? Are there specific requirements or certification procedures for reader identification, ECP, certificates, keys, or the reader trust chain? Can our Webguard/backend platform act directly as the Credential Manager and provision, manage and revoke Access Keys through the Apple Access Platform? Can credential provisioning be initiated from a web interface using an “Add to Apple Wallet” flow, or is a native iOS application required? Which entitlements, certificates, APIs and technical documentation become available after joining the Apple Wallet Access Program? Is Apple Wallet Access for employee/physical access credentials available for access control providers operating in the European Union, including the Czech Republic? We contacted Apple Developer Support regarding this integration and were advised to ask the technical questions here on the Developer Forums. Developer Support case: 102991167219 Our objective is not to create a standard Wallet pass or QR credential. We want to integrate secure NFC-based physical access credentials directly with Apple Wallet, our own backend and our own reader hardware. Thank you for any guidance on the correct technical integration path.

The last week i paid 100$ for the activacion of my account i have sent some emails and i havent had no answer so i dont no what to do the activation of my means the last step of my start up, if someone hace some experience in this pls help me (i have sent my ID that is the last step they notice me)

Waiting on a new app to be reviewed, we were approved for a Card Program go live, last Tuesday, but app hadn't been reviewed, we now are approved any locked in for the 3rd Nov. How do we get a new app reviewed, inline with Digital Card Program? Re-submitted last Tuesday at 1:21 PM after no activity Apple ID: 6759777960 Case ID: 103003281154

Hey, 14th Oct, I submitted an app with a digital card program, it got approved for the card program go live... but app wasn't reviewed. Tried a rebuild, resubmit, yet still not reviewed. We are approved to go live 3rd Nov for the card program, would love a review ASAP so we have time to resolve and resubmit any issues.

Hi there! i have a similar issue as this guy (Link), but on my iPhone 14 Pro running iOS 16.4 (20E5229e). Without really using the wallet, it accounts for a huge portion of battery usage (see below). Does anyone of you have a similar issue?

I would like to propose a policy adjustment regarding Apple Wallet restrictions for child accounts (under 13) under Family Sharing. Current Limitation: Currently, Apple IDs for children under 13 are completely blocked from adding any cards to Apple Wallet. While restricting credit and debit cards for minors is a necessary measure for financial security and CoPPA compliance, this blanket restriction also blocks transit cards (such as Suica, T-money, etc.). The Problem: In regions with advanced public transit infrastructures, many children rely on digital transit cards for daily commutes to school and academies. Because Apple Wallet blocks transit cards on child accounts—even on Apple Watch via Family Setup—children are forced to carry physical transit cards, leading to frequent losses and damages. Proposed Solution: Differentiate Transit from Financial Cards: Maintain strict blocks on credit/debit cards for accounts under 13, but grant an exception for Transit Cards. Family Sharing Integration: Require Parental Approval through Family Sharing for any transit card addition or balance top-up, ensuring full parental control and safety. By introducing this exception, Apple can greatly improve the usability of Apple Watch Family Setup for families while maintaining high safety standards. I have submitted this feedback via Feedback Assistant under FB25261157. If you agree or are facing similar design constraints, please upvote this thread or reference the FB number in your own feedback submissions. Thank you.

According to this autofill credit card documentation we should be able to autofill credit card fields using the QuickType Bar for credit card fields, but it does not work. The QuickType Bar does not display for credit card fields (see screenshots) I have tested this on a physical device running iOS 27 (iPhone 16e), have added a card to the Autofill setting in the Wallet app, and have made sure my text fields have the correct textContentType values. I am able to autofill using the backup autofill menu, but it is less than ideal. It takes a minimum of 5 taps to autofill one field. It would be far less painful to just pull out the credit card and manually enter the information (see screenshot). Here is a link to my test project demonstrating the issue: https://drive.google.com/file/d/1wMGOUNhVnmt3rBAD0TSMf9NV39-JS9ij/view?usp=sharing

Hi, I've been trying to request the PassKit NFC certificate on our organization Apple Developer account for some time. We submit our request at https://developer .apple.com/contact/passkit/ and usually within 1-2 weeks I get a response saying the request was denied for reasons that can't be shared, but we can resubmit. We have resubmitted several times, doing our best to guess at how to revise the application each time, and each time get the same response. Just wondering if this is a new thing or something others have experienced. Am I really supposed to just keep guessing? Is there an appropriate escalation path? Thank you.

Does anyone know how to implement Apple Account Binding for Wallet Pass function like https://www.ticketswest.com/customer-service/nfc-apple-account-binding/apple-account-bin

Hi,I'm developing an iOS app that uses App Intents to log Wallet payment transactions via Shortcuts automation with the "After Payment" trigger. The Issue: When users set up a Personal Automation with "Run Immediately" enabled and select "Always Allow" on the permission prompt, the permission does not persist. Every subsequent Wallet transaction triggers the "Allow Once / Always Allow" dialog again. Reproduction: App exposes an App Intent (LogWalletTransactionIntent) with openAppWhenRun = false User creates Personal Automation in Shortcuts app: Trigger: Wallet → After Payment Action: Log Wallet Transaction Set automation to "Run Immediately" First Wallet payment → permission prompt appears → user selects "Always Allow" Second Wallet payment → permission prompt appears again (expected: silent execution) Observations: When the user sets up the automation manually (adds the App Intent action inline and maps fields manually), "Always Allow" works correctly — no repeated prompts The issue occurs when the action is referenced via a pre-configured .shortcut file that has variable descriptors embedded for the parameters The bundled shortcut contains Descriptor mappings for card and merchant parameters Questions: Is this a known limitation of how iOS handles permission persistence for App Intents invoked through pre-configured shortcuts vs. inline automation actions? Does the distribution method affect this behavior — will Ad Hoc (alpha), TestFlight (beta), and App Store (production) builds behave differently regarding permission persistence? Is there a recommended approach for bundling pre-configured shortcuts that avoids repeated permission prompts? Environment: iOS 18.x (also observed on earlier versions) App Intent with String and Double parameters with default:` values openAppWhenRun = false Distribution: Ad Hoc via PGY Any insights would be appreciated. Thanks!

I am working on In-App-Verification. I am able to add my cards manually in the Apple Wallet Sandbox. I am getting the option to Verify using App. When I click on the Verify Button, I am able to redirect to my Testflight App. But when I use the API PKPassLibrary().pass(withPassTypeIdentifier: passTypeIdentifier, serialNumber: serialNumber) its not returning me the expected Pass. It is infact giving an empty result The entitlements which I already have added are: com.apple.developer.pass-type-identifiers com.apple.developer.payment-pass-provisioning So I have below questions: Do I need to do something else for PassKit API's to work? Is it even possible to test In-App-Verification in the TestFlight App using sandbox Wallet? Is it possible to redirect user to debug and enterprise builds also as currently the redirection from Apple Wallet is not working for debug and enterprise builds? The PassKit API which I indicated earlier is working in debug build when I sideload from Xcode. But since deeplink from Wallet does not work for debug builds, I am not able to proceed with testing. What will be behavior in App-Store build production environment without using sandbox, by using real cards? Will it work there?

Hi, Our iOS airline app already provides its own Live Activity for flight tracking. We are currently adopting Apple's semantic boarding pass for our Wallet boarding passes. According to Apple's documentation, to automatically suppress the Wallet-based Live Activity, we should add our App Store Identifier (Adam ID) to the associatedStoreIdentifiers array in pass.json. We have configured this as follows: "associatedStoreIdentifiers": [ "<OUR_APP_STORE_ID>" ] However, we are still seeing the Flight Tracker / Wallet-based Live Activity option for the flight after adding the semantic boarding pass to Wallet. Has anyone experienced this behavior? Specifically: Is associatedStoreIdentifiers expected to completely suppress the Wallet-generated Live Activity? Does it suppress only the automatically generated Live Activity, while the Flight Tracker functionality remains available in the semantic boarding pass? Are there any additional requirements or specific pass.json configurations needed? Does the pass need to be removed and re-added to Wallet after adding associatedStoreIdentifiers? Is this behavior different between iOS versions? Our objective is to prevent duplicate flight-tracking Live Activities because our application already provides its own Live Activity for the same flight. Any clarification or guidance would be appreciated. Thanks!

iOS 27, See image below. From top to bottom I'm using: displayName containerDisplayName contentDescription I haven't found a way to remove the transaction amount from my containerDisplayName and display it in the top right with some other CSSearchableItemAttributeSet value. Is it even possible?

We test Apple Pay in the sandbox on supervised iPhones in a device lab (Apple Configurator supervision, no MDM enrollment, no SIM, iOS 26.x). Since late September two of the test cards from the Sandbox Testing page no longer add to Wallet. Discover test cards still add fine on the same devices and accounts. Filed as FB24994276 (Visa) and FB24994258 (Mastercard), with device logs and timestamps. Visa 4622 9431 2318 9285 (FB24994276), only on our lab devices: eligibility → 412 → TSM sync → 200, "received eligibility status: 1" terms shown and accepted provision → HTTP 403 → PKProvisioningErrorDomain Code=3 → "Invalid Card" Same result on two different lab iPhones, including one signed in to a brand-new sandbox account. The same new account and the same card add successfully on an unsupervised iPhone on a home network (iOS 18.2.1). Neither side sends location data. Mastercard 5204 2452 5046 0049 (FB24994258), on every device we tried, lab and home, iOS 18.2.1 and 26.x: eligibility → 412 → TSM sync → retry → HTTP 500 → PKProvisioningErrorDomain Code=5 Questions: What does the 403 at the provisioning step mean for the Visa card? Does supervision, the iOS version, our network egress, or the fact that our devices re-provision cards every test session play a role? Is the Mastercard sandbox environment currently broken, or is there a Mastercard test card that works? Happy to capture a sysdiagnose with the Wallet logging profile if that helps.

I've tried to add the "Pass Type Identifiers" entitlement manually in .entitlements, but it will not archive and shows the error: Entitlement com.apple.developer.pass-type-identifiers not found and could not be included in profile. This likely is not a valid entitlement and should be removed from your entitlements file. It works correctly for the App (parent of ), but without it the App Clip can't see any passes. The documentation says this should be possible: Note In iOS 17 and later, App Clips can use the Wallet capability. For more information on functionality that’s available to App Clips, see Choosing the right functionality for your App Clip. It is not visible in the portal either. Is this an entitlement that I need to specifically request, and if so, how would I go about doing so? Thanks! Wes

Hi, We received a notice that our Pass Type ID certificate will expire soon, and we plan to renew it for the same Pass Type ID (we will not create a new identifier, and we will not revoke the old certificate until the new one is in place). Our app adds payment cards to Apple Wallet via in-app provisioning (PKAddPaymentPassViewController / com.apple.developer.payment-pass-provisioning). We do not sign or distribute .pkpass files with this certificate. The app entitlement com.apple.developer.pass-type-identifiers includes our existing Pass Type ID. Developer Support pointed us to the standard certificate overview: if the certificate expires, installed passes keep working, but we can no longer sign new passes or send updates. That sounds like generic Wallet passes, not payment-card provisioning. Could someone from Apple confirm: If we renew the Pass Type ID certificate for the same identifier, will Add to Wallet for payment cards still work for current users (no need to remove and re-add the card)? After renewal, can users add new payment cards as usual? Is the Pass Type ID certificate required for in-app provisioning, or do we only need the Pass Type ID identifier in entitlements? Thanks.

Hi All, We build a new feature according to the Apple docs: In iOS 17 and later, App Clips can use the Wallet capability. For more information on functionality that’s available to App Clips, see Choosing the right functionality for your App Clip. and based on that we proceeded with our development, our but in our appclip we are not able to see the wallet capability in the developer portal but for our main application the wallet is there and we enabled it and therefore the com.apple.developer.pass-type-identifiers entitlement has been added to our main app and the appclip, the signing for the main app is working fine, but for the appclip we are getting this issue: Entitlement com.apple.developer.pass-type-identifiers not found and could not be included in profile. This likely is not a valid entitlement and should be removed from your entitlements file.

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’m trying to request an NFC PassKit Certificate through https://developer.apple.com/contact/passkit/. After clicking Send, the completed form is POSTed successfully and receives 200 OK, but the server returns the original form instead of a confirmation page. The page’s passkit.js then clears all fields, and Developer Support confirmed that my earlier submission was never received. Has anyone else encountered this behavior or found another way to submit the NFC PassKit Certificate request?