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)

We are currently supporting an Apple Pay-enabled card program as an issuer/issuer processor and have successfully completed In-App Push Provisioning integration within our iOS application. The in-app flow is fully operational, including issuer-side cryptographic exchange and Mastercard MDES network tokenization. We are now looking to extend this integration to support Apple Pay Web Push Provisioning, allowing cardholders to add eligible cards to Apple Wallet directly from our web application. We would appreciate guidance on: -The process for enrolling in Apple Business Register (if required) -Enabling Web Push Provisioning for an issuer profile Required entitlements or provisioning certificates Any additional onboarding steps specific to issuer-level Web provisioning We understand that Web Push Provisioning requires issuer-level enablement beyond standard Apple Pay on the Web, and we would like clarification on the correct path to activate this capability. Thank you in advance for your guidance.

Hello, guys. I am going through a situation in which an open validation appears in the system/developer mode and I would like to understand better if this is something normal in this process. Could someone confirm if this type of validation is expected at this stage? I would also like to know what criteria I can observe to be sure that it is legitimate and that I can trust the activation. Thank you in advance for your attention and help. Thank you

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

Dears, Please review: FB21940123 (Wallet Extension unable to add card) Thanks,

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.

Hello, I'm implementing the wallet extension but I found a problem in the passEntries function. This following part is giving nil ando I don't know why if let entry = PKIssuerProvisioningExtensionPaymentPassEntry( identifier: element.id, title: element.cardType ?? "Card", art: self.testImage()!, addRequestConfiguration: config! ) { entries.append(entry) } I debug and all the arguments have information but it doesn't create the entry

Hello, I'm implementing the wallet extension for a financial app. Right now I'm having a problem, I want to redirect to the main app when the user hasn't logged in. Is it possible? This is my code in the WalletUI. It just doesn't work. let urlString = "bank://login" guard let url = URL(string: urlString) else { return } self.extensionContext?.open(url, completionHandler: { success in if !success { print("Success") } else { self.completionHandler?(.canceled) } }) }

Hello there, We’re currently integrating Apple Wallet pass functionality into our application and am looking for clarification around the automatic update flow. Particularly regarding secure management of the authenticationToken. We’ve reviewed the documentation here: Adding a Web Service to Update Passes authenticationToken Documentation From our understanding: When a user downloads a pass from our service, the .pkpass includes both a webServiceURL and an authenticationToken. Once the pass is added to Wallet, the Wallet app makes authenticated requests to our webServiceURL, using the token in the Authorization header. We then validate this token server-side to serve updates or handle device registration. So far, this flow is clear. However, we’re looking for clarification on two key scenarios: If a user adds the same pass twice on the same device, should the authenticationToken remain the same in both cases? If the same user adds the same pass on a different device, should the authenticationToken also remain consistent across devices? If the answer to both is “yes,” we assume that our backend must store the original authenticationToken in a retrievable form (not just as a hash) to regenerate the same pass for re-download or multi-device sync. Our main question is: What is Apple’s recommended or acceptable approach to storing authenticationToken values securely on the backend? Should these tokens be: Stored in plaintext (e.g. in a protected DB field)? Encrypted using a symmetric key? Hashed (not reversible, but limits reuse)? We want to ensure we align with Apple’s best practices for Wallet security and token management, especially in contexts where the same pass may be installed on multiple devices or reissued later.

In Xcode, under Signing & Capabilities (Release) for our bundle ID the selected provisioning profile does include the entitlement: com.apple.developer.payment-pass-provisioning However, when we upload a new build to TestFlight, the Build Metadata → Entitlements section for the same bundle ID does not include com.apple.developer.payment-pass-provisioning. Because of this, PKAddPaymentPassViewController does not open in TestFlight builds. This suggests that while the entitlement is enabled for the App ID and visible in Xcode, it may not yet be propagated to App Store Connect’s signing service for TestFlight/App Store builds. Please Note: The Wallet Entitlements team had confirmed that they had granted entitlements for our team and the apple IDs Xcode : 26.0.1 Profile being used: Distribution Profile

I'm implementing the in app provisioning in a financial project. I got my entitlement identifier, I'm also implementing the wallet extension but I have the problem with Xcode. Domain: IXUserPresentableErrorDomain Code: 1 ... NSExtensionPointIdentifier key in the NSExtension dictionary in its Info.plist that does not correspond to a known extension point. But I'm not sure what does this mean, I reviewed the info.plist form the project and the wallet extension

Hello everyone, My team is exploring the implementation of an Apple Wallet pass for a loyalty program linked to a brand in an age-restricted product category. The intended use cases for the Wallet pass are: Member identification at events — Quick verification at brand events or exclusive venues, with tier-based perks (e.g., priority entry for higher tiers) Support services — Members present their card at retail locations to receive assistance Tier and points display — Dynamic visual changes based on loyalty level and current points balance Notifications — Pass updates for expiring points, upcoming events, or relevant announcements The pass would function as a standard Store Card (membership/loyalty) — no payments, no stored value, just identification and informational display. Before investing development effort, I'd like to understand: Has anyone successfully implemented Wallet passes for brands in restricted categories (tobacco, alcohol, etc.)? Are there specific guidelines or restrictions I should be aware of beyond the standard Wallet documentation? Is there a recommended channel to get official guidance from Apple on eligibility before building? Any insights or experiences would be appreciated. Thanks!

Hello Dear Network, We are developing a banking application and are implementing Apple Wallet In-App Provisioning with Wallet UI and Non-UI extensions. Our App Store submission fails with the error: "Missing entitlement com.apple.developer.payment-pass-provisioning" for both Wallet UI and Non-UI extensions. In the Apple Developer portal, we do not see the "Apple Pay" or "In-App Provisioning" capabilities available for our App ID or extension App IDs. We would like to request enablement of: Apple Pay Payment Pass Provisioning In-App Provisioning for our Apple Developer Team and related App IDs. Please let us know what we need to do for can upload build with that Entitlements, what can be problem? Thank you.

Hi, We are distributing pk pass files via a web browser. When a user taps Add in the system pass preview, the pass is added successfully, the preview is dismissed, and the user remains in the browser. From a user experience perspective, we would like to better guide users to their newly added pass in Apple Wallet. Is there a supported API, URL scheme, or documented mechanism that allows a web-based flow to transition the user to the Wallet app after a pass has been added? If direct app transitions are not supported in this scenario, what is the recommended best practice for helping users locate and open their newly added pass in Wallet? Thank you for your guidance.

Hi, When I try to add a card to wallet, I get this PKPassKitErrorDomain Code=2 error from my logs, and from the SysDiagnose, I get some more detailed error log Error details: Date: December 15, 2025 Time: 15:16 UTC Request URL: https://nc-pod9-smp-device.apple.com:443/broker/v4/devices/041B4183BA1490022104102123315131EBFE2BE7… Response: HTTP Status: 500 – Internal Server Error Time profile: 0.505452 seconds Response headers: Server: Apple Content-Type: text/html X-Content-Type-Options: nosniffStrict-Transport-Security: max-age=31536000; includeSubdomainsDate: Mon, 15 Dec 2025 15:16:59 GMT X-Frame-Options: SAMEORIGIN X-XSS-Protection: 1; mode=blockCross-Origin-Opener-Policy: same-origin Content-Length: 170 Connection: close Response body: Anyone have faced this problem before?

I´m tring to integrate InApp push provisioning but when I send the information from the issuer to SDK to add my debit card to wallet I saw this error: PKPassKitErrorDomain Code 2 error Looking in the forum I found how to see part of the logs to get more detail on the error and I found: POST https://pr-pod9-smp-device.apple.com:443/broker/v4/devices/04131B65D01590022288082867404947F3CCA674C3D41F3C/cards/683986c983984251b9aecfc8ff51d88a/enable 'Error Domain=PKPaymentWebServiceErrorDomain Code=0 "Error inesperado." UserInfo={PKErrorHTTPResponseStatusCodeKey=500, NSLocalizedDescription=Error inesperado.

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.

Hello, I'm using PassKit with to perform Apple Pay payment in a financial application. Our approach are: On iOS application, define PKMerchantCapability threeDSecure and credit, perform apple pay experience and get the encrypted response. On PCI service, receive the encrypted data Payment token, decrypt this data, and use to perform the payment. The problem is, in MasterCard transaction the eciIndicator is missing. I want to know if has some rule or problem about it.

I'm creating an event ticket Apple Wallet Pass and setting a light-coloured background image. When I do this, it automatically sets the foregroundColor to white, even when I explicitly set it to black. What's strange is that on my Mac, the foregroundColor appears as intended, and I can set it to any color I want, but when I AirDrop the pass to my iPhone, it sets the color to white, regardless of what I set the foregroundColor to. This means the text becomes completely illegible for my users, with white text on a white background image. If I remove the background image, the foregroundColor works fine. Is there a way to have a light-colored background image with dark text, or am I forced to have a dark-colored background image? Here are the colors in my pass.json: backgroundColor: "rgb(255, 255, 255)" foregroundColor: "rgb(0, 0, 0)" labelColor: "rgb(0, 0, 0)" I've attached what the pass looks like on my Mac and my iPhone.

Hi, I am developing an app that uses the Host Card Emulation (HCE) technology available on iOS. Our team is using the official HCE app entitlement, and we are testing the SDK’s behavior when the app is selected as the default contactless payment application. On devices located in supported regions, the system automatically displays a setting where the user can choose the default app. For colleagues who are located in those regions, the toggle appears normally. For development and QA purposes, I would like to understand whether there is an officially supported method to test the default-app selection behavior on devices that are not in a region where the feature is available. Any guidance on the correct testing approach would be appreciated. Thank you!