feat: support incoming paykit requests

[ben-kaufman]

Description

This PR builds on #1084 to support incoming Paykit payment requests:

• Updates Paykit to 0.1.0-rc39 and uses its separate public and private payment resolution APIs.
• Receives supported one-time Bitcoin payment requests while Bitkit is active, discarding expired or unsupported requests.
• Reuses the existing send confirmation and payment flow, with a Payment Request title, fixed requested amount, and requesting contact.
• Accepts a request only after the user approves it, before submitting the payment.
• Uses public payment details only when no Noise channel is established and never falls back from private to public resolution.
• Persists consumed private payment-list versions before submission, treats submitted, pending, and uncertain payments as consumed, waits for newer details, and serializes private payments per contact and receiver path.
• Advertises payment-request support with the live Paykit session.

Payment proofs and receipts remain out of scope.

References:

• Base PR: feat: add Paykit server accounts #1084
• Companion iOS PR: feat: support incoming paykit requests bitkit-ios#637

Preview

N/A — the existing payment UI is reused, and no media is attached.

QA Notes

Manual Tests

• 1. Receive a request from a linked Paykit contact while Bitkit is active: the Payment Request confirmation opens with the contact and requested amount.
• 2. Swipe to pay: the request is accepted and payment continues through the existing send flow.
• 3. Receive or retain a request past its expiration: it is discarded and not presented.
• 4. Attempt another private payment before the contact publishes a newer payment list: Bitkit waits and does not reuse the consumed details or fall back to public details.

Automated Checks

• PaykitPaymentRequestRepoTest.kt: request mapping, expiry, lifecycle, and acceptance.
• PrivatePaykitRepoTest.kt: separate resolution, consumed-list persistence, and prevention of private payment-detail reuse.
• AppViewModelSendFlowTest.kt: presentation, polling, approval order, expiry, and duplicate or pending consumption.
• Gradle compilation, affected unit tests, and Detekt passed.

[greptile-apps]

Greptile Summary

This PR adds support for incoming Paykit payment requests. The main changes are:

• Polls for supported requests while the app is active.
• Reuses the send confirmation flow with fixed request details.
• Separates private and public payment resolution.
• Persists consumed private payment-list versions.
• Updates Paykit capabilities, SDK adapters, and related tests.

Confidence Score: 4/5

The legacy backup restore path needs a compatibility fix before merging.

• Backups created by previous releases are raw SDK-state strings.
• The updated restore path requires the new JSON envelope and fails before restoring old data.
• The request lifecycle and private payment flow otherwise have consistent guards and state handling.

app/src/main/java/to/bitkit/repositories/PrivatePaykitRepo.kt

Important Files Changed

Filename	Overview
app/src/main/java/to/bitkit/repositories/PrivatePaykitRepo.kt	Adds private resolution and consumed-version persistence, but the new backup envelope breaks restoration of legacy backups.
app/src/main/java/to/bitkit/repositories/PaykitPaymentRequestRepo.kt	Adds synchronized request intake, filtering, expiration, and acceptance.
app/src/main/java/to/bitkit/viewmodels/AppViewModel.kt	Connects request polling and presentation to the existing payment flow.
app/src/main/java/to/bitkit/services/PaykitSdkService.kt	Adapts the service to separate public and private Paykit APIs and advertises request support.

Sequence Diagram

sequenceDiagram
    participant Contact as Paykit Contact
    participant SDK as Paykit SDK
    participant Requests as Payment Request Repo
    participant App as App View Model
    participant Private as Private Paykit Repo
    participant Wallet as Send Flow

    Contact->>SDK: Publish payment request
    Requests->>SDK: Receive and query requests
    Requests-->>App: Emit actionable request
    App->>Private: Resolve private payment details
    Private->>SDK: Resolve after consumed version
    SDK-->>Private: Endpoint and list version
    Private-->>App: Open payment details
    App-->>Wallet: Show confirmation
    Wallet->>App: User approves
    App->>Requests: Accept request
    App->>Private: Persist consumed version
    App->>Wallet: Submit payment

Loading

_{Reviews (1): Last reviewed commit: "feat: support incoming paykit requests" | Re-trigger Greptile}

[greptile-apps]

Legacy Backups Cannot Restore

Previous releases stored exportBackupState() as a raw string, but this line now decodes every non-null backup as PrivatePaykitBackup JSON. Restoring a backup created before this change therefore fails during decoding and never calls restoreBackupState(); the restore path needs to recognize and migrate the legacy format.

[ben-kaufman]

No code change here: this raw backup format only exists in the unshipped parent Paykit work, so there are no production backups to migrate. Per the pre-release scope of this stack, we are intentionally not adding migration or backward-compatibility code.

[ben-kaufman]

Restacked onto the current #1084 head after its force-push. The request/review-fix commits are signed; the retry fix previously referenced as cf14578b1 is now e01a3ce25, with 44d58d2b8 preserving the Paykit rc39 integration across the rewritten base.

The current build failure is inherited unchanged from #1084: both jobs fail in WatchOnlyAccountStore.kt on unresolved serializedExtendedPubkey references at lines 6 and 29. I left #1084 untouched, as it is being handled separately.

[jvsena42]

Re-reviewed the changes since my last pass. All 8 comments I raised are addressed — resolved those threads. Verified locally on 796bc2b1: the Paykit unit tests (PaykitPaymentRequestRepoTest, PrivatePaykitRepoTest, PublicPaykitRepoTest, AppViewModelSendFlowTest, PaykitSdkServiceTest, ContactPaymentSettingsRepoTest) all pass and detekt is clean.

A few new findings below. Only the first one blocks.

One extra nit that has no diff line to attach to: PrivatePaykitRepoTest.kt:32 — import org.mockito.kotlin.anyOrNull is now unused (base had 4 usages, this branch has 0). detekt reports it as NoUnusedImports, but ignoreFailures = true in app/build.gradle.kts keeps CI green.

[jvsena42]

This dropped the runSuspendCatching {}.getOrDefault(false) that wrapped the helper on master, and that turns a settings toggle into a crash path.

pubkyService.currentPublicKey() reaches PaykitSdkService.currentPublicKey() → handle() + handle.initialize(), which throws PaykitException. The public hasPrivatePaymentAccess() (line 121) is called by ContactPaymentSettingsRepo.enable() outside its runSuspendCatching:

val canUsePrivateContactPayments = privatePaykitRepo.hasPrivatePaymentAccess()  // throws
return runSuspendCatching { ... }

So the throw escapes setEnabled()'s Result<Unit> contract and lands in SettingsViewModel.setContactPaymentsEnabled's bare viewModelScope.launch — uncaught coroutine exception, and _isUpdatingContactPayments stays stuck at true. PayContactsViewModel.continueToProfile has a finally so it only loses the toast, but the exception still escapes.

The other callers (canPublishPrivateEndpoints, prepareRelevantPrivateLinksIfAvailable) are all inside a runSuspendCatching, so hasPrivatePaymentAccess() is the single exposure — but it's user-reachable. Please restore the guard:

private suspend fun hasPrivatePaymentAccessForCurrentProfile(): Boolean = runSuspendCatching {
    pubkyService.currentPublicKey() ?: return@runSuspendCatching false
    paykitSdkService.hasPrivatePaymentAccess()
}.getOrDefault(false)

[jvsena42]

slashtags__error_pay_empty_msg means "no payment endpoint found", but the actual state here is "waiting for the contact to publish an updated payment list" — a transient, retryable condition the user could act on by waiting. Worth a dedicated string.

The same branch is duplicated verbatim in SendContactSelectViewModel and AddContactViewModel; folding the PublicPaykitPaymentResult → message mapping into one shared helper would keep the three in sync.

[jvsena42]

Separate from my earlier consume-before-send comment (which you answered — the rc39 contract makes that unavoidable, understood): the concern here is the window between these two calls.

validateAndAcceptIncomingPaymentRequest accepts the request on the Paykit side and removes it from pendingRequests. If consumePrivatePaymentListIfNeeded then fails (e.g. PaymentListAlreadyConsumed), we've accepted a request, made no payment, and there's no path left to retry or decline it — it's simply gone.

Consuming first (or accepting last) would close that gap. incoming payment request is accepted before its private list is consumed pins the current order, so I assume this is deliberate — just want to confirm it's the order you want.

[jvsena42]

The retry schedule saturates at 300s and never gives up. A request with expiresAt == null that never resolves will keep issuing beginPaymentRequest network calls every 5 minutes for as long as the app is foregrounded.

A max-attempt cap — after which the request falls back to the normal poll cycle — would bound it.

[jvsena42]

Nit: paykitPaymentRequestRepo.isPending(request) is evaluated twice on adjacent lines — worth hoisting into a local.

Also, the Boolean return means two different things: true at line 689 is "abort, a sheet opened" while true at line 703 is "presented". The caller treats both as return, so behaviour is right, but the name openIncomingPaymentRequestIfAvailable reads like it returns "did I open it". A small sealed result, or a rename to something like presentIncomingPaymentRequestOrStop, would make the loop easier to follow.

[jvsena42]

Nit: the amountSats <= ULong.MAX_VALUE / 1000uL guard is already enforced at construction by toSats() (takeIf { it <= ULong.MAX_VALUE / 1000uL }), so it's dead weight here. The unparenthesized ||/&& mix also reads ambiguously even though the precedence is correct — parentheses around the && clause would help.