feat: support incoming paykit requests by ben-kaufman · Pull Request #637 · synonymdev/bitkit-ios

ben-kaufman · 2026-07-22T07:57:07Z

Description

This PR builds on #630 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.

Linked Issues/Tasks

Base PR: feat: add Paykit server accounts #630
Companion Android PR: feat: support incoming paykit requests bitkit-android#1098

Screenshot / Video

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

PaykitPaymentRequestServiceTests.swift: request mapping, expiry, lifecycle, acceptance, and refresh concurrency.
PrivatePaykitServiceTests.swift: consumed-list persistence and prevention of private payment-detail reuse.
PublicPaykitServiceTests.swift: separate public payment endpoint parsing and resolution.
40 selected Paykit tests passed in the iOS simulator.
SwiftFormat, translation validation, and git diff --check passed.

greptile-apps · 2026-07-22T07:59:35Z

Greptile Summary

This PR adds support for receiving and paying incoming Paykit requests. The main changes are:

Polling, filtering, and presenting incoming one-time Bitcoin requests.
Private and public payment resolution through the Paykit rc39 APIs.
Persistent tracking of consumed private payment-list versions.
Request acceptance through the existing send confirmation flow.
Payment-request capability advertising and localized UI text.

Confidence Score: 4/5

The backup migration and payment submission paths need fixes before merging.

Existing Paykit backups fail against the new JSON wrapper.
LNURL fetch failures leave requests accepted and private details consumed without a payment attempt.
Amount-bearing invoices can submit a different amount from the one shown for approval.

PrivatePaykitService+Backup.swift, LnurlPayConfirm.swift, and SendConfirmationView.swift

Security Review

An amount-bearing Bolt11 endpoint is submitted using its embedded amount without checking that it matches the Paykit request amount shown to the user. A stale or malformed private endpoint can therefore change the amount that is paid.

Important Files Changed

Filename	Overview
Bitkit/Services/PaykitPaymentRequestService.swift	Adds request parsing, synchronization, expiration handling, presentation deduplication, and acceptance state.
Bitkit/Services/PrivatePaykitService+Payments.swift	Adds private request resolution, public fallback rules, and consumed-version enforcement.
Bitkit/Services/PrivatePaykitService+Backup.swift	Wraps Paykit backup state in a new JSON shape without restoring the previous raw-string format.
Bitkit/Views/Wallets/Send/LnurlPayConfirm.swift	Accepts and consumes incoming requests before the LNURL invoice is fetched.
Bitkit/Views/Wallets/Send/SendConfirmationView.swift	Integrates request acceptance and consumption but can submit an embedded invoice amount that differs from the requested amount.
Bitkit/AppScene.swift	Adds active-scene polling and serialized request presentation through the send sheet.
Bitkit/Services/PubkyService.swift	Adapts the Paykit integration to separate public and private rc39 APIs and advertises request support.

Sequence Diagram

sequenceDiagram
    participant Peer as Paykit Peer
    participant Manager as Request Manager
    participant Resolver as Private Resolver
    participant UI as Send Confirmation
    participant Wallet

    Peer->>Manager: Proposed payment request
    Manager->>Resolver: Resolve endpoint for requested amount
    Resolver-->>UI: Payment target and list version
    UI->>Manager: Accept request
    UI->>Resolver: Persist consumed version
    UI->>Wallet: Fetch invoice and submit payment
    Note over UI,Wallet: LNURL fetch currently happens after acceptance and consumption

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

jvsena42 · 2026-07-31T10:36:38Z

+    let amountValue: String
+    let amountSats: UInt64
+    let paymentReference: String
+    let expiresAt: Date?


is this intended to be optional? just double checking

jvsena42 · 2026-07-31T10:39:47Z

+        for request in requests {
+            do {
+                let result = try await PrivatePaykitService.shared.beginPaymentRequest(request)
+                guard sheets.activeSheetConfiguration == nil, app.contactPaymentContext == nil else { return }
+                guard case let .opened(paymentTarget, privatePaymentContext) = result else { continue }


if beginPaymentRequest never returns .opened (the counterparty has no private payment list, or no accepted endpoint matches) this method takes the continue branch and markPresentedIfPending is never called. That request then re-runs full SDK resolution on every 30 s poll and on every sheet dismissal, indefinitely, with no backoff and no user-visible feedback

There is also no reject path

jvsena42 · 2026-07-31T10:52:34Z

+    private func pollIncomingPaykitPaymentRequests() async {
+        guard scenePhase == .active else { return }
+
+        while !Task.isCancelled {
+            do {
+                try await Task.sleep(for: Self.paykitPaymentRequestRefreshInterval)
+            } catch {
+                return
+            }
+            await refreshIncomingPaykitPaymentRequests()
+        }
+    }


This method perform multiple requests every 30 seconds for as log the app is in foreground, even if nothings has changed

Maybe should back off the requests when nothing has been returned or scaling the interval by linked-peer count

jvsena42 · 2026-07-31T10:55:23Z

+        }
+    }
+
+    private func hasLiveSessionForCurrentProfile() async throws -> Bool {


this method has no remaining callers. Dead code?

jvsena42 · 2026-07-31T11:05:25Z

+                try await consumePrivatePaymentListIfNeeded(contactPaymentContext)
                let txid = try await wallet.send(address: invoice.address, sats: amount, isMaxAmount: useMaxAmount)
-                if let contactPublicKey {
-                    await PrivatePaykitService.shared.discardRemoteOnchainEndpoints(


This was the last caller of this method. Is it dead code?

ben-kaufman mentioned this pull request Jul 22, 2026

feat: support incoming paykit requests synonymdev/bitkit-android#1098

Open

4 tasks

greptile-apps Bot reviewed Jul 22, 2026

View reviewed changes

Comment thread Bitkit/Services/PrivatePaykitService+Backup.swift

Comment thread Bitkit/Views/Wallets/Send/LnurlPayConfirm.swift

Comment thread Bitkit/Views/Wallets/Send/SendConfirmationView.swift

ben-kaufman mentioned this pull request Jul 22, 2026

refactor: batch paykit contact cleanup #638

Open

ben-kaufman force-pushed the codex/paykit-watch-only-accounts branch 2 times, most recently from 990db23 to e4a5c92 Compare July 22, 2026 11:39

ben-kaufman force-pushed the codex/paykit-incoming-payment-requests branch 2 times, most recently from ae345b3 to 778f6d0 Compare July 22, 2026 14:09

ben-kaufman added 2 commits July 22, 2026 17:30

feat: support incoming paykit requests

dfeee86

fix: harden paykit request payments

9dcc431

ben-kaufman force-pushed the codex/paykit-incoming-payment-requests branch from 778f6d0 to 9dcc431 Compare July 22, 2026 15:34

Base automatically changed from codex/paykit-watch-only-accounts to master July 24, 2026 13:48

jvsena42 requested changes Jul 31, 2026

View reviewed changes

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

feat: support incoming paykit requests - #637

feat: support incoming paykit requests#637
ben-kaufman wants to merge 2 commits into
masterfrom
codex/paykit-incoming-payment-requests

ben-kaufman commented Jul 22, 2026 •

edited

Loading

Uh oh!

greptile-apps Bot commented Jul 22, 2026

Security Review

Important Files Changed

Uh oh!

Uh oh!

Uh oh!

Uh oh!

jvsena42 Jul 31, 2026

Uh oh!

jvsena42 Jul 31, 2026

Uh oh!

jvsena42 Jul 31, 2026

Uh oh!

jvsena42 Jul 31, 2026

Uh oh!

jvsena42 Jul 31, 2026

Uh oh!

jvsena42 Jul 31, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

Uh oh!

Conversation

ben-kaufman commented Jul 22, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Description

Linked Issues/Tasks

Screenshot / Video

QA Notes

Manual Tests

Automated Checks

Uh oh!

greptile-apps Bot commented Jul 22, 2026

Greptile Summary

Confidence Score: 4/5

Security Review

Important Files Changed

Sequence Diagram

Uh oh!

Uh oh!

Uh oh!

Uh oh!

jvsena42 Jul 31, 2026

Choose a reason for hiding this comment

Uh oh!

jvsena42 Jul 31, 2026

Choose a reason for hiding this comment

Uh oh!

jvsena42 Jul 31, 2026

Choose a reason for hiding this comment

Uh oh!

jvsena42 Jul 31, 2026

Choose a reason for hiding this comment

Uh oh!

jvsena42 Jul 31, 2026

Choose a reason for hiding this comment

Uh oh!

jvsena42 Jul 31, 2026

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

ben-kaufman commented Jul 22, 2026 •

edited

Loading