[Bug]: Stale payment request remains briefly actionable after initial USDT subscription payment #982

What happened?

After subscribing and completing the initial USDT payment on iOS, a payment-request notification remained briefly available. The reporter could tap it, but it disappeared after a few seconds and showed that the request was no longer available. The reporter observed the same sequence on Android.

No second payment was observed. This report concerns a stale actionable notification/request presentation, not proven duplicate request creation or duplicate payment execution.

Expected behavior

Once the initial payment is committed/submitted, suppress the corresponding actionable request while proof delivery/reconciliation continues. Keep an appropriate pending/completed state. Tapping stale UI should not invite another payment flow and then end in an unavailable toast.

Steps to Reproduce

1. Create a USD-priced/USDT-settled subscription on Android for the iOS contact.
2. On iOS, subscribe and complete its initial USDT payment.
3. Immediately inspect the payment-request notification/bell.
4. While the stale request remains, tap it.
5. Observe it disappear after reconciliation with a no-longer-available message.

Observed sequence, not a deterministic timed reproduction. No video captures exact visibility duration.

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 no-pending cleanup occurs 8.223 seconds after the proof-queue event and 10.334 seconds after closing the subscription sheet. Neither interval equals a measured notification-visibility duration. The toast itself is reporter-observed, not logged in these excerpts.

Bitkit Version

3.0.0 RC2 (200), mainnet, 59278ad871381f8ac4b9d4d0f70953643d59243e; counterparty Android RC2 (193).

Device / OS

iPhone 13; iOS version not captured. Counterparty Samsung Galaxy S22, Android 16.

Reproducibility

Reporter observed on both platforms after USDT subscription payment. Exact duration/rate and on-chain parity for this transient notification were not established.

Additional context

Hypothesis, not confirmed root cause: stale pending/presentation state may survive payment submission until an SDK/proof refresh removes it. Correlate request IDs, recurring billing period, accepted/pending membership, proof state and presentation generation around sheet cleanup.

Related: Android #1534 tracks transient request reappearance; the follow-up adds this subscription sequence without asserting identical cause. iOS #737 is a closed historical just-paid-request requeue race, useful context but not proof of the same mechanism. Separate two-step USDT subscription reports: Android #1540 / iOS #981.

The initial on-chain subscription path is one-step in the reporter’s control tests; this report must not imply the notification occurred in those controls unless separately confirmed.

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.