You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
feat: make payment requests findable from the drawer #1624
Incoming Paykit payment requests, including expired ones (for example a Pubky Market order request), only appear under drawer → Subscriptions → the second tab, Payments. Nothing in the app points there, so a user looking for a payment request has no reason to open Subscriptions. The bell on Home lists requests, but only while they are pending.
Found during a mainnet Shop checkout on Bitkit 3.0.1: the feedback was that the drawer label is misleading and that finding payment requests in a second tab of Subscriptions takes guesswork.
Proposed solution
Pending design. Naming: "Payments" is the preferred label; "Purchases" or "Orders" are fallbacks if "Payments" collides with existing Bitkit terms. The final name is a design call. Options:
Rename the drawer entry to cover both, for example "Payments", with Subscriptions as one of its tabs.
Make payment requests the first tab.
Give payment requests their own drawer entry.
Whichever is chosen, a user finds pending, paid and expired payment requests from the drawer in one obvious step.
Design direction (20 Oct)
Payment requests shouldn't live only in Subscriptions → Payments. They also get their own Payment Requests screen:
Incoming: each request with the payer, note and amount, and Dismiss and Pay buttons.
Outgoing: each request with the payee, note, amount and its status (for example pending).
A Request Payment button at the bottom.
Subscriptions → Payments stays, with a badge showing the number of pending requests. The drawer entry and its label follow from this; the final wording is a design call.
Payment Requests screen (design mockup):
Subscriptions → Payments tab with the pending badge (design mockup):
Also: tell the user when a request fails or expires
Today a request turns Expired silently (seen on Android 3.0.1 with a Shop order request, which expired while the app showed nothing). When an incoming payment request fails or expires, show a toast saying so, ideally with a button under the text that opens Payment Requests. The early expiry itself is tracked in pubky/pubky-marketplace#358.
Where the standalone Payment Requests screen is entered from, per the Figma prototype (Bitkit Wallet, page "Bitkit - Handoff v62") and the code on master:
Design: Home bell (shown only while requests are pending) → Payment Requests sheet → See all → standalone Payment Requests screen (frame 48056:274346: incoming and outgoing requests plus Request Payment). Creating a request also ends on that screen. The drawer has no Payment Requests item; Subscriptions opens the Subscriptions overview.
Both apps today: the bell and the sheet match the design, but See all goes to Subscriptions → Payments, and no standalone screen exists. Android ContentView.kt routes See all to Routes.Subscriptions(showPayments = true); iOS PaymentRequestsView.swift to .subscriptions(showPayments: true).
The gap behind this issue: with no pending requests the bell is hidden, so drawer → Subscriptions → Payments is the only way in.
Open design questions:
Should the standalone screen be reachable with no pending requests (a drawer item, a Home action, or from Subscriptions)?
Should See all go to the standalone screen, with the Payments tab kept as a second view?
Which of the redrawn Payment Requests frames (48056:274346, 50515:118198, 50515:118415) is current? The 50515 frames have no prototype links into them yet.
The fail/expire toast part: #1643 shows "The payment request has expired." when a pending request expires on its own. Failed requests already get a toast. The Payment Requests screen and the toast's button that opens it wait on design sign-off.
Design update (21 Oct): Aldert confirmed the navigation to Payment Requests will be reconsidered and improved, since today the standalone screen has no permanent entry point (thread). The permanent entry waits on that design; the expiry toast part ships separately.
Activity
ovitrif commentedon Oct 20, 2026
Where the standalone Payment Requests screen is entered from, per the Figma prototype (Bitkit Wallet, page "Bitkit - Handoff v62") and the code on master:
ContentView.ktroutes See all toRoutes.Subscriptions(showPayments = true); iOSPaymentRequestsView.swiftto.subscriptions(showPayments: true).Open design questions:
ovitrif commentedon Oct 21, 2026
The fail/expire toast part: #1643 shows "The payment request has expired." when a pending request expires on its own. Failed requests already get a toast. The Payment Requests screen and the toast's button that opens it wait on design sign-off.
ovitrif commentedon Oct 21, 2026
Design update (21 Oct): Aldert confirmed the navigation to Payment Requests will be reconsidered and improved, since today the standalone screen has no permanent entry point (thread). The permanent entry waits on that design; the expiry toast part ships separately.