Additional context: This does not appear to be an issuer-specific provisioning problem. The same device previously provisioned Apple Pay cards normally on iOS 26, and the failure has now been reproduced through both first-party Wallet provisioning and issuer-app initiated provisioning. I have also tested different network conditions and previously reset network settings without changing the behavior. The consistent symptom is that provisioning reaches the stage immediately before the Terms & Conditions UI should be presented, but that UI never successfully appears. In the Beta 7 sysdiagnose, SESUIServiceApp is launched during the failed provisioning attempt, but is later observed in a suspended/background state while the expected Secure Element storage-management UI has not been presented. This makes me suspect that the failure is not simply an issuer decline, but may involve the system presentation/lifecycle path used by SESUIServiceApp / SEStorageManagementSheet. If possible, could DTS please compare the Beta 6 and Beta 7 diagnostics attached to FB24403156 and confirm whether this Feedback has been routed to the Wallet / Apple Pay / Secure Element engineering team? I am happy to capture an additional sysdiagnose or reproduce the issue again if engineering needs a specific timestamp or additional diagnostic information.

Update — iOS 27 Beta 7 (24A5424a) This issue is still reproducible after updating to iOS 27 Beta 7. I reproduced the failure again with multiple issuers. East West Bank eventually displays an error without ever presenting the Terms & Conditions screen, while Mercury fails to present the Terms & Conditions screen and does not display a final error at all. A new Beta 7 sysdiagnose has been captured and added to FB24403156. Could an Apple DTS engineer please help review or route FB24403156 to the appropriate Wallet / Apple Pay / Secure Element engineering team? The issue has now reproduced consistently across both Beta 6 and Beta 7.