Twin: synonymdev/bitkit-ios#863
Refs: #1407
What happened?
During Pubky Shop canary #3 (fresh profile The Piotr 3, order c62d186d, pay ₿1,753 — payment succeeded), several Paykit payment-request UX nits on Android:
- Notification without auto-open — Payment bell / notification arrived, but Bitkit did not automatically present the pay / payment-request sheet. Had to open it manually.
- Sheet sizing / scroll — The Payment Request sheet is not correctly sized. You can scroll it so content clips: either the large amount is cut off at the top, or the slide-to-pay control is cramped / partially covered at the bottom (system nav overlap).
Payment itself completed (Shop Payment seen). This ticket is UX polish / layout from that successful path; the slow pay sheet and confirmation are tracked in #1407 — not delivery failure (#1402 is the restore/recovery_required case).
Marketplace canary thread: BitcoinErrorLog/pubky-marketplace#54.
Expected behavior
- When a Shop/Paykit payment request arrives while Bitkit is in foreground (or user taps the payment notification), the payment-request / pay sheet should open (or product should document that bell = notify-only). Related work: #1350.
- Payment Request sheet should fit the viewport without clipping the amount or the slide-to-pay control; scroll should not hide primary chrome.
Steps to Reproduce
- Fresh Bitkit mainnet profile; add seller Pav C Tester as contact.
- Checkout a Pubky Shop listing that delivers a private Paykit payment request (~1k sats + payment code).
- Keep Bitkit open / watch for payment notification / bell.
- Observe: bell/notify without auto sheet; open pay manually.
- On Payment Request sheet, scroll — amount clips at top and/or slider is cramped at bottom.
Logs / Screenshots / Recordings
| Sheet top OK (slider visible) |
Scrolled — amount clipped |
 |
 |
Session logs:
bitkit_logs_2026-10-01_09-44-08.zip
09:23:59 WARN PaykitPaymentRequestRepo — Timed out inspecting payment request support for 'pubkyad…'
09:24:35 WARN PaykitPaymentRequestRepo — Timed out inspecting payment request support for 'pubkyad…'
09:26:24 INFO PrivatePaykitRepo — Opened private Paykit payment for 'pubkyad…xmnjdcy'
09:26:45 INFO AppViewModel — Decoded incoming Paykit payment request target
09:27:14 INFO PrivatePaykitRepo — Consumed private Paykit payment list version 0 …
09:27:31 INFO Keychain — Upserted 'PAYKIT_PRESENTED_PAYMENT_REQUESTS'
09:27:48 INFO Keychain — Upserted 'PAYKIT_PRESENTED_PAYMENT_REQUESTS'
09:27:54 INFO Keychain — Upserted 'PAYKIT_PENDING_PAYMENT_PROOFS'
09:27:59 INFO LightningService — Sending 1753 sats to bc1qtnxlssr8x7pwas3xasqz8zzrkmz6gru7prpqkq, satsPerVByte=1
09:27:59 INFO AppViewModel — Onchain send result txid: a71b5a8e…
09:29:47 DEBUG Keychain — Deleted 'PAYKIT_PENDING_PAYMENT_PROOFS'
~46s between Decoded incoming (09:26:45) and first PRESENTED (09:27:31) matches “bell / request arrived but pay sheet not auto-opened; had to open manually.”
Bitkit Version
Mainnet debug 2.5.0 (190), master @ dbbf90f02
Device / OS
Samsung Galaxy S22 (SM-S901B), Android 16
Reproducibility
Often (>50%) — seen on this canary run; layout always scrollable into a bad state once on the sheet.
Additional context
Twin: synonymdev/bitkit-ios#863
Refs: #1407
What happened?
During Pubky Shop canary #3 (fresh profile The Piotr 3, order
c62d186d, pay ₿1,753 — payment succeeded), several Paykit payment-request UX nits on Android:Payment itself completed (Shop Payment seen). This ticket is UX polish / layout from that successful path; the slow pay sheet and confirmation are tracked in #1407 — not delivery failure (#1402 is the restore/
recovery_requiredcase).Marketplace canary thread: BitcoinErrorLog/pubky-marketplace#54.
Expected behavior
Steps to Reproduce
Logs / Screenshots / Recordings
Session logs:
bitkit_logs_2026-10-01_09-44-08.zip
~46s between Decoded incoming (
09:26:45) and first PRESENTED (09:27:31) matches “bell / request arrived but pay sheet not auto-opened; had to open manually.”Bitkit Version
Mainnet debug
2.5.0(190),master@dbbf90f02Device / OS
Samsung Galaxy S22 (SM-S901B), Android 16
Reproducibility
Often (>50%) — seen on this canary run; layout always scrollable into a bad state once on the sheet.
Additional context
c62d186d; amount ₿1,753; sent ₿1,894 incl. fee.Przesuń, aby zapłacić).