Skip to content

feat: add Request Payment UI to Payments page - #37

Merged
sirdeggen merged 22 commits into
bsv-blockchain:feature/request-paymentfrom
Quaakee:feat/request-payment
Apr 9, 2026
Merged

feat: add Request Payment UI to Payments page#37
sirdeggen merged 22 commits into
bsv-blockchain:feature/request-paymentfrom
Quaakee:feat/request-payment

Conversation

@Quaakee

@Quaakee Quaakee commented Apr 8, 2026

Copy link
Copy Markdown
Contributor

Summary

  • Add "Request Payment" tab with form for sending payment requests (recipient search, amount, description, expiry)
  • Add "Incoming Requests" tab showing request cards with editable amount, note, and Pay/Decline actions
  • Add outgoing request status tracker (Pending/Paid/Declined/Expired/Cancelled)
  • Add request settings: identity whitelist management + configurable min/max amount limits
  • Reorganize Payments page into 4 tabs: Send Payment, Request Payment, Incoming Requests, Pending Payments

Dependencies

New Files

  • src/lib/pages/Dashboard/Payments/RequestPaymentForm.tsx — request form + outgoing tracker
  • src/lib/pages/Dashboard/Payments/IncomingRequestList.tsx — request cards + settings panel

Modified Files

  • src/lib/pages/Dashboard/Payments/index.tsx — tab navigation and new component integration

Security

  • Default-deny: payment_requests box blocks all senders until explicitly whitelisted
  • Configurable min/max amount limits to prevent dust spam (defaults: 1,000 - 10,000,000 sats)
  • Limits stored in localStorage, applied client-side during request listing

Test plan

  • Build succeeds (npm run build:renderer)
  • All 4 tabs render correctly
  • Request Payment form validates inputs (amount > 0, description required, recipient valid)
  • Incoming Requests shows empty state when no requests
  • Settings panel: whitelist add/remove works
  • Settings panel: amount limits save to localStorage
  • Existing Send Payment and Pending Payments tabs function unchanged

🤖 Generated with Claude Code

Quaakee and others added 22 commits April 8, 2026 07:38
Temporarily using npm link to local clone of message-box-client
with payment request methods. Will switch to published version
once bsv-blockchain/message-box-client#38 is merged.
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
…request settings

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
- Add on/off toggle for whitelist with visual ON/OFF chip indicator
- Add identity search (useIdentitySearch) to whitelist management
- Show full whitelisted identity keys with delete button
- Direct key paste fallback when identity not found in search
- Change tab variant from scrollable to fullWidth so all labels visible
- Whitelist enabled state persisted in localStorage
The dependency was accidentally removed during npm link setup.
Restored with ^2.0.6 (current registry version). This PR requires
bsv-blockchain/message-box-client#38 to be merged and a new version
published before the build will pass.
Add changelog entry for Request Payment feature:
- Request/fulfill/decline payment requests
- Outgoing request tracker with live status
- Identity whitelist with toggle
- Min/max amount limits
- 4-tab Payments page layout
Fulfilled requests now show a Receive button in the outgoing tracker
to accept/internalize the payment directly, instead of requiring the
user to go to the Pending Payments tab. Displays the fulfiller's note
in a quote block and shows the paid amount prominently.
All localStorage keys for the request payment feature are now suffixed
with the active profile's identity key. Prevents cross-account data
overwrites when users switch between multiple identities in the same
wallet.

Affected keys: payReq_outgoing, payReq_whitelist, payReq_minAmount,
payReq_maxAmount, payReq_whitelistEnabled
…requests

Previously polling only started after 15 seconds and only checked for
pending requests. Now polls immediately when the component mounts with
actionable requests, and also polls for paid requests that still need
their incomingPayment reference fetched for the Receive button.
Previously the component loaded from a fallback key when activeProfile
was undefined on mount, then overwrote the identity-scoped key with
empty data when the profile resolved. Now storageKey is null until
the identity is available, and load/save effects are skipped until then.
…mpletes

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
…n mutation

Replace the useEffect-based save (which raced with the load effect) with
an updateOutgoing() helper that writes to localStorage synchronously
inside the setState updater. The load effect only reads; all mutations
go through updateOutgoing which persists immediately. This guarantees
the initial empty state never overwrites persisted data.
The logout() function calls localStorage.clear() which wiped all
payment request data (outgoing requests, whitelist, amount limits).
Now saves and restores all keys prefixed with payReq_ around the clear,
so request data persists across logout/login cycles.
- RequestPaymentForm: capture requestProof from requestPayment() return,
  store it in OutgoingRequest, pass it to cancelPaymentRequest()
- IncomingRequestList: remove amount override from fulfillPaymentRequest()
  (API no longer supports it), remove "Amount to Pay" text field and
  unused payAmounts state

Matches API changes in bsv-blockchain/message-box-client#38:
- fulfillPaymentRequest no longer accepts amount override
- cancelPaymentRequest now requires requestProof parameter
- requestPayment now returns { requestId, requestProof }

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
@sirdeggen
sirdeggen changed the base branch from master to feature/request-payment April 9, 2026 13:14
@sirdeggen
sirdeggen merged commit 67e6a0a into bsv-blockchain:feature/request-payment Apr 9, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants