[Bug]: USDT subscription requires a second payment confirmation while Bitcoin is one-step #981

What happened?

During paired mainnet RC2 testing, accepting a subscription paid in USDT required the subscribe authorization followed by an additional payment flow/confirmation. The reporter observed this on both Android and iOS. In the subsequent on-chain Bitcoin control test in both directions, one subscribe step completed the initial payment.

This is a USDT initial-payment flow/design discrepancy, not a claim that every second authorization is unsafe or unnecessary in all pricing/signing cases.

Expected behavior

Align the standard eligible initial-payment flow with Figma v63 — Review & Subscribe → Subscribed: one informed subscribe-and-pay authorization, followed by completion. If USDT requires an additional quote/fee/method review, make that requirement explicit and confirm the intended exception with design. Preserve final amount/fee review, quote expiry, PIN/biometric and hardware/manual-coin safeguards. Do not remove payment guards merely to eliminate a step.

Steps to Reproduce

1. Create a subscription for the paired contact, with the USD/USDT payment option.
2. On the subscriber, open Review & Subscribe and authorize subscription.
3. Observe the additional amount/payment review and USDT payment confirmation.
4. Complete the initial payment.
5. Compare with a Bitcoin subscription paid from Savings/on-chain: the reporter completed that control with one subscribe step on both devices.

For the on-chain controls, iOS sent the first proposal to Android, then Android sent one to iOS. The reporter performed all payments; no agent payments were made.

Logs / Screenshots / Recordings

18:30:25.021 iOS Showing sheet subscription
18:30:55.435 iOS Opened private Paykit payment [contact redacted], list version 107
18:31:21.161 iOS send(_:submissionDeadline:beforeSubmission:) took 3.99 seconds on core queue
18:31:24.867 iOS Hiding sheet subscription: SendSheet.swift:862 viewForRoute(_:)
18:31:26.978 iOS Queued a Paykit payment proof for private delivery
18:31:35.201 iOS Hiding sheet paymentRequests: No pending payment requests

Times are 2026-10-16 Europe/Warsaw (UTC+02:00), converted from UTC app logs. Selected messages only; contact keys, addresses, transaction hashes and request payloads omitted. Generic presentation/proof events lack request IDs, so they cannot prove duplicate request identity or a common race. User interactions were not recorded with timestamps; screen-open-to-close intervals include reading/input time.

The two-step observation is reporter evidence; logs support the payment path and completion, not a count of swipes. iOS on-chain control explicitly logs “Initial subscription payment completed” at 18:49:03.136.

Bitkit Version

3.0.0 RC2 (200), mainnet, revision 59278ad871381f8ac4b9d4d0f70953643d59243e. Paired Android 193 / iOS 200.

Device / OS

Samsung Galaxy S22 (SM-S901B), Android 16 / API 36; paired iPhone 13 (iOS version not captured).

Reproducibility

Reported on both USDT subscription directions in this session. On-chain controls were one-step on both. Repeat rate across wallets, methods and quote states is not measured.

Additional context

Source mechanism: subscription accept routing routes through asset selection when requiresAssetSelection is true. The shared USDT confirmation renders a separate SwipeButton. The BTC initial-subscription path has conditional auto-start.

Pricing clarification: RC2 subscription creation supports BTC or USD denomination. USD-priced subscriptions settle through USDT and can carry a 1:1 USD→USDT conversion record. Do not describe this as a proven absence of conversion or as a BTC market conversion. Exact proposal/pricing payload was not logged in the supplied excerpts.

Related: Android #1468 / iOS #920 are closed historical on-chain second-swipe bugs. Current on-chain controls support that fix; the separate USDT route remains the concern. Companion: synonymdev/bitkit-android#1540.

Separate from stale post-payment request presentation (Android #1534) and latency (Android #1407, #1419). No common root cause established.

Current related reports

• Android two-step USDT subscription #1540 / iOS counterpart #981.
• Android stale request #1534 / iOS stale subscription request #982.
• Android latency #1407, shared-runtime latency #1419 / iOS #868.

These reports track separate behaviors; a shared root cause is not established.