Repository navigation
[Bug]: Contact payment options temporarily disappear after cancelling confirmation #1524
Description
What happened?
USDT and Lightning become unavailable intermittently in the contact-send funding picker, then recover after the apps have had time to reconcile. The recipient has Contact payments enabled. This also occurred after cancelling an available USDT payment at confirmation without swiping. Eventually all options returned and the reporter successfully sent a payment.
The earlier recording shows the unavailable options. The subsequent cancellation/recovery sequence below is the reporter’s observation; the recording does not capture that entire sequence. Recovery timing has not been measured.
Expected behavior
Cancelling before payment authorization should not make supported contact payment methods appear unsupported. If fresh recipient endpoints must be reconciled, show a clear loading/pending state and refresh available methods when ready.
Steps to Reproduce
- With Contact payments enabled on the receiving iPhone, open the contact-send flow on Android.
- Once USDT is available, select it, enter an amount and open the swipe-to-pay confirmation.
- Dismiss/cancel the sheet without swiping or authorizing payment.
- Return to contact Send and inspect the funding-source picker: USDT and Lightning can now be unavailable.
- Retry/wait while the apps reconcile. The methods eventually become available again.
- Reporter subsequently completed a payment successfully. Sending funds is not required to investigate the preceding cancellation behavior.
Logs / Screenshots / Recordings
2026-10-16-contact-payment-options.mp4
Sanitized diagnostic summary: Android opened private payment list version 56 at 14:06:50 CEST; later resolutions used version 57 at 14:13:30, 14:18:39 and 14:21:29, after consumed version 32. Logs do not expose the resolved endpoint payloads or pinpoint each enabled/disabled transition. No raw wallet logs are attached.
Bitkit Version
3.0.0 RC2 (193), mainnet; release revision 19449fb0d729f51b9875eee2f66acfc0671e11da.
Device / OS
Samsung Galaxy S22 (SM-S901B), Android 16. Recipient for contact-payment tests: iPhone 13, iOS Bitkit 3.0.0 (200).
Reproducibility
Intermittent, observed repeatedly by the reporter; methods eventually recover. No reliable failure percentage or reconciliation duration yet.
Additional context
Confirmed mechanism, exact cause unconfirmed: AppViewModel.kt:4704 enables USDT from usdtRecipient and Lightning from a decoded Lightning/LNURL/unified target. openPaykitEndpoints populates those targets from resolved contact endpoints. Missing usable targets therefore disables rows independently of sender balance. Private endpoint resolution filters unusable invoices; endpoint publication, resolution and send-state refresh need correlation around cancellation to locate where methods are lost.
Do not attribute this to disabled recipient settings: a fresh snapshot confirmed public/private Contact payments enabled and cleanup no longer pending, and the issue was reported after that. Do not claim cancellation consumed the private list: inspected consumption occurs during payment execution; the cancellation path clears contact context.
Related latency context: Android #1488, Android #1419 and iOS #868. This report concerns transient funding-option loss/recovery after cancellation, rather than general contact linking latency. Separate from the contact-picker loading feedback gap.
Activity
ben-kaufman commentedon Oct 18, 2026
I checked the current cancellation and private-list consumption paths. Cancelling before authorization clears the active contact context; list consumption happens during payment execution. The existing cancellation tests pass, so I have not confirmed that cancellation itself removes the methods.
#1564 adds the missing contact-resolution loading feedback, but does not claim to fix this separate availability issue. Keeping this open: the next useful reproduction needs the resolved method set and private-list version immediately before cancellation and on the next attempt, on both wallets. No additional payment is needed for that check.