We are integrating Apple Pay In-App Provisioning in our banking application using an external SDK. The provisioning flow works on the iOS Simulator (mock sheet appears), but fails on real devices via TestFlight with the error:
internalInconsistency: "PKAddPaymentPassViewController can not be created"
Environment:
- Xcode 16
- iOS 18
- Real device: iPhone (tested via TestFlight / Distribution build)
- Card network: Mastercard
What we've verified:
com.apple.developer.payment-pass-provisioningentitlement is set toYESin our.entitlementsfile- The entitlement is confirmed present in our Development provisioning profile via
security cms -D -i embedded.mobileprovision | grep payment-pass→ returns<true/> PKAddPaymentPassViewController.canAddPaymentPass()returnstrueon the device- The card is NOT already in Apple Wallet (0 local/remote Secure Element passes)
- All provisioning data is present and valid (encryptedPayload, authorizationCode, primaryAccountSuffix, cardholderName)
- The external SDK is configured successfully at app launch
Diagnostic logs from TestFlight build:
canAddPaymentPass: true
Local SE passes: 0
Remote SE passes: 0
suffix: 6165
name: [redacted]
encryptedPayload length: 1130
authCode length: 514
scheme: Mastercard
Card already in Wallet: false
Error: internalInconsistency("PKAddPaymentPassViewController can not be created")
Testing matrix:
| Simulator | Mock sheet appears (not a real test) |
| Device + Debugger attached | PKAddPaymentPassViewController error |
| Device + Debugger detached (Dev build) | SDK error 903: "device environment unsafe" |
| TestFlight (Distribution) | PKAddPaymentPassViewController cannot be created |
Questions:
- Can
PKAddPaymentPassViewControllerfail to be created even whencanAddPaymentPass()returnstrue? What other conditions could cause this? - Is there a way to verify that the Distribution provisioning profile correctly includes the
payment-pass-provisioningentitlement after it has been approved by Apple? - Are there any additional Apple Pay entitlements or configurations (e.g., Wallet merchant setup, pass type identifiers) required beyond
com.apple.developer.payment-pass-provisioningfor In-App Provisioning to work? - Does regenerating the Distribution provisioning profile on Apple Developer Portal resolve cases where entitlements were added after the profile was originally created?
Any guidance would be greatly appreciated. Thank you.
You wrote:
[...] Can PKAddPaymentPassViewController fail to be created even when canAddPaymentPass() returns true? What other conditions could cause this? [...]
Yes, absolutely. These two checks operate at completely different layers:
- canAddPaymentPass() checks device-level eligibility and has zero knowledge of your app's entitlements or allow list status.
- PKAddPaymentPassViewController initialization performs a signing/entitlement validation agains the provisioning profile embedded in the binary at runtime. If the profile doesn't include the entitlement, the instantiation is aborted and an error is thrown immediately.
There are other conditions that can cause these errors when when canAddPauymentPass() returns true:
- Entitlement present in
.entitlementsfile but absent from your provisioning profile. This is most likely the scenario you're facing. - Debugger attached. PassKit explicitly refuses to create the controller when a debugger is detected.
- App ID configuration has not enabled capability. Ensure the provisioning profile was generated after the App ID enables the capability.
- Bundle ID mismatch. ensure the running app and the ID contained in the provisioning profile are identical.
- Entitlement not distribution approved. In-App Provisioning is a managed entitlement with a separate approval process for production use. Please contact the provisioning team that granted your original entitlement request to learn about the distribution verification process.
Next, you wrote:
[...] Is there a way to verify that the Distribution provisioning profile correctly includes the
payment-pass-provisioningentitlement after it has been approved by Apple? [...]
You must inspect the actual .ipa submitted to TestFlight to confirm this:
# 1. Rename and unpack the .ipa
cp YourApp.ipa YourApp.zip && unzip YourApp.zip -d AppContents
# 2. Decode the embedded provisioning profile inside the binary
security cms -D -i AppContents/Payload/YourApp.app/embedded.mobileprovision > decoded_dist.plist
# 3. Check for the entitlement
/usr/libexec/PlistBuddy -c "Print :Entitlements" decoded_dist.plist | grep payment-pass
If properly entitled/provisioned, you should see:
com.apple.developer.payment-pass-provisioning = true
If that key is missing from the decoded Distribution profile, this confirms the issue. You can also verify via codesign, where the output XML must include com.apple.developer.payment-pass-provisioning:
codesign -d --entitlements - AppContents/Payload/YourApp.app
Then, you wrote:
[...] Are there any additional Apple Pay entitlements or configurations (e.g., Wallet merchant setup, pass type identifiers) required beyond
com.apple.developer.payment-pass-provisioningfor In-App Provisioning to work? [...]
The Wallet In-App Provisioning capability must be explicitly enabled on your App ID in the Developer portal. This is separate from having it in the .entitlements file.
Also, the app's Adam ID must be approved and added to the allow list. To learn more about that process, see below:
Apple Pay on the Web Demo: In-App Provisioning
https://applepaydemo.apple.com/in-app-provisioning#5
Lastly, you wrote:
[...] Does regenerating the Distribution provisioning profile on Apple Developer Portal resolve cases where entitlements were added after the profile was originally created? [...]
Yes, and I recommend you do so. Please see my answer on this post below for more details:
Xcode 26.4 Debug Schema is not building.
https://developer.apple.com/forums/thread/822642?answerId=893503022#893503022
Cheers,
Paris X Pinkney | WWDR | DTS Engineer
