feat: add private payment requests

[ben-kaufman]

This PR adds private Paykit Payment Requests to Bitkit.

Description

1. Automatically opens incoming requests in the existing Send confirmation flow with the requesting contact, exact amount, and a Payment Request title.
2. Keeps dismissed requests actionable through a bell, preview sheet, and full request history, with manual reopen and explicit rejection.
3. Adds outgoing request creation from Receive for linked, saved contacts, including amount, note, expiry, queued delivery state, and sent history.
4. Drops expired or remotely unavailable requests, keeps presentation state scoped to the active Pubky identity, and protects account changes, sheet transitions, and overlapping actions.
5. Requires strict private resolution for requests: a consumed Private Payment List is never reused, another endpoint from that list is not attempted, and public details are never used as fallback while waiting for a newer list.
6. Updates Paykit to 0.1.0-rc44 and adds local E2E homeserver configuration plus safe cold-start restoration for externally managed Pubky sessions.

The request payload itself remains SDK-backed and durable; Bitkit persists only encrypted, identity-scoped presentation suppression, not a duplicate request queue. Payment proofs and receipts remain out of scope.

Dependencies:

• Paykit 0.1.0-rc44
• Local Locks interoperability was verified with paykit-server#2 at 41cda2567226a690a012770017d5e7c1d49e2a2b.
• Companion iOS PR: synonymdev/bitkit-ios#676

Preview

N/A — proof recordings were completed locally and are intentionally not attached to the PR.

QA Notes

Manual Tests

• 1. Clean wallet → create Pubky profile → enable Paykit and Contact Payments → add the peer as a contact: private-capable request action appears once the Noise link is established.
• 2. Peer creates a private request → Home: Payment Request opens automatically with the correct contact and amount.
• 3. Payment Request → dismiss without rejecting → bell → request preview → Pay: the request remains queued, reopens, and pays successfully.
• 4. Peer creates a second request after payment → Pay: a newer Private Payment List is used; the consumed list is not reused and no public fallback occurs.
• 5. Receive → Send Payment Request → enter amount, note, and expiry → select linked contact → Send: request is queued once and appears in sent history.
• 6. Incoming request → Reject: only that request becomes terminal and the private payment list is not consumed.
• 7. Incoming request → dismiss → relaunch: request remains discoverable without automatically reopening again; expired requests disappear live.
• 8. Cross-platform E2E: iOS creates two requests that Android receives and pays, and Android creates two requests that iOS receives and pays, on clean regtest state.

Automated Checks

• PaykitPaymentRequestRepoTest.kt: covers mapping, eligibility, proposal delivery, rejection, expiry, identity-scoped presentation state, and action serialization.
• PaykitSdkServiceTest.kt: covers exact identity enforcement and safe deferred session restoration.
• AppViewModelSendFlowTest.kt: covers automatic/manual presentation, sheet transitions, identity changes, newer-list retry, strict private resolution, and payment lifecycle races.
• PaymentRequestExpirationTest.kt: covers expiry selection and retained draft state.
• SheetHostTest.kt: covers locked sheet dismissal and scrim input isolation during durable proposal creation.
• Local verification passed: app compile, Android-test compile, complete dev unit suite, detekt, and git diff --check.
• Both final cross-platform proof videos decoded end to end without errors.

[piotr-iohk]

Flagging while QA’ing with the staging public-pay pubkys — not a prod issue (Paykit UI is still hidden).

Enabling payments with contacts fail-closes with Unknown error if a saved contact’s receiver marker doesn’t parse (here: missing noise_public_key). I hit it on:

• pubky1jy146y751hkgqk9p69ds5cqf461aj5x7c8ptbca5rw6m9asotso
• pubkynekaxdyt5ktoqyufd7cgug6qppa7999hm46wfqdzm6jqnr8tj16o

In principle the same thing could happen with any broken / outdated profile marker, not only these fixtures. Recording attached. Same surface on iOS after #676 (toast there is Private Paykit is not available).

Steps:

1. Enable Paykit UI. Create a profile. Leave payments with contacts off.
2. Add either (or both) staging pubkys above as contacts. They do not need to be live.
3. Enable payments with contacts.
4. Toast is Unknown error and the toggle stays off.

Screen.Recording.2026-08-26.at.10.12.34.mov

logs.zip

[piotr-iohk]

Flagging from QA: paying a payment request that’s larger than the wallet balance.

Same setup, two directions, both recordings attached:

• iOS → Android (this PR): incoming sheet, Pay → toast Insufficient Spending Balance (e.g. ₿ 78,244 more needed to pay this Lightning invoice) and a red-bordered card. Dismiss then fails with Payment request operation is already in progress. Toast / error repeats; request stays on the sheet and is hard to dismiss.

Screen.Recording.2026-08-26.at.14.06.24.mov

• Android → iOS (ldk-node Error #676, already merged):Pay → Please try again. Coin selection failed. Dismiss is fine; the copy is just the wrong error.

Screen.Recording.2026-08-26.at.14.18.16.mov

Steps:

1. Two live wallets with payments-with-contacts on. Put ~88k on the payer (split savings + spending is fine).
2. Other wallet requests more than that total (100k Android-as-payer, 90k iOS-as-payer).
3. On the incoming request, tap Pay, then try Dismiss.

Expected: don’t enter confirm if the amount is above spendable. On Android, Dismiss should still work after a failed Pay (no already in progress loop).

[ben-kaufman]

Addressed both QA findings in signed commit 5d39cd96a:

• A malformed remote receiver marker is still rejected and cannot be used, but its per-contact inspection error no longer aborts global private endpoint publication for valid contacts. The regression test now covers the immediate-publication path used when enabling Contact Payments.
• An unaffordable request now releases its manual presentation state after showing the existing insufficient-balance message. It remains pending and dismissible, is not accepted or rejected, and does not consume a Private Payment List. The regression test verifies Dismiss remains actionable and no retry starts from the old context.

The matching iOS fixes are isolated in synonymdev/bitkit-ios#684: malformed remote markers no longer block other contacts, and incoming request amounts are used during initial LN/on-chain balance validation so the standard insufficient Spending/Savings error appears before coin selection.

Local verification: 193 focused Android tests passed; detekt completed successfully with only unrelated pre-existing findings.

[piotr-iohk]

Retested after 5d39cd9.

Enable — still fails. ❌

Toggle Enable payments with contacts → Unknown error, toggle does not stay on. Same staging contact as before (pubky1jy146y751hkgqk9p69ds5cqf461aj5x7c8ptbca5rw6m9asotso). Recording + logs attached.

This is not the noise_public_key inspect-fail anymore. Logs are PrivateUnavailable. In this run I turned the toggle off first; disable cleanup already failed with that error, then re-enable with cleanup still pending fail-closes again. Settings still maps it to Unknown error.

Same user-facing miss on iOS #684 (toast there is Private Paykit is not available).

Steps:

1. Paykit UI on. Profile exists. Staging pubky above saved as a contact (need not be live).
2. Payments with contacts off (or turn it off first).
3. Enable payments with contacts.
4. Toast is Unknown error; toggle stays off.

Screen.Recording.2026-08-27.at.10.24.05.-.android.mov

logs-android.zip

Over-balance — looks good on Android. ✅

Incoming request larger than the wallet: one Insufficient Savings / Spending toast, request stays pending and dismissible. No already in progress loop.

iOS #684 still repeats that toast (see that PR).

[jvsena42]

Code review

Reviewed git diff master...HEAD at 56ce990 (merge-base 6ae3cb7) — 34 files, ~3.8k added lines. 10 findings inline, roughly in severity order: the ReceiveSheet start-destination change and the dropped firstError in PrivatePaykitRepo look like the two most likely to bite in practice.

Checked and looked correct: the generation/identity guards in PaykitPaymentRequestRepo (activate/refresh/synchronizeLocked/isCurrentState), creationMutex.tryLock with finally unlock in propose, expiration rescheduling, the hideSheet re-entrancy guard, SheetHost's confirmValueChange + rememberUpdatedState pairing, the scrim's pointer-consuming modifier, the stopped/recursion loop in presentNextIncomingPaykitPaymentRequest, and the sats/BTC BigDecimal conversions.

One judgement call I did not flag as a defect: the string-literal match in canDeferStaleSession is brittle against SDK message changes.

[ben-kaufman]

Addressed the remaining enable/disable QA path in signed, rebased commit 531578e.

The private setting now reflects the user choice independently of transient transport cleanup or immediate Noise availability:

• Disable commits private sharing off and records failed remote cleanup as durable deferred work instead of restoring the toggle.
• Re-enable supersedes pending removal and prepares saved contacts opportunistically; it no longer requires a live peer or immediate private endpoint publication to keep the toggle enabled.
• Recovery persists the cleanup marker before remote removal and local pruning, so a failure between those stages remains retryable. The cached-publication fallback still recovers older states where the marker was not stored.
• Malformed remote markers remain unusable, and there is still no private-to-public payment fallback.

Regression coverage includes deferred disable cleanup, re-enable with pending cleanup, recovery without a marker, failure after remote cleanup but before local pruning, and total versus partial marker-selection failure. The over-balance behavior that passed the retest is unchanged.

Post-rebase verification: full testDevDebugUnitTest, detekt, and compileDevDebugAndroidTestKotlin pass. The stack is rebased onto current master and all 13 PR commits are signed.

[piotr-iohk]

Retested. LGTM.

[jvsena42]

tAck

Reviewed the code manually and tested with journeys

[ben-kaufman]

This PR adds private Paykit Payment Requests to Bitkit.

Description

1. Automatically opens incoming requests in the existing Send confirmation flow with the requesting contact, exact amount, and a Payment Request title.
2. Keeps dismissed requests actionable through a bell, preview sheet, and full request history, with manual reopen and explicit rejection.
3. Adds outgoing request creation from Receive for linked, saved contacts, including amount, note, expiry, queued delivery state, and sent history.
4. Drops expired or remotely unavailable requests, keeps presentation state scoped to the active Pubky identity, and protects account changes, sheet transitions, and overlapping actions.
5. Requires strict private resolution for requests: a consumed Private Payment List is never reused, another endpoint from that list is not attempted, and public details are never used as fallback while waiting for a newer list.
6. Updates Paykit to 0.1.0-rc44 and adds local E2E homeserver configuration plus safe cold-start restoration for externally managed Pubky sessions.

The request payload itself remains SDK-backed and durable; Bitkit persists only encrypted, identity-scoped presentation suppression, not a duplicate request queue. Payment proofs and receipts remain out of scope.

Dependencies:

• Paykit 0.1.0-rc44
• Local Locks interoperability was verified with paykit-server#2 at 41cda2567226a690a012770017d5e7c1d49e2a2b.
• Companion iOS PR: synonymdev/bitkit-ios#676

Preview

N/A — proof recordings were completed locally and are intentionally not attached to the PR.

QA Notes

Manual Tests

• 1. Clean wallet → create Pubky profile → enable Paykit and Contact Payments → add the peer as a contact: private-capable request action appears once the Noise link is established.
• 2. Peer creates a private request → Home: Payment Request opens automatically with the correct contact and amount.
• 3. Payment Request → dismiss without rejecting → bell → request preview → Pay: the request remains queued, reopens, and pays successfully.
• 4. Peer creates a second request after payment → Pay: a newer Private Payment List is used; the consumed list is not reused and no public fallback occurs.
• 5. Receive → Send Payment Request → enter amount, note, and expiry → select linked contact → Send: request is queued once and appears in sent history.
• 6. Incoming request → Reject: only that request becomes terminal and the private payment list is not consumed.
• 7. Incoming request → dismiss → relaunch: request remains discoverable without automatically reopening again; expired requests disappear live.
• 8. Cross-platform E2E: iOS creates two requests that Android receives and pays, and Android creates two requests that iOS receives and pays, on clean regtest state.

Automated Checks

• PaykitPaymentRequestRepoTest.kt: covers mapping, eligibility, proposal delivery, rejection, expiry, identity-scoped presentation state, and action serialization.
• PaykitSdkServiceTest.kt: covers exact identity enforcement and safe deferred session restoration.
• AppViewModelSendFlowTest.kt: covers automatic/manual presentation, sheet transitions, identity changes, newer-list retry, strict private resolution, and payment lifecycle races.
• PaymentRequestExpirationTest.kt: covers expiry selection and retained draft state.
• SheetHostTest.kt: covers locked sheet dismissal and scrim input isolation during durable proposal creation.
• Local verification passed: app compile, Android-test compile, complete dev unit suite, detekt, and git diff --check.
• Both final cross-platform proof videos decoded end to end without errors.

[piotr-iohk]

Flagging while QA’ing with the staging public-pay pubkys — not a prod issue (Paykit UI is still hidden).

Enabling payments with contacts fail-closes with Unknown error if a saved contact’s receiver marker doesn’t parse (here: missing noise_public_key). I hit it on:

• pubky1jy146y751hkgqk9p69ds5cqf461aj5x7c8ptbca5rw6m9asotso
• pubkynekaxdyt5ktoqyufd7cgug6qppa7999hm46wfqdzm6jqnr8tj16o

In principle the same thing could happen with any broken / outdated profile marker, not only these fixtures. Recording attached. Same surface on iOS after #676 (toast there is Private Paykit is not available).

Steps:

1. Enable Paykit UI. Create a profile. Leave payments with contacts off.
2. Add either (or both) staging pubkys above as contacts. They do not need to be live.
3. Enable payments with contacts.
4. Toast is Unknown error and the toggle stays off.

Screen.Recording.2026-08-26.at.10.12.34.mov

logs.zip

[piotr-iohk]

Flagging from QA: paying a payment request that’s larger than the wallet balance.

Same setup, two directions, both recordings attached:

• iOS → Android (this PR): incoming sheet, Pay → toast Insufficient Spending Balance (e.g. ₿ 78,244 more needed to pay this Lightning invoice) and a red-bordered card. Dismiss then fails with Payment request operation is already in progress. Toast / error repeats; request stays on the sheet and is hard to dismiss.

Screen.Recording.2026-08-26.at.14.06.24.mov

• Android → iOS (ldk-node Error #676, already merged):Pay → Please try again. Coin selection failed. Dismiss is fine; the copy is just the wrong error.

Screen.Recording.2026-08-26.at.14.18.16.mov

Steps:

1. Two live wallets with payments-with-contacts on. Put ~88k on the payer (split savings + spending is fine).
2. Other wallet requests more than that total (100k Android-as-payer, 90k iOS-as-payer).
3. On the incoming request, tap Pay, then try Dismiss.

Expected: don’t enter confirm if the amount is above spendable. On Android, Dismiss should still work after a failed Pay (no already in progress loop).

[ben-kaufman]

Addressed both QA findings in signed commit 5d39cd96a:

• A malformed remote receiver marker is still rejected and cannot be used, but its per-contact inspection error no longer aborts global private endpoint publication for valid contacts. The regression test now covers the immediate-publication path used when enabling Contact Payments.
• An unaffordable request now releases its manual presentation state after showing the existing insufficient-balance message. It remains pending and dismissible, is not accepted or rejected, and does not consume a Private Payment List. The regression test verifies Dismiss remains actionable and no retry starts from the old context.

The matching iOS fixes are isolated in synonymdev/bitkit-ios#684: malformed remote markers no longer block other contacts, and incoming request amounts are used during initial LN/on-chain balance validation so the standard insufficient Spending/Savings error appears before coin selection.

Local verification: 193 focused Android tests passed; detekt completed successfully with only unrelated pre-existing findings.

[piotr-iohk]

Retested after 5d39cd9.

Enable — still fails. ❌

Toggle Enable payments with contacts → Unknown error, toggle does not stay on. Same staging contact as before (pubky1jy146y751hkgqk9p69ds5cqf461aj5x7c8ptbca5rw6m9asotso). Recording + logs attached.

This is not the noise_public_key inspect-fail anymore. Logs are PrivateUnavailable. In this run I turned the toggle off first; disable cleanup already failed with that error, then re-enable with cleanup still pending fail-closes again. Settings still maps it to Unknown error.

Same user-facing miss on iOS #684 (toast there is Private Paykit is not available).

Steps:

1. Paykit UI on. Profile exists. Staging pubky above saved as a contact (need not be live).
2. Payments with contacts off (or turn it off first).
3. Enable payments with contacts.
4. Toast is Unknown error; toggle stays off.

Screen.Recording.2026-08-27.at.10.24.05.-.android.mov

logs-android.zip

Over-balance — looks good on Android. ✅

Incoming request larger than the wallet: one Insufficient Savings / Spending toast, request stays pending and dismissible. No already in progress loop.

iOS #684 still repeats that toast (see that PR).

[jvsena42]

Code review

Reviewed git diff master...HEAD at 56ce990 (merge-base 6ae3cb7) — 34 files, ~3.8k added lines. 10 findings inline, roughly in severity order: the ReceiveSheet start-destination change and the dropped firstError in PrivatePaykitRepo look like the two most likely to bite in practice.

Checked and looked correct: the generation/identity guards in PaykitPaymentRequestRepo (activate/refresh/synchronizeLocked/isCurrentState), creationMutex.tryLock with finally unlock in propose, expiration rescheduling, the hideSheet re-entrancy guard, SheetHost's confirmValueChange + rememberUpdatedState pairing, the scrim's pointer-consuming modifier, the stopped/recursion loop in presentNextIncomingPaykitPaymentRequest, and the sats/BTC BigDecimal conversions.

One judgement call I did not flag as a defect: the string-literal match in canDeferStaleSession is brittle against SDK message changes.

[ben-kaufman]

Addressed the remaining enable/disable QA path in signed, rebased commit 531578e.

The private setting now reflects the user choice independently of transient transport cleanup or immediate Noise availability:

• Disable commits private sharing off and records failed remote cleanup as durable deferred work instead of restoring the toggle.
• Re-enable supersedes pending removal and prepares saved contacts opportunistically; it no longer requires a live peer or immediate private endpoint publication to keep the toggle enabled.
• Recovery persists the cleanup marker before remote removal and local pruning, so a failure between those stages remains retryable. The cached-publication fallback still recovers older states where the marker was not stored.
• Malformed remote markers remain unusable, and there is still no private-to-public payment fallback.

Regression coverage includes deferred disable cleanup, re-enable with pending cleanup, recovery without a marker, failure after remote cleanup but before local pruning, and total versus partial marker-selection failure. The over-balance behavior that passed the retest is unchanged.

Post-rebase verification: full testDevDebugUnitTest, detekt, and compileDevDebugAndroidTestKotlin pass. The stack is rebased onto current master and all 13 PR commits are signed.

[piotr-iohk]

Retested. LGTM.

[jvsena42]

tAck

Reviewed the code manually and tested with journeys

[ben-kaufman]

This PR adds private Paykit Payment Requests to Bitkit.

Description

1. Automatically opens incoming requests in the existing Send confirmation flow with the requesting contact, exact amount, and a Payment Request title.
2. Keeps dismissed requests actionable through a bell, preview sheet, and full request history, with manual reopen and explicit rejection.
3. Adds outgoing request creation from Receive for linked, saved contacts, including amount, note, expiry, queued delivery state, and sent history.
4. Drops expired or remotely unavailable requests, keeps presentation state scoped to the active Pubky identity, and protects account changes, sheet transitions, and overlapping actions.
5. Requires strict private resolution for requests: a consumed Private Payment List is never reused, another endpoint from that list is not attempted, and public details are never used as fallback while waiting for a newer list.
6. Updates Paykit to 0.1.0-rc44 and adds local E2E homeserver configuration plus safe cold-start restoration for externally managed Pubky sessions.

The request payload itself remains SDK-backed and durable; Bitkit persists only encrypted, identity-scoped presentation suppression, not a duplicate request queue. Payment proofs and receipts remain out of scope.

Dependencies:

• Paykit 0.1.0-rc44
• Local Locks interoperability was verified with paykit-server#2 at 41cda2567226a690a012770017d5e7c1d49e2a2b.
• Companion iOS PR: synonymdev/bitkit-ios#676

Preview

N/A — proof recordings were completed locally and are intentionally not attached to the PR.

QA Notes

Manual Tests

• 1. Clean wallet → create Pubky profile → enable Paykit and Contact Payments → add the peer as a contact: private-capable request action appears once the Noise link is established.
• 2. Peer creates a private request → Home: Payment Request opens automatically with the correct contact and amount.
• 3. Payment Request → dismiss without rejecting → bell → request preview → Pay: the request remains queued, reopens, and pays successfully.
• 4. Peer creates a second request after payment → Pay: a newer Private Payment List is used; the consumed list is not reused and no public fallback occurs.
• 5. Receive → Send Payment Request → enter amount, note, and expiry → select linked contact → Send: request is queued once and appears in sent history.
• 6. Incoming request → Reject: only that request becomes terminal and the private payment list is not consumed.
• 7. Incoming request → dismiss → relaunch: request remains discoverable without automatically reopening again; expired requests disappear live.
• 8. Cross-platform E2E: iOS creates two requests that Android receives and pays, and Android creates two requests that iOS receives and pays, on clean regtest state.

Automated Checks

• PaykitPaymentRequestRepoTest.kt: covers mapping, eligibility, proposal delivery, rejection, expiry, identity-scoped presentation state, and action serialization.
• PaykitSdkServiceTest.kt: covers exact identity enforcement and safe deferred session restoration.
• AppViewModelSendFlowTest.kt: covers automatic/manual presentation, sheet transitions, identity changes, newer-list retry, strict private resolution, and payment lifecycle races.
• PaymentRequestExpirationTest.kt: covers expiry selection and retained draft state.
• SheetHostTest.kt: covers locked sheet dismissal and scrim input isolation during durable proposal creation.
• Local verification passed: app compile, Android-test compile, complete dev unit suite, detekt, and git diff --check.
• Both final cross-platform proof videos decoded end to end without errors.

[piotr-iohk]

Flagging while QA’ing with the staging public-pay pubkys — not a prod issue (Paykit UI is still hidden).

Enabling payments with contacts fail-closes with Unknown error if a saved contact’s receiver marker doesn’t parse (here: missing noise_public_key). I hit it on:

• pubky1jy146y751hkgqk9p69ds5cqf461aj5x7c8ptbca5rw6m9asotso
• pubkynekaxdyt5ktoqyufd7cgug6qppa7999hm46wfqdzm6jqnr8tj16o

In principle the same thing could happen with any broken / outdated profile marker, not only these fixtures. Recording attached. Same surface on iOS after #676 (toast there is Private Paykit is not available).

Steps:

1. Enable Paykit UI. Create a profile. Leave payments with contacts off.
2. Add either (or both) staging pubkys above as contacts. They do not need to be live.
3. Enable payments with contacts.
4. Toast is Unknown error and the toggle stays off.

Screen.Recording.2026-08-26.at.10.12.34.mov

logs.zip

[piotr-iohk]

Flagging from QA: paying a payment request that’s larger than the wallet balance.

Same setup, two directions, both recordings attached:

• iOS → Android (this PR): incoming sheet, Pay → toast Insufficient Spending Balance (e.g. ₿ 78,244 more needed to pay this Lightning invoice) and a red-bordered card. Dismiss then fails with Payment request operation is already in progress. Toast / error repeats; request stays on the sheet and is hard to dismiss.

Screen.Recording.2026-08-26.at.14.06.24.mov

• Android → iOS (ldk-node Error #676, already merged):Pay → Please try again. Coin selection failed. Dismiss is fine; the copy is just the wrong error.

Screen.Recording.2026-08-26.at.14.18.16.mov

Steps:

1. Two live wallets with payments-with-contacts on. Put ~88k on the payer (split savings + spending is fine).
2. Other wallet requests more than that total (100k Android-as-payer, 90k iOS-as-payer).
3. On the incoming request, tap Pay, then try Dismiss.

Expected: don’t enter confirm if the amount is above spendable. On Android, Dismiss should still work after a failed Pay (no already in progress loop).

[ben-kaufman]

Addressed both QA findings in signed commit 5d39cd96a:

• A malformed remote receiver marker is still rejected and cannot be used, but its per-contact inspection error no longer aborts global private endpoint publication for valid contacts. The regression test now covers the immediate-publication path used when enabling Contact Payments.
• An unaffordable request now releases its manual presentation state after showing the existing insufficient-balance message. It remains pending and dismissible, is not accepted or rejected, and does not consume a Private Payment List. The regression test verifies Dismiss remains actionable and no retry starts from the old context.

The matching iOS fixes are isolated in synonymdev/bitkit-ios#684: malformed remote markers no longer block other contacts, and incoming request amounts are used during initial LN/on-chain balance validation so the standard insufficient Spending/Savings error appears before coin selection.

Local verification: 193 focused Android tests passed; detekt completed successfully with only unrelated pre-existing findings.

[piotr-iohk]

Retested after 5d39cd9.

Enable — still fails. ❌

Toggle Enable payments with contacts → Unknown error, toggle does not stay on. Same staging contact as before (pubky1jy146y751hkgqk9p69ds5cqf461aj5x7c8ptbca5rw6m9asotso). Recording + logs attached.

This is not the noise_public_key inspect-fail anymore. Logs are PrivateUnavailable. In this run I turned the toggle off first; disable cleanup already failed with that error, then re-enable with cleanup still pending fail-closes again. Settings still maps it to Unknown error.

Same user-facing miss on iOS #684 (toast there is Private Paykit is not available).

Steps:

1. Paykit UI on. Profile exists. Staging pubky above saved as a contact (need not be live).
2. Payments with contacts off (or turn it off first).
3. Enable payments with contacts.
4. Toast is Unknown error; toggle stays off.

Screen.Recording.2026-08-27.at.10.24.05.-.android.mov

logs-android.zip

Over-balance — looks good on Android. ✅

Incoming request larger than the wallet: one Insufficient Savings / Spending toast, request stays pending and dismissible. No already in progress loop.

iOS #684 still repeats that toast (see that PR).

[jvsena42]

Code review

Reviewed git diff master...HEAD at 56ce990 (merge-base 6ae3cb7) — 34 files, ~3.8k added lines. 10 findings inline, roughly in severity order: the ReceiveSheet start-destination change and the dropped firstError in PrivatePaykitRepo look like the two most likely to bite in practice.

Checked and looked correct: the generation/identity guards in PaykitPaymentRequestRepo (activate/refresh/synchronizeLocked/isCurrentState), creationMutex.tryLock with finally unlock in propose, expiration rescheduling, the hideSheet re-entrancy guard, SheetHost's confirmValueChange + rememberUpdatedState pairing, the scrim's pointer-consuming modifier, the stopped/recursion loop in presentNextIncomingPaykitPaymentRequest, and the sats/BTC BigDecimal conversions.

One judgement call I did not flag as a defect: the string-literal match in canDeferStaleSession is brittle against SDK message changes.

[ben-kaufman]

Addressed the remaining enable/disable QA path in signed, rebased commit 531578e.

The private setting now reflects the user choice independently of transient transport cleanup or immediate Noise availability:

• Disable commits private sharing off and records failed remote cleanup as durable deferred work instead of restoring the toggle.
• Re-enable supersedes pending removal and prepares saved contacts opportunistically; it no longer requires a live peer or immediate private endpoint publication to keep the toggle enabled.
• Recovery persists the cleanup marker before remote removal and local pruning, so a failure between those stages remains retryable. The cached-publication fallback still recovers older states where the marker was not stored.
• Malformed remote markers remain unusable, and there is still no private-to-public payment fallback.

Regression coverage includes deferred disable cleanup, re-enable with pending cleanup, recovery without a marker, failure after remote cleanup but before local pruning, and total versus partial marker-selection failure. The over-balance behavior that passed the retest is unchanged.

Post-rebase verification: full testDevDebugUnitTest, detekt, and compileDevDebugAndroidTestKotlin pass. The stack is rebased onto current master and all 13 PR commits are signed.

[piotr-iohk]

Retested. LGTM.

[jvsena42]

tAck

Reviewed the code manually and tested with journeys

[ben-kaufman]

This PR adds private Paykit Payment Requests to Bitkit.

Description

1. Automatically opens incoming requests in the existing Send confirmation flow with the requesting contact, exact amount, and a Payment Request title.
2. Keeps dismissed requests actionable through a bell, preview sheet, and full request history, with manual reopen and explicit rejection.
3. Adds outgoing request creation from Receive for linked, saved contacts, including amount, note, expiry, queued delivery state, and sent history.
4. Drops expired or remotely unavailable requests, keeps presentation state scoped to the active Pubky identity, and protects account changes, sheet transitions, and overlapping actions.
5. Requires strict private resolution for requests: a consumed Private Payment List is never reused, another endpoint from that list is not attempted, and public details are never used as fallback while waiting for a newer list.
6. Updates Paykit to 0.1.0-rc44 and adds local E2E homeserver configuration plus safe cold-start restoration for externally managed Pubky sessions.

The request payload itself remains SDK-backed and durable; Bitkit persists only encrypted, identity-scoped presentation suppression, not a duplicate request queue. Payment proofs and receipts remain out of scope.

Dependencies:

• Paykit 0.1.0-rc44
• Local Locks interoperability was verified with paykit-server#2 at 41cda2567226a690a012770017d5e7c1d49e2a2b.
• Companion iOS PR: synonymdev/bitkit-ios#676

Preview

N/A — proof recordings were completed locally and are intentionally not attached to the PR.

QA Notes

Manual Tests

• 1. Clean wallet → create Pubky profile → enable Paykit and Contact Payments → add the peer as a contact: private-capable request action appears once the Noise link is established.
• 2. Peer creates a private request → Home: Payment Request opens automatically with the correct contact and amount.
• 3. Payment Request → dismiss without rejecting → bell → request preview → Pay: the request remains queued, reopens, and pays successfully.
• 4. Peer creates a second request after payment → Pay: a newer Private Payment List is used; the consumed list is not reused and no public fallback occurs.
• 5. Receive → Send Payment Request → enter amount, note, and expiry → select linked contact → Send: request is queued once and appears in sent history.
• 6. Incoming request → Reject: only that request becomes terminal and the private payment list is not consumed.
• 7. Incoming request → dismiss → relaunch: request remains discoverable without automatically reopening again; expired requests disappear live.
• 8. Cross-platform E2E: iOS creates two requests that Android receives and pays, and Android creates two requests that iOS receives and pays, on clean regtest state.

Automated Checks

• PaykitPaymentRequestRepoTest.kt: covers mapping, eligibility, proposal delivery, rejection, expiry, identity-scoped presentation state, and action serialization.
• PaykitSdkServiceTest.kt: covers exact identity enforcement and safe deferred session restoration.
• AppViewModelSendFlowTest.kt: covers automatic/manual presentation, sheet transitions, identity changes, newer-list retry, strict private resolution, and payment lifecycle races.
• PaymentRequestExpirationTest.kt: covers expiry selection and retained draft state.
• SheetHostTest.kt: covers locked sheet dismissal and scrim input isolation during durable proposal creation.
• Local verification passed: app compile, Android-test compile, complete dev unit suite, detekt, and git diff --check.
• Both final cross-platform proof videos decoded end to end without errors.

[piotr-iohk]

Flagging while QA’ing with the staging public-pay pubkys — not a prod issue (Paykit UI is still hidden).

Enabling payments with contacts fail-closes with Unknown error if a saved contact’s receiver marker doesn’t parse (here: missing noise_public_key). I hit it on:

• pubky1jy146y751hkgqk9p69ds5cqf461aj5x7c8ptbca5rw6m9asotso
• pubkynekaxdyt5ktoqyufd7cgug6qppa7999hm46wfqdzm6jqnr8tj16o

In principle the same thing could happen with any broken / outdated profile marker, not only these fixtures. Recording attached. Same surface on iOS after #676 (toast there is Private Paykit is not available).

Steps:

1. Enable Paykit UI. Create a profile. Leave payments with contacts off.
2. Add either (or both) staging pubkys above as contacts. They do not need to be live.
3. Enable payments with contacts.
4. Toast is Unknown error and the toggle stays off.

Screen.Recording.2026-08-26.at.10.12.34.mov

logs.zip

[piotr-iohk]

Flagging from QA: paying a payment request that’s larger than the wallet balance.

Same setup, two directions, both recordings attached:

• iOS → Android (this PR): incoming sheet, Pay → toast Insufficient Spending Balance (e.g. ₿ 78,244 more needed to pay this Lightning invoice) and a red-bordered card. Dismiss then fails with Payment request operation is already in progress. Toast / error repeats; request stays on the sheet and is hard to dismiss.

Screen.Recording.2026-08-26.at.14.06.24.mov

• Android → iOS (ldk-node Error #676, already merged):Pay → Please try again. Coin selection failed. Dismiss is fine; the copy is just the wrong error.

Screen.Recording.2026-08-26.at.14.18.16.mov

Steps:

1. Two live wallets with payments-with-contacts on. Put ~88k on the payer (split savings + spending is fine).
2. Other wallet requests more than that total (100k Android-as-payer, 90k iOS-as-payer).
3. On the incoming request, tap Pay, then try Dismiss.

Expected: don’t enter confirm if the amount is above spendable. On Android, Dismiss should still work after a failed Pay (no already in progress loop).

[ben-kaufman]

Addressed both QA findings in signed commit 5d39cd96a:

• A malformed remote receiver marker is still rejected and cannot be used, but its per-contact inspection error no longer aborts global private endpoint publication for valid contacts. The regression test now covers the immediate-publication path used when enabling Contact Payments.
• An unaffordable request now releases its manual presentation state after showing the existing insufficient-balance message. It remains pending and dismissible, is not accepted or rejected, and does not consume a Private Payment List. The regression test verifies Dismiss remains actionable and no retry starts from the old context.

The matching iOS fixes are isolated in synonymdev/bitkit-ios#684: malformed remote markers no longer block other contacts, and incoming request amounts are used during initial LN/on-chain balance validation so the standard insufficient Spending/Savings error appears before coin selection.

Local verification: 193 focused Android tests passed; detekt completed successfully with only unrelated pre-existing findings.

[piotr-iohk]

Retested after 5d39cd9.

Enable — still fails. ❌

Toggle Enable payments with contacts → Unknown error, toggle does not stay on. Same staging contact as before (pubky1jy146y751hkgqk9p69ds5cqf461aj5x7c8ptbca5rw6m9asotso). Recording + logs attached.

This is not the noise_public_key inspect-fail anymore. Logs are PrivateUnavailable. In this run I turned the toggle off first; disable cleanup already failed with that error, then re-enable with cleanup still pending fail-closes again. Settings still maps it to Unknown error.

Same user-facing miss on iOS #684 (toast there is Private Paykit is not available).

Steps:

1. Paykit UI on. Profile exists. Staging pubky above saved as a contact (need not be live).
2. Payments with contacts off (or turn it off first).
3. Enable payments with contacts.
4. Toast is Unknown error; toggle stays off.

Screen.Recording.2026-08-27.at.10.24.05.-.android.mov

logs-android.zip

Over-balance — looks good on Android. ✅

Incoming request larger than the wallet: one Insufficient Savings / Spending toast, request stays pending and dismissible. No already in progress loop.

iOS #684 still repeats that toast (see that PR).

[jvsena42]

Code review

Reviewed git diff master...HEAD at 56ce990 (merge-base 6ae3cb7) — 34 files, ~3.8k added lines. 10 findings inline, roughly in severity order: the ReceiveSheet start-destination change and the dropped firstError in PrivatePaykitRepo look like the two most likely to bite in practice.

Checked and looked correct: the generation/identity guards in PaykitPaymentRequestRepo (activate/refresh/synchronizeLocked/isCurrentState), creationMutex.tryLock with finally unlock in propose, expiration rescheduling, the hideSheet re-entrancy guard, SheetHost's confirmValueChange + rememberUpdatedState pairing, the scrim's pointer-consuming modifier, the stopped/recursion loop in presentNextIncomingPaykitPaymentRequest, and the sats/BTC BigDecimal conversions.

One judgement call I did not flag as a defect: the string-literal match in canDeferStaleSession is brittle against SDK message changes.

[ben-kaufman]

Addressed the remaining enable/disable QA path in signed, rebased commit 531578e.

The private setting now reflects the user choice independently of transient transport cleanup or immediate Noise availability:

• Disable commits private sharing off and records failed remote cleanup as durable deferred work instead of restoring the toggle.
• Re-enable supersedes pending removal and prepares saved contacts opportunistically; it no longer requires a live peer or immediate private endpoint publication to keep the toggle enabled.
• Recovery persists the cleanup marker before remote removal and local pruning, so a failure between those stages remains retryable. The cached-publication fallback still recovers older states where the marker was not stored.
• Malformed remote markers remain unusable, and there is still no private-to-public payment fallback.

Regression coverage includes deferred disable cleanup, re-enable with pending cleanup, recovery without a marker, failure after remote cleanup but before local pruning, and total versus partial marker-selection failure. The over-balance behavior that passed the retest is unchanged.

Post-rebase verification: full testDevDebugUnitTest, detekt, and compileDevDebugAndroidTestKotlin pass. The stack is rebased onto current master and all 13 PR commits are signed.

[piotr-iohk]

Retested. LGTM.

[jvsena42]

tAck

Reviewed the code manually and tested with journeys

[ben-kaufman]

This PR adds private Paykit Payment Requests to Bitkit.

Description

1. Automatically opens incoming requests in the existing Send confirmation flow with the requesting contact, exact amount, and a Payment Request title.
2. Keeps dismissed requests actionable through a bell, preview sheet, and full request history, with manual reopen and explicit rejection.
3. Adds outgoing request creation from Receive for linked, saved contacts, including amount, note, expiry, queued delivery state, and sent history.
4. Drops expired or remotely unavailable requests, keeps presentation state scoped to the active Pubky identity, and protects account changes, sheet transitions, and overlapping actions.
5. Requires strict private resolution for requests: a consumed Private Payment List is never reused, another endpoint from that list is not attempted, and public details are never used as fallback while waiting for a newer list.
6. Updates Paykit to 0.1.0-rc44 and adds local E2E homeserver configuration plus safe cold-start restoration for externally managed Pubky sessions.

The request payload itself remains SDK-backed and durable; Bitkit persists only encrypted, identity-scoped presentation suppression, not a duplicate request queue. Payment proofs and receipts remain out of scope.

Dependencies:

• Paykit 0.1.0-rc44
• Local Locks interoperability was verified with paykit-server#2 at 41cda2567226a690a012770017d5e7c1d49e2a2b.
• Companion iOS PR: synonymdev/bitkit-ios#676

Preview

N/A — proof recordings were completed locally and are intentionally not attached to the PR.

QA Notes

Manual Tests

• 1. Clean wallet → create Pubky profile → enable Paykit and Contact Payments → add the peer as a contact: private-capable request action appears once the Noise link is established.
• 2. Peer creates a private request → Home: Payment Request opens automatically with the correct contact and amount.
• 3. Payment Request → dismiss without rejecting → bell → request preview → Pay: the request remains queued, reopens, and pays successfully.
• 4. Peer creates a second request after payment → Pay: a newer Private Payment List is used; the consumed list is not reused and no public fallback occurs.
• 5. Receive → Send Payment Request → enter amount, note, and expiry → select linked contact → Send: request is queued once and appears in sent history.
• 6. Incoming request → Reject: only that request becomes terminal and the private payment list is not consumed.
• 7. Incoming request → dismiss → relaunch: request remains discoverable without automatically reopening again; expired requests disappear live.
• 8. Cross-platform E2E: iOS creates two requests that Android receives and pays, and Android creates two requests that iOS receives and pays, on clean regtest state.

Automated Checks

• PaykitPaymentRequestRepoTest.kt: covers mapping, eligibility, proposal delivery, rejection, expiry, identity-scoped presentation state, and action serialization.
• PaykitSdkServiceTest.kt: covers exact identity enforcement and safe deferred session restoration.
• AppViewModelSendFlowTest.kt: covers automatic/manual presentation, sheet transitions, identity changes, newer-list retry, strict private resolution, and payment lifecycle races.
• PaymentRequestExpirationTest.kt: covers expiry selection and retained draft state.
• SheetHostTest.kt: covers locked sheet dismissal and scrim input isolation during durable proposal creation.
• Local verification passed: app compile, Android-test compile, complete dev unit suite, detekt, and git diff --check.
• Both final cross-platform proof videos decoded end to end without errors.

[piotr-iohk]

Flagging while QA’ing with the staging public-pay pubkys — not a prod issue (Paykit UI is still hidden).

Enabling payments with contacts fail-closes with Unknown error if a saved contact’s receiver marker doesn’t parse (here: missing noise_public_key). I hit it on:

• pubky1jy146y751hkgqk9p69ds5cqf461aj5x7c8ptbca5rw6m9asotso
• pubkynekaxdyt5ktoqyufd7cgug6qppa7999hm46wfqdzm6jqnr8tj16o

In principle the same thing could happen with any broken / outdated profile marker, not only these fixtures. Recording attached. Same surface on iOS after #676 (toast there is Private Paykit is not available).

Steps:

1. Enable Paykit UI. Create a profile. Leave payments with contacts off.
2. Add either (or both) staging pubkys above as contacts. They do not need to be live.
3. Enable payments with contacts.
4. Toast is Unknown error and the toggle stays off.

Screen.Recording.2026-08-26.at.10.12.34.mov

logs.zip

[piotr-iohk]

Flagging from QA: paying a payment request that’s larger than the wallet balance.

Same setup, two directions, both recordings attached:

• iOS → Android (this PR): incoming sheet, Pay → toast Insufficient Spending Balance (e.g. ₿ 78,244 more needed to pay this Lightning invoice) and a red-bordered card. Dismiss then fails with Payment request operation is already in progress. Toast / error repeats; request stays on the sheet and is hard to dismiss.

Screen.Recording.2026-08-26.at.14.06.24.mov

• Android → iOS (ldk-node Error #676, already merged):Pay → Please try again. Coin selection failed. Dismiss is fine; the copy is just the wrong error.

Screen.Recording.2026-08-26.at.14.18.16.mov

Steps:

1. Two live wallets with payments-with-contacts on. Put ~88k on the payer (split savings + spending is fine).
2. Other wallet requests more than that total (100k Android-as-payer, 90k iOS-as-payer).
3. On the incoming request, tap Pay, then try Dismiss.

Expected: don’t enter confirm if the amount is above spendable. On Android, Dismiss should still work after a failed Pay (no already in progress loop).

[ben-kaufman]

Addressed both QA findings in signed commit 5d39cd96a:

• A malformed remote receiver marker is still rejected and cannot be used, but its per-contact inspection error no longer aborts global private endpoint publication for valid contacts. The regression test now covers the immediate-publication path used when enabling Contact Payments.
• An unaffordable request now releases its manual presentation state after showing the existing insufficient-balance message. It remains pending and dismissible, is not accepted or rejected, and does not consume a Private Payment List. The regression test verifies Dismiss remains actionable and no retry starts from the old context.

The matching iOS fixes are isolated in synonymdev/bitkit-ios#684: malformed remote markers no longer block other contacts, and incoming request amounts are used during initial LN/on-chain balance validation so the standard insufficient Spending/Savings error appears before coin selection.

Local verification: 193 focused Android tests passed; detekt completed successfully with only unrelated pre-existing findings.

[piotr-iohk]

Retested after 5d39cd9.

Enable — still fails. ❌

Toggle Enable payments with contacts → Unknown error, toggle does not stay on. Same staging contact as before (pubky1jy146y751hkgqk9p69ds5cqf461aj5x7c8ptbca5rw6m9asotso). Recording + logs attached.

This is not the noise_public_key inspect-fail anymore. Logs are PrivateUnavailable. In this run I turned the toggle off first; disable cleanup already failed with that error, then re-enable with cleanup still pending fail-closes again. Settings still maps it to Unknown error.

Same user-facing miss on iOS #684 (toast there is Private Paykit is not available).

Steps:

1. Paykit UI on. Profile exists. Staging pubky above saved as a contact (need not be live).
2. Payments with contacts off (or turn it off first).
3. Enable payments with contacts.
4. Toast is Unknown error; toggle stays off.

Screen.Recording.2026-08-27.at.10.24.05.-.android.mov

logs-android.zip

Over-balance — looks good on Android. ✅

Incoming request larger than the wallet: one Insufficient Savings / Spending toast, request stays pending and dismissible. No already in progress loop.

iOS #684 still repeats that toast (see that PR).

[jvsena42]

Code review

Reviewed git diff master...HEAD at 56ce990 (merge-base 6ae3cb7) — 34 files, ~3.8k added lines. 10 findings inline, roughly in severity order: the ReceiveSheet start-destination change and the dropped firstError in PrivatePaykitRepo look like the two most likely to bite in practice.

Checked and looked correct: the generation/identity guards in PaykitPaymentRequestRepo (activate/refresh/synchronizeLocked/isCurrentState), creationMutex.tryLock with finally unlock in propose, expiration rescheduling, the hideSheet re-entrancy guard, SheetHost's confirmValueChange + rememberUpdatedState pairing, the scrim's pointer-consuming modifier, the stopped/recursion loop in presentNextIncomingPaykitPaymentRequest, and the sats/BTC BigDecimal conversions.

One judgement call I did not flag as a defect: the string-literal match in canDeferStaleSession is brittle against SDK message changes.

[ben-kaufman]

Addressed the remaining enable/disable QA path in signed, rebased commit 531578e.

The private setting now reflects the user choice independently of transient transport cleanup or immediate Noise availability:

• Disable commits private sharing off and records failed remote cleanup as durable deferred work instead of restoring the toggle.
• Re-enable supersedes pending removal and prepares saved contacts opportunistically; it no longer requires a live peer or immediate private endpoint publication to keep the toggle enabled.
• Recovery persists the cleanup marker before remote removal and local pruning, so a failure between those stages remains retryable. The cached-publication fallback still recovers older states where the marker was not stored.
• Malformed remote markers remain unusable, and there is still no private-to-public payment fallback.

Regression coverage includes deferred disable cleanup, re-enable with pending cleanup, recovery without a marker, failure after remote cleanup but before local pruning, and total versus partial marker-selection failure. The over-balance behavior that passed the retest is unchanged.

Post-rebase verification: full testDevDebugUnitTest, detekt, and compileDevDebugAndroidTestKotlin pass. The stack is rebased onto current master and all 13 PR commits are signed.

[piotr-iohk]

Retested. LGTM.

[jvsena42]

tAck

Reviewed the code manually and tested with journeys

[ben-kaufman]

This PR adds private Paykit Payment Requests to Bitkit.

Description

1. Automatically opens incoming requests in the existing Send confirmation flow with the requesting contact, exact amount, and a Payment Request title.
2. Keeps dismissed requests actionable through a bell, preview sheet, and full request history, with manual reopen and explicit rejection.
3. Adds outgoing request creation from Receive for linked, saved contacts, including amount, note, expiry, queued delivery state, and sent history.
4. Drops expired or remotely unavailable requests, keeps presentation state scoped to the active Pubky identity, and protects account changes, sheet transitions, and overlapping actions.
5. Requires strict private resolution for requests: a consumed Private Payment List is never reused, another endpoint from that list is not attempted, and public details are never used as fallback while waiting for a newer list.
6. Updates Paykit to 0.1.0-rc44 and adds local E2E homeserver configuration plus safe cold-start restoration for externally managed Pubky sessions.

The request payload itself remains SDK-backed and durable; Bitkit persists only encrypted, identity-scoped presentation suppression, not a duplicate request queue. Payment proofs and receipts remain out of scope.

Dependencies:

• Paykit 0.1.0-rc44
• Local Locks interoperability was verified with paykit-server#2 at 41cda2567226a690a012770017d5e7c1d49e2a2b.
• Companion iOS PR: synonymdev/bitkit-ios#676

Preview

N/A — proof recordings were completed locally and are intentionally not attached to the PR.

QA Notes

Manual Tests

• 1. Clean wallet → create Pubky profile → enable Paykit and Contact Payments → add the peer as a contact: private-capable request action appears once the Noise link is established.
• 2. Peer creates a private request → Home: Payment Request opens automatically with the correct contact and amount.
• 3. Payment Request → dismiss without rejecting → bell → request preview → Pay: the request remains queued, reopens, and pays successfully.
• 4. Peer creates a second request after payment → Pay: a newer Private Payment List is used; the consumed list is not reused and no public fallback occurs.
• 5. Receive → Send Payment Request → enter amount, note, and expiry → select linked contact → Send: request is queued once and appears in sent history.
• 6. Incoming request → Reject: only that request becomes terminal and the private payment list is not consumed.
• 7. Incoming request → dismiss → relaunch: request remains discoverable without automatically reopening again; expired requests disappear live.
• 8. Cross-platform E2E: iOS creates two requests that Android receives and pays, and Android creates two requests that iOS receives and pays, on clean regtest state.

Automated Checks

• PaykitPaymentRequestRepoTest.kt: covers mapping, eligibility, proposal delivery, rejection, expiry, identity-scoped presentation state, and action serialization.
• PaykitSdkServiceTest.kt: covers exact identity enforcement and safe deferred session restoration.
• AppViewModelSendFlowTest.kt: covers automatic/manual presentation, sheet transitions, identity changes, newer-list retry, strict private resolution, and payment lifecycle races.
• PaymentRequestExpirationTest.kt: covers expiry selection and retained draft state.
• SheetHostTest.kt: covers locked sheet dismissal and scrim input isolation during durable proposal creation.
• Local verification passed: app compile, Android-test compile, complete dev unit suite, detekt, and git diff --check.
• Both final cross-platform proof videos decoded end to end without errors.

[piotr-iohk]

Flagging while QA’ing with the staging public-pay pubkys — not a prod issue (Paykit UI is still hidden).

Enabling payments with contacts fail-closes with Unknown error if a saved contact’s receiver marker doesn’t parse (here: missing noise_public_key). I hit it on:

• pubky1jy146y751hkgqk9p69ds5cqf461aj5x7c8ptbca5rw6m9asotso
• pubkynekaxdyt5ktoqyufd7cgug6qppa7999hm46wfqdzm6jqnr8tj16o

In principle the same thing could happen with any broken / outdated profile marker, not only these fixtures. Recording attached. Same surface on iOS after #676 (toast there is Private Paykit is not available).

Steps:

1. Enable Paykit UI. Create a profile. Leave payments with contacts off.
2. Add either (or both) staging pubkys above as contacts. They do not need to be live.
3. Enable payments with contacts.
4. Toast is Unknown error and the toggle stays off.

Screen.Recording.2026-08-26.at.10.12.34.mov

logs.zip

[piotr-iohk]

Flagging from QA: paying a payment request that’s larger than the wallet balance.

Same setup, two directions, both recordings attached:

• iOS → Android (this PR): incoming sheet, Pay → toast Insufficient Spending Balance (e.g. ₿ 78,244 more needed to pay this Lightning invoice) and a red-bordered card. Dismiss then fails with Payment request operation is already in progress. Toast / error repeats; request stays on the sheet and is hard to dismiss.

Screen.Recording.2026-08-26.at.14.06.24.mov

• Android → iOS (ldk-node Error #676, already merged):Pay → Please try again. Coin selection failed. Dismiss is fine; the copy is just the wrong error.

Screen.Recording.2026-08-26.at.14.18.16.mov

Steps:

1. Two live wallets with payments-with-contacts on. Put ~88k on the payer (split savings + spending is fine).
2. Other wallet requests more than that total (100k Android-as-payer, 90k iOS-as-payer).
3. On the incoming request, tap Pay, then try Dismiss.

Expected: don’t enter confirm if the amount is above spendable. On Android, Dismiss should still work after a failed Pay (no already in progress loop).

[ben-kaufman]

Addressed both QA findings in signed commit 5d39cd96a:

• A malformed remote receiver marker is still rejected and cannot be used, but its per-contact inspection error no longer aborts global private endpoint publication for valid contacts. The regression test now covers the immediate-publication path used when enabling Contact Payments.
• An unaffordable request now releases its manual presentation state after showing the existing insufficient-balance message. It remains pending and dismissible, is not accepted or rejected, and does not consume a Private Payment List. The regression test verifies Dismiss remains actionable and no retry starts from the old context.

The matching iOS fixes are isolated in synonymdev/bitkit-ios#684: malformed remote markers no longer block other contacts, and incoming request amounts are used during initial LN/on-chain balance validation so the standard insufficient Spending/Savings error appears before coin selection.

Local verification: 193 focused Android tests passed; detekt completed successfully with only unrelated pre-existing findings.

[piotr-iohk]

Retested after 5d39cd9.

Enable — still fails. ❌

Toggle Enable payments with contacts → Unknown error, toggle does not stay on. Same staging contact as before (pubky1jy146y751hkgqk9p69ds5cqf461aj5x7c8ptbca5rw6m9asotso). Recording + logs attached.

This is not the noise_public_key inspect-fail anymore. Logs are PrivateUnavailable. In this run I turned the toggle off first; disable cleanup already failed with that error, then re-enable with cleanup still pending fail-closes again. Settings still maps it to Unknown error.

Same user-facing miss on iOS #684 (toast there is Private Paykit is not available).

Steps:

1. Paykit UI on. Profile exists. Staging pubky above saved as a contact (need not be live).
2. Payments with contacts off (or turn it off first).
3. Enable payments with contacts.
4. Toast is Unknown error; toggle stays off.

Screen.Recording.2026-08-27.at.10.24.05.-.android.mov

logs-android.zip

Over-balance — looks good on Android. ✅

Incoming request larger than the wallet: one Insufficient Savings / Spending toast, request stays pending and dismissible. No already in progress loop.

iOS #684 still repeats that toast (see that PR).

[jvsena42]

Code review

Reviewed git diff master...HEAD at 56ce990 (merge-base 6ae3cb7) — 34 files, ~3.8k added lines. 10 findings inline, roughly in severity order: the ReceiveSheet start-destination change and the dropped firstError in PrivatePaykitRepo look like the two most likely to bite in practice.

Checked and looked correct: the generation/identity guards in PaykitPaymentRequestRepo (activate/refresh/synchronizeLocked/isCurrentState), creationMutex.tryLock with finally unlock in propose, expiration rescheduling, the hideSheet re-entrancy guard, SheetHost's confirmValueChange + rememberUpdatedState pairing, the scrim's pointer-consuming modifier, the stopped/recursion loop in presentNextIncomingPaykitPaymentRequest, and the sats/BTC BigDecimal conversions.

One judgement call I did not flag as a defect: the string-literal match in canDeferStaleSession is brittle against SDK message changes.

[ben-kaufman]

Addressed the remaining enable/disable QA path in signed, rebased commit 531578e.

The private setting now reflects the user choice independently of transient transport cleanup or immediate Noise availability:

• Disable commits private sharing off and records failed remote cleanup as durable deferred work instead of restoring the toggle.
• Re-enable supersedes pending removal and prepares saved contacts opportunistically; it no longer requires a live peer or immediate private endpoint publication to keep the toggle enabled.
• Recovery persists the cleanup marker before remote removal and local pruning, so a failure between those stages remains retryable. The cached-publication fallback still recovers older states where the marker was not stored.
• Malformed remote markers remain unusable, and there is still no private-to-public payment fallback.

Regression coverage includes deferred disable cleanup, re-enable with pending cleanup, recovery without a marker, failure after remote cleanup but before local pruning, and total versus partial marker-selection failure. The over-balance behavior that passed the retest is unchanged.

Post-rebase verification: full testDevDebugUnitTest, detekt, and compileDevDebugAndroidTestKotlin pass. The stack is rebased onto current master and all 13 PR commits are signed.

[piotr-iohk]

Retested. LGTM.

[jvsena42]

tAck

Reviewed the code manually and tested with journeys

[ben-kaufman]

This PR adds private Paykit Payment Requests to Bitkit.

Description

1. Automatically opens incoming requests in the existing Send confirmation flow with the requesting contact, exact amount, and a Payment Request title.
2. Keeps dismissed requests actionable through a bell, preview sheet, and full request history, with manual reopen and explicit rejection.
3. Adds outgoing request creation from Receive for linked, saved contacts, including amount, note, expiry, queued delivery state, and sent history.
4. Drops expired or remotely unavailable requests, keeps presentation state scoped to the active Pubky identity, and protects account changes, sheet transitions, and overlapping actions.
5. Requires strict private resolution for requests: a consumed Private Payment List is never reused, another endpoint from that list is not attempted, and public details are never used as fallback while waiting for a newer list.
6. Updates Paykit to 0.1.0-rc44 and adds local E2E homeserver configuration plus safe cold-start restoration for externally managed Pubky sessions.

The request payload itself remains SDK-backed and durable; Bitkit persists only encrypted, identity-scoped presentation suppression, not a duplicate request queue. Payment proofs and receipts remain out of scope.

Dependencies:

• Paykit 0.1.0-rc44
• Local Locks interoperability was verified with paykit-server#2 at 41cda2567226a690a012770017d5e7c1d49e2a2b.
• Companion iOS PR: synonymdev/bitkit-ios#676

Preview

N/A — proof recordings were completed locally and are intentionally not attached to the PR.

QA Notes

Manual Tests

• 1. Clean wallet → create Pubky profile → enable Paykit and Contact Payments → add the peer as a contact: private-capable request action appears once the Noise link is established.
• 2. Peer creates a private request → Home: Payment Request opens automatically with the correct contact and amount.
• 3. Payment Request → dismiss without rejecting → bell → request preview → Pay: the request remains queued, reopens, and pays successfully.
• 4. Peer creates a second request after payment → Pay: a newer Private Payment List is used; the consumed list is not reused and no public fallback occurs.
• 5. Receive → Send Payment Request → enter amount, note, and expiry → select linked contact → Send: request is queued once and appears in sent history.
• 6. Incoming request → Reject: only that request becomes terminal and the private payment list is not consumed.
• 7. Incoming request → dismiss → relaunch: request remains discoverable without automatically reopening again; expired requests disappear live.
• 8. Cross-platform E2E: iOS creates two requests that Android receives and pays, and Android creates two requests that iOS receives and pays, on clean regtest state.

Automated Checks

• PaykitPaymentRequestRepoTest.kt: covers mapping, eligibility, proposal delivery, rejection, expiry, identity-scoped presentation state, and action serialization.
• PaykitSdkServiceTest.kt: covers exact identity enforcement and safe deferred session restoration.
• AppViewModelSendFlowTest.kt: covers automatic/manual presentation, sheet transitions, identity changes, newer-list retry, strict private resolution, and payment lifecycle races.
• PaymentRequestExpirationTest.kt: covers expiry selection and retained draft state.
• SheetHostTest.kt: covers locked sheet dismissal and scrim input isolation during durable proposal creation.
• Local verification passed: app compile, Android-test compile, complete dev unit suite, detekt, and git diff --check.
• Both final cross-platform proof videos decoded end to end without errors.

[piotr-iohk]

Flagging while QA’ing with the staging public-pay pubkys — not a prod issue (Paykit UI is still hidden).

Enabling payments with contacts fail-closes with Unknown error if a saved contact’s receiver marker doesn’t parse (here: missing noise_public_key). I hit it on:

• pubky1jy146y751hkgqk9p69ds5cqf461aj5x7c8ptbca5rw6m9asotso
• pubkynekaxdyt5ktoqyufd7cgug6qppa7999hm46wfqdzm6jqnr8tj16o

In principle the same thing could happen with any broken / outdated profile marker, not only these fixtures. Recording attached. Same surface on iOS after #676 (toast there is Private Paykit is not available).

Steps:

1. Enable Paykit UI. Create a profile. Leave payments with contacts off.
2. Add either (or both) staging pubkys above as contacts. They do not need to be live.
3. Enable payments with contacts.
4. Toast is Unknown error and the toggle stays off.

Screen.Recording.2026-08-26.at.10.12.34.mov

logs.zip

[piotr-iohk]

Flagging from QA: paying a payment request that’s larger than the wallet balance.

Same setup, two directions, both recordings attached:

• iOS → Android (this PR): incoming sheet, Pay → toast Insufficient Spending Balance (e.g. ₿ 78,244 more needed to pay this Lightning invoice) and a red-bordered card. Dismiss then fails with Payment request operation is already in progress. Toast / error repeats; request stays on the sheet and is hard to dismiss.

Screen.Recording.2026-08-26.at.14.06.24.mov

• Android → iOS (ldk-node Error #676, already merged):Pay → Please try again. Coin selection failed. Dismiss is fine; the copy is just the wrong error.

Screen.Recording.2026-08-26.at.14.18.16.mov

Steps:

1. Two live wallets with payments-with-contacts on. Put ~88k on the payer (split savings + spending is fine).
2. Other wallet requests more than that total (100k Android-as-payer, 90k iOS-as-payer).
3. On the incoming request, tap Pay, then try Dismiss.

Expected: don’t enter confirm if the amount is above spendable. On Android, Dismiss should still work after a failed Pay (no already in progress loop).

[ben-kaufman]

Addressed both QA findings in signed commit 5d39cd96a:

• A malformed remote receiver marker is still rejected and cannot be used, but its per-contact inspection error no longer aborts global private endpoint publication for valid contacts. The regression test now covers the immediate-publication path used when enabling Contact Payments.
• An unaffordable request now releases its manual presentation state after showing the existing insufficient-balance message. It remains pending and dismissible, is not accepted or rejected, and does not consume a Private Payment List. The regression test verifies Dismiss remains actionable and no retry starts from the old context.

The matching iOS fixes are isolated in synonymdev/bitkit-ios#684: malformed remote markers no longer block other contacts, and incoming request amounts are used during initial LN/on-chain balance validation so the standard insufficient Spending/Savings error appears before coin selection.

Local verification: 193 focused Android tests passed; detekt completed successfully with only unrelated pre-existing findings.

[piotr-iohk]

Retested after 5d39cd9.

Enable — still fails. ❌

Toggle Enable payments with contacts → Unknown error, toggle does not stay on. Same staging contact as before (pubky1jy146y751hkgqk9p69ds5cqf461aj5x7c8ptbca5rw6m9asotso). Recording + logs attached.

This is not the noise_public_key inspect-fail anymore. Logs are PrivateUnavailable. In this run I turned the toggle off first; disable cleanup already failed with that error, then re-enable with cleanup still pending fail-closes again. Settings still maps it to Unknown error.

Same user-facing miss on iOS #684 (toast there is Private Paykit is not available).

Steps:

1. Paykit UI on. Profile exists. Staging pubky above saved as a contact (need not be live).
2. Payments with contacts off (or turn it off first).
3. Enable payments with contacts.
4. Toast is Unknown error; toggle stays off.

Screen.Recording.2026-08-27.at.10.24.05.-.android.mov

logs-android.zip

Over-balance — looks good on Android. ✅

Incoming request larger than the wallet: one Insufficient Savings / Spending toast, request stays pending and dismissible. No already in progress loop.

iOS #684 still repeats that toast (see that PR).

[jvsena42]

Code review

Reviewed git diff master...HEAD at 56ce990 (merge-base 6ae3cb7) — 34 files, ~3.8k added lines. 10 findings inline, roughly in severity order: the ReceiveSheet start-destination change and the dropped firstError in PrivatePaykitRepo look like the two most likely to bite in practice.

Checked and looked correct: the generation/identity guards in PaykitPaymentRequestRepo (activate/refresh/synchronizeLocked/isCurrentState), creationMutex.tryLock with finally unlock in propose, expiration rescheduling, the hideSheet re-entrancy guard, SheetHost's confirmValueChange + rememberUpdatedState pairing, the scrim's pointer-consuming modifier, the stopped/recursion loop in presentNextIncomingPaykitPaymentRequest, and the sats/BTC BigDecimal conversions.

One judgement call I did not flag as a defect: the string-literal match in canDeferStaleSession is brittle against SDK message changes.

[ben-kaufman]

Addressed the remaining enable/disable QA path in signed, rebased commit 531578e.

The private setting now reflects the user choice independently of transient transport cleanup or immediate Noise availability:

• Disable commits private sharing off and records failed remote cleanup as durable deferred work instead of restoring the toggle.
• Re-enable supersedes pending removal and prepares saved contacts opportunistically; it no longer requires a live peer or immediate private endpoint publication to keep the toggle enabled.
• Recovery persists the cleanup marker before remote removal and local pruning, so a failure between those stages remains retryable. The cached-publication fallback still recovers older states where the marker was not stored.
• Malformed remote markers remain unusable, and there is still no private-to-public payment fallback.

Regression coverage includes deferred disable cleanup, re-enable with pending cleanup, recovery without a marker, failure after remote cleanup but before local pruning, and total versus partial marker-selection failure. The over-balance behavior that passed the retest is unchanged.

Post-rebase verification: full testDevDebugUnitTest, detekt, and compileDevDebugAndroidTestKotlin pass. The stack is rebased onto current master and all 13 PR commits are signed.

[piotr-iohk]

Retested. LGTM.

[jvsena42]

tAck

Reviewed the code manually and tested with journeys

[ben-kaufman]

This PR adds private Paykit Payment Requests to Bitkit.

Description

1. Automatically opens incoming requests in the existing Send confirmation flow with the requesting contact, exact amount, and a Payment Request title.
2. Keeps dismissed requests actionable through a bell, preview sheet, and full request history, with manual reopen and explicit rejection.
3. Adds outgoing request creation from Receive for linked, saved contacts, including amount, note, expiry, queued delivery state, and sent history.
4. Drops expired or remotely unavailable requests, keeps presentation state scoped to the active Pubky identity, and protects account changes, sheet transitions, and overlapping actions.
5. Requires strict private resolution for requests: a consumed Private Payment List is never reused, another endpoint from that list is not attempted, and public details are never used as fallback while waiting for a newer list.
6. Updates Paykit to 0.1.0-rc44 and adds local E2E homeserver configuration plus safe cold-start restoration for externally managed Pubky sessions.

The request payload itself remains SDK-backed and durable; Bitkit persists only encrypted, identity-scoped presentation suppression, not a duplicate request queue. Payment proofs and receipts remain out of scope.

Dependencies:

• Paykit 0.1.0-rc44
• Local Locks interoperability was verified with paykit-server#2 at 41cda2567226a690a012770017d5e7c1d49e2a2b.
• Companion iOS PR: synonymdev/bitkit-ios#676

Preview

N/A — proof recordings were completed locally and are intentionally not attached to the PR.

QA Notes

Manual Tests

• 1. Clean wallet → create Pubky profile → enable Paykit and Contact Payments → add the peer as a contact: private-capable request action appears once the Noise link is established.
• 2. Peer creates a private request → Home: Payment Request opens automatically with the correct contact and amount.
• 3. Payment Request → dismiss without rejecting → bell → request preview → Pay: the request remains queued, reopens, and pays successfully.
• 4. Peer creates a second request after payment → Pay: a newer Private Payment List is used; the consumed list is not reused and no public fallback occurs.
• 5. Receive → Send Payment Request → enter amount, note, and expiry → select linked contact → Send: request is queued once and appears in sent history.
• 6. Incoming request → Reject: only that request becomes terminal and the private payment list is not consumed.
• 7. Incoming request → dismiss → relaunch: request remains discoverable without automatically reopening again; expired requests disappear live.
• 8. Cross-platform E2E: iOS creates two requests that Android receives and pays, and Android creates two requests that iOS receives and pays, on clean regtest state.

Automated Checks

• PaykitPaymentRequestRepoTest.kt: covers mapping, eligibility, proposal delivery, rejection, expiry, identity-scoped presentation state, and action serialization.
• PaykitSdkServiceTest.kt: covers exact identity enforcement and safe deferred session restoration.
• AppViewModelSendFlowTest.kt: covers automatic/manual presentation, sheet transitions, identity changes, newer-list retry, strict private resolution, and payment lifecycle races.
• PaymentRequestExpirationTest.kt: covers expiry selection and retained draft state.
• SheetHostTest.kt: covers locked sheet dismissal and scrim input isolation during durable proposal creation.
• Local verification passed: app compile, Android-test compile, complete dev unit suite, detekt, and git diff --check.
• Both final cross-platform proof videos decoded end to end without errors.

[piotr-iohk]

Flagging while QA’ing with the staging public-pay pubkys — not a prod issue (Paykit UI is still hidden).

Enabling payments with contacts fail-closes with Unknown error if a saved contact’s receiver marker doesn’t parse (here: missing noise_public_key). I hit it on:

• pubky1jy146y751hkgqk9p69ds5cqf461aj5x7c8ptbca5rw6m9asotso
• pubkynekaxdyt5ktoqyufd7cgug6qppa7999hm46wfqdzm6jqnr8tj16o

In principle the same thing could happen with any broken / outdated profile marker, not only these fixtures. Recording attached. Same surface on iOS after #676 (toast there is Private Paykit is not available).

Steps:

1. Enable Paykit UI. Create a profile. Leave payments with contacts off.
2. Add either (or both) staging pubkys above as contacts. They do not need to be live.
3. Enable payments with contacts.
4. Toast is Unknown error and the toggle stays off.

Screen.Recording.2026-08-26.at.10.12.34.mov

logs.zip

[piotr-iohk]

Flagging from QA: paying a payment request that’s larger than the wallet balance.

Same setup, two directions, both recordings attached:

• iOS → Android (this PR): incoming sheet, Pay → toast Insufficient Spending Balance (e.g. ₿ 78,244 more needed to pay this Lightning invoice) and a red-bordered card. Dismiss then fails with Payment request operation is already in progress. Toast / error repeats; request stays on the sheet and is hard to dismiss.

Screen.Recording.2026-08-26.at.14.06.24.mov

• Android → iOS (ldk-node Error #676, already merged):Pay → Please try again. Coin selection failed. Dismiss is fine; the copy is just the wrong error.

Screen.Recording.2026-08-26.at.14.18.16.mov

Steps:

1. Two live wallets with payments-with-contacts on. Put ~88k on the payer (split savings + spending is fine).
2. Other wallet requests more than that total (100k Android-as-payer, 90k iOS-as-payer).
3. On the incoming request, tap Pay, then try Dismiss.

Expected: don’t enter confirm if the amount is above spendable. On Android, Dismiss should still work after a failed Pay (no already in progress loop).

[ben-kaufman]

Addressed both QA findings in signed commit 5d39cd96a:

• A malformed remote receiver marker is still rejected and cannot be used, but its per-contact inspection error no longer aborts global private endpoint publication for valid contacts. The regression test now covers the immediate-publication path used when enabling Contact Payments.
• An unaffordable request now releases its manual presentation state after showing the existing insufficient-balance message. It remains pending and dismissible, is not accepted or rejected, and does not consume a Private Payment List. The regression test verifies Dismiss remains actionable and no retry starts from the old context.

The matching iOS fixes are isolated in synonymdev/bitkit-ios#684: malformed remote markers no longer block other contacts, and incoming request amounts are used during initial LN/on-chain balance validation so the standard insufficient Spending/Savings error appears before coin selection.

Local verification: 193 focused Android tests passed; detekt completed successfully with only unrelated pre-existing findings.

[piotr-iohk]

Retested after 5d39cd9.

Enable — still fails. ❌

Toggle Enable payments with contacts → Unknown error, toggle does not stay on. Same staging contact as before (pubky1jy146y751hkgqk9p69ds5cqf461aj5x7c8ptbca5rw6m9asotso). Recording + logs attached.

This is not the noise_public_key inspect-fail anymore. Logs are PrivateUnavailable. In this run I turned the toggle off first; disable cleanup already failed with that error, then re-enable with cleanup still pending fail-closes again. Settings still maps it to Unknown error.

Same user-facing miss on iOS #684 (toast there is Private Paykit is not available).

Steps:

1. Paykit UI on. Profile exists. Staging pubky above saved as a contact (need not be live).
2. Payments with contacts off (or turn it off first).
3. Enable payments with contacts.
4. Toast is Unknown error; toggle stays off.

Screen.Recording.2026-08-27.at.10.24.05.-.android.mov

logs-android.zip

Over-balance — looks good on Android. ✅

Incoming request larger than the wallet: one Insufficient Savings / Spending toast, request stays pending and dismissible. No already in progress loop.

iOS #684 still repeats that toast (see that PR).

[jvsena42]

Code review

Reviewed git diff master...HEAD at 56ce990 (merge-base 6ae3cb7) — 34 files, ~3.8k added lines. 10 findings inline, roughly in severity order: the ReceiveSheet start-destination change and the dropped firstError in PrivatePaykitRepo look like the two most likely to bite in practice.

Checked and looked correct: the generation/identity guards in PaykitPaymentRequestRepo (activate/refresh/synchronizeLocked/isCurrentState), creationMutex.tryLock with finally unlock in propose, expiration rescheduling, the hideSheet re-entrancy guard, SheetHost's confirmValueChange + rememberUpdatedState pairing, the scrim's pointer-consuming modifier, the stopped/recursion loop in presentNextIncomingPaykitPaymentRequest, and the sats/BTC BigDecimal conversions.

One judgement call I did not flag as a defect: the string-literal match in canDeferStaleSession is brittle against SDK message changes.

[ben-kaufman]

Addressed the remaining enable/disable QA path in signed, rebased commit 531578e.

The private setting now reflects the user choice independently of transient transport cleanup or immediate Noise availability:

• Disable commits private sharing off and records failed remote cleanup as durable deferred work instead of restoring the toggle.
• Re-enable supersedes pending removal and prepares saved contacts opportunistically; it no longer requires a live peer or immediate private endpoint publication to keep the toggle enabled.
• Recovery persists the cleanup marker before remote removal and local pruning, so a failure between those stages remains retryable. The cached-publication fallback still recovers older states where the marker was not stored.
• Malformed remote markers remain unusable, and there is still no private-to-public payment fallback.

Regression coverage includes deferred disable cleanup, re-enable with pending cleanup, recovery without a marker, failure after remote cleanup but before local pruning, and total versus partial marker-selection failure. The over-balance behavior that passed the retest is unchanged.

Post-rebase verification: full testDevDebugUnitTest, detekt, and compileDevDebugAndroidTestKotlin pass. The stack is rebased onto current master and all 13 PR commits are signed.

[piotr-iohk]

Retested. LGTM.

[jvsena42]

tAck

Reviewed the code manually and tested with journeys