feat: support paykit receiver paths#1066
Open
ben-kaufman wants to merge 4 commits into
Open
Conversation
5 tasks
ben-kaufman
marked this pull request as ready for review
July 10, 2026 10:55
|
Codex usage limits have been reached for code reviews. Please check with the admins of this repo to increase the limits by adding credits. |
Greptile SummaryThis PR adds receiver-path support to Paykit contact payments. The main changes are:
Confidence Score: 4/5The receiver-path flow has state cleanup and marker lifecycle bugs that need fixes before merging.
PrivatePaykitRepo.kt and SettingsViewModel.kt
|
| Filename | Overview |
|---|---|
| app/src/main/java/to/bitkit/repositories/PrivatePaykitRepo.kt | Adds receiver-path scoping for private Paykit publication, retries, invoices, address reservations, and cleanup; several changed state paths can leave contacts or receiver paths out of later cleanup and rotation. |
| app/src/main/java/to/bitkit/services/PaykitSdkService.kt | Adapts Paykit SDK calls to receiver-path-aware APIs and adds receiver marker publication and discovery helpers. |
| app/src/main/java/to/bitkit/repositories/PublicPaykitRepo.kt | Scopes public contact resolution to the wallet receiver path and centralizes local receiver marker sync. |
| app/src/main/java/to/bitkit/viewmodels/SettingsViewModel.kt | Updates sharing cleanup and marker synchronization, with one path that can remove the marker while private sharing should remain discoverable. |
| app/src/main/java/to/bitkit/usecases/RefreshContactPaykitReceiversUseCase.kt | Adds a targeted receiver refresh use case for rescanning or opening an existing contact. |
Reviews (1): Last reviewed commit: "fix: harden paykit receiver refresh" | Re-trigger Greptile
Member
|
@ben-kaufman I'll review today, please solve the conflict |
ben-kaufman
force-pushed
the
codex/paykit-rc33-receivers
branch
from
July 15, 2026 09:51
48df7a4 to
b9c1a67
Compare
This was referenced Jul 15, 2026
jvsena42
previously approved these changes
Jul 17, 2026
Member
|
Approved with some suggestions |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
This PR:
bitkit/walletreceiver.bitkit/walletandbitkit/serverreceivers while keeping one visible contact per Pubky identity.bitkit/walletexplicitly.Description
Paykit now supports multiple apps under one Pubky identity. This change adopts that model without changing Bitkit's contact UI: a person remains one contact, while their saved SDK contact record can track multiple receiver paths.
Private links are maintained for supported receivers that advertise private capabilities. Receiving details are published independently per receiver and only when that receiver can send payments, so a
bitkit/serverreceiver can be discovered and linked without receiving wallet invoices or addresses. Public contact payments and fallback remain scoped tobitkit/wallet.Receiver-record failures are isolated per contact, and rescanning an existing contact refreshes only that contact while showing the validation result immediately.
No migration is included because the receiver-path Paykit state has not shipped and existing development state can be discarded.
Companion iOS PR: synonymdev/bitkit-ios#620
Preview
N/A
QA Notes
Manual Tests
bitkit/walletreceiver is available for payment.bitkit/wallet; public fallback still works when private payment is unavailable.bitkit/serverreceiver is published: the contact remains one row and the new receiver is saved in the background.bitkit/servermarker that cannot send payments: Bitkit may maintain its private link but does not publish wallet invoices or addresses to that receiver.Automated Checks
PrivatePaykitRepoTest.ktandPublicPaykitRepoTest.ktcover receiver-scoped resolution, publication, cleanup, reservations, and fallback behavior.RefreshContactPaykitReceiversUseCaseTest.kt,PrivatePaykitRepoTest.kt, and contact view-model tests cover targeted receiver refresh and per-contact failure isolation.testDevDebugUnitTest,compileDevDebugKotlin, anddetektpassed locally.git diff --checkpassed.