fix: surface payment request details in sheet

[ovitrif]

Closes #1336
Twin: synonymdev/bitkit-ios#791

This PR shows who a Payment Request is from and what it is for on the Payment Request sheet, and keeps the request note in its details.

Description

• Adds a From / For row under the amount on the incoming Payment Request sheet, so the payer sees the requester and the request note without opening the details.
• Leaves the For column out when the request has no note; From keeps its half width.
• Shows the request note as an Invoice Note in the details and labels the requester as Contact, so the note stays visible once the details are open.
• Keeps the invoice's own description as Note in the details when it differs from the request note, so the payer still sees what the invoice says before confirming.
• Uses the design's spacing under the amount on the Payment Request sheet.
• Adds the request-summary.xml journey and its identifiers to the Payment Request journeys.

Out of Scope

• Other payment flows: LNURL pay, subscription payments and regular sends keep their current confirmation screens; the From / For row, Contact label and Invoice Note apply to one-off Payment Requests only.
• Payment Request sheet: the illustration's size and placement.
• Pubky checkout: an alternative view or QR for a payer who does not have Bitkit at hand.
• fix: surface payment request details in sheet bitkit-ios#791: the iOS change.

Design

Send (Pay Payment Request) on the Bitkit - Refactor v63 page, added on 2026-09-24. It supersedes the Payment Request frames on Bitkit - Handoff v62:

• Payment Request: From / For under the amount
• Confirm Details: Contact and Invoice Note in the details

Preview

Captured on an Android emulator receiving requests from an iOS simulator on regtest.

With note	Without note	Details

QA Notes

Journeys

• new request-summary.xml — the collapsed Payment Request sheet shows From and For, the details show the note as Invoice Note under a Contact recipient, and For is left out without a note

Manual Tests

• Open a request whose Lightning invoice description differs from the request note → the details show the invoice description as Note and the request note as Invoice Note — a Lightning endpoint with its own invoice description is not in Capabilities

Automated Checks

• added AppViewModelSendFlowTest.kt — an opened request passes its note to the confirm sheet

[greptile-apps]

Confidence Score: 4/5

The PR should not merge until opening payment details preserves access to the request note.

Findings

1.  Request note disappears in details ▶
2.  Summary display lacks UI coverage ▶

Summary

This PR carries an incoming payment-request note into send state and adds a collapsed confirmation row for the requester and optional note.

• Adds From/For cells, previews, a string, and journey instructions.
• Adds a ViewModel test for note propagation.

Diagram

%%{init: {'theme': 'neutral'}}%%
flowchart TD
  A[Incoming payment request] --> B[SendUiState: contact and request note]
  B --> C{Confirmation details open?}
  C -- No --> D[From / optional For summary]
  C -- Yes --> E[Expanded payment details]
  E --> F[Request note not shown on-chain]

Loading

_{Reviews (1) · Last reviewed commit: "Merge remote-tracking branch 'origin/mas..."}

[github-actions]

Regtest APK

Built from 4b5e73f (run).

Download bitkit-dev-debug universal APK (expires in 30 days).

[ovitrif]

Pushed 2f74260: keeps the decoded invoice description in the Payment Request details when it differs from the request note, answering @pwltr's review comment. The Note row is hidden only when the two match, so Bitkit-to-Bitkit requests (empty invoice description) look unchanged.

Checks: compile and detekt clean on the changed file.

[piotr-iohk]

QA approve — Payment Request From/For sheet

Pinned: 2f74260. Twin: synonymdev/bitkit-ios#791 @ c4bdb4d5cc12.

Code: no actionable findings on the From/For row, details Invoice Note / Contact labeling, or empty-note layout.

Device: incoming request confirm opened on Android (Payer) after Requester sent from iOS; two on-chain Paykit payments completed (logs: Opened → Decoded → Consumed → sendOnChain for ~20k then 21k). First automated wait hit empty encrypted-link poll (delivery lag); after the request arrived, open → confirm → pay worked.

LGTM.

[jvsena42]

No HIGH/MEDIUM findings.

Checked and clean:

• From/For vs the request paid: paymentRequestNote, isPaymentRequest, incomingPaymentRequestId and contactPaymentProfile are only written by resetSendState, which handleScan calls under scanMutex from the same activeContactPaymentContext right after prepareContactPaymentContextForScan. The note and request id in the snapshot always belong to the decoded invoice. Pay-time guards still hold: onConfirmPay rejects a payment-request snapshot without an active context, and validateIncomingPaymentRequest rejects amount/invoice mismatch and non-pending requests.
• Second request while the confirm is open: blocked by isPaymentRequestPresentationBlocked; opening one manually hides the Send sheet and re-runs handleScan.
• Back/cancel from Confirm: header Back and amount tap pop to Amount with the same request; sheet close runs hideSheet → clearActiveContactPaymentContext. The stale SendUiState fields that survive are reset on every re-entry (TabBar Send resetSendState, any scan/deeplink via handleScan), and onConfirmPay would reject a stale snapshot anyway. The note adds no new clearing obligation beyond the existing contactPaymentProfile.
• Requester text: From and For are single-line with ellipsis; the note is plain text and never reaches URLs, network calls or logs. The unbounded Invoice Note stays readable because ContentRunning scrolls; iOS does not scroll there, flagged on synonymdev/bitkit-ios#791.
• Subscriptions and LNURL keep their confirm; the Note row hides only when the trimmed invoice description equals the note.
• Gating: every entry point sits behind PaykitFeatureFlags.isUiEnabled (default off).
• Figma: matches the Payment Request and Confirm Details frames on Bitkit - Refactor v63.

[ovitrif]

Pushed c00e726: the changelog entry now also says the request note stays in the payment details, and master is merged in.

The Design section now names the spec's page: Send (Pay Payment Request) on Bitkit - Refactor v63, with the Payment Request and Confirm Details frames. It supersedes the Handoff v62 Payment Request frames, which the earlier description pointed to.

Checks: compile, detekt and AppViewModelSendFlowTest.kt pass.

@piotr-iohk, re-requesting your review because the approval was on 2f74260; the code under review is unchanged.

[ovitrif]

Pushed 4b5e73f: restores the original one-line changelog entry; the added detail about the payment details did not belong in release notes.

[jvsena42]

tAck