Hi Support,
When the applepay express transit option is used on emv payment cards, like this iPhone - Open “Settings” → “Wallet & Apple Pay” → “Express Transit Card”. And a emv single card has been enabled under Express Transit
And on transit reader Apple Enhanced contactless Polling support is provided, ( with VAS not supported, user authentciation not supported)
Sometimes ATQB response also comes from the iPhone or iWatch instead of the ATQA response, and then it causes the transit reader to report as collision error in the polling.
Sequence of the packets:
WUPA WUPB ECP frame WUPA WUPB ATQB WUPA ATQA
Hi @JakeHess,
You wrote:
[...] Sometimes ATQB response also comes from the iPhone or iWatch instead of the ATQA response, and then it causes the transit reader to report as collision error in the polling. [...]
When the ECP 2.0 frame is received, the iPhone/Apple Watch NFC controller begins activating the Express Transit card emulation profile. During this transient activation window (typically a few milliseconds), the NFC controller's card emulation layer is not yet fully configured to the target technology type (Type A for EMV). As a result:
- The NFC controller may briefly respond to both WUPA and WUPB solicitations
- The spurious ATQB is emitted during this intermediate state
- On the next polling cycle the controller has settled, and only ATQA is returned
The reader's anti-collision logic then sees responses on both Type A and Type B in the same discovery loop, interprets this as multiple targets or a collision, and flags an error.
Important: First confirm the ATQB is truly originating from the Apple device and not from a physical contactless card (e.g., a bank card in a phone case or wallet held near the reader). If you are also seeing this with physical EMV cards (not just Apple devices), that would indicate a separate reader-side anti-collision issue and show be investigated independently.
That said, the reported behavior is more frequently triggered when the reader's polling loop is particularly fast (short inter-command gaps), because the WUPB arrives while the NFC controller is still in its transient state.
I'd submit a Feedback Assistant report for this behavior to learn more about the underlying controller architecture, if possible. However, I don't believe the ATQB response is a bug or malfunction — it's likely a direct result of the architectural separation between Apple's NFC controller hardware layer and the ECP middleware layer, and is a fully valid, well-formed ISO 14443-3B response.
These two layers operate asynchronously and independently. The NFC controller hardware responds to WUPB before the ECP middleware has finished processing the ECP frame and issuing the Type B suppression instruction to the NFC controller. This irreducible latency on the SWP/HCI path between the application process (where the ECP runs) and the NFC controller SE interface makes it impossible for the NFC controller to suppress its ATQB in time.
I'd be interested to learn if your ECP frame's Technology Indicator byte is correctly set. If it's set to include Type B technologies, you're explicitly inviting the Apple device to respond on both technologies. To confirm this, verify your ECP frame byte-by-byte. Setting this to 0x01 (Type A only) is the most direct way to signal to the Apple device that Type B is not needed, though as noted above it doesn't eliminate the race condition entirely due to the async processing window.
Cheers,
Paris X Pinkney | WWDR | DTS Engineer
