We are working with a large fintech org on project connected with provisioning payment cards to Apple Wallet.
When we add a previously provisioned card to the Wallet (using the Wallet UI, Add card -> Previous card). It adds the card on one device showing the Express Travel card screen after the card is added allowing the user to set the card as an express travel card during the provisioning flow but never on our other devices. All of the test devices are clean and have only the same single card provisioned.
What triggers the Express Travel Card screen to be shown during the add previous card flow? (Why is it showing on one device and not another).
Hi @robinhayward,
You wrote:
What triggers the Express Travel Card screen to be shown during the add previous card flow? (Why is it showing on one device and not another).
This is likely due to a multi-gate eligibility system behind the Express Travel setup flow. I'd suggest for you to capture screen recordings and sysdiagnose logs on both devices so the Wallet engineering team can investigate. See the post below for more details on the bug reporting process:
Gathering Required Information for Troubleshooting Apple Pay In-App Provisioning or In-App Verification Issues
https://developer.apple.com/forums/thread/762893
As I said above, the Express Travel setup screen isn't controlled by a single flag. It's the result of a multi-layered AND gate — every condition must pass simultaneously. If any one gate files, the screen is suppressed with no error.
The most foundation gate is the BIN/INN card product registration. If your card's BIN is not registered as Express Transit eligible in Apple's backend, the screen will never appear regardless of any other condition or configuration on the device.
However, the most variable (as well as the most common real-world) cause of this discrepancy is the TSP provisioning response. The TSP returns a capability manifest with each provisioning response. This manifest includes a per-token Express Transit flag that controls whether that specific provisioned token instance is Express Transit capable. You'll need to confirm with your TSP on this exact configuration for your BINs.
Furthermore, despite appearing to the suer as a restore, the "Add Previous Card" flow is technically a complete new provisioning event:
- Apple identifiers the previous card by
primaryAccountIdentifier - A new provisioning request is sent to the TSP
- The TSP generates a new DPAN / token (or re-activates per token lifecycle policy)
- A new provisioning response is returned with current capability flags at that moment in time
This means if the issuer updated their Express Transit configuration with the TSP between two provisioning events, Device A (provisioned earlier) gets expressTransit: false, for instance, and Device B (provisioned later) gets expressTransit: true. The older device's Secure Element configuration is frozen at provisioning time and doesn't automatically update.
Lastly, when you mentioned "All of the test devices are clean", please note that a device reset does not always fully clear the Secure Element state. A full DFU restore (not just "Erase All Content and Settings") is required to guarantee a fully clean SE state for testing purposes.
Cheers,
Paris X Pinkney | WWDR | DTS Engineer
