[ovitrif]

Closes #1625
Twin: synonymdev/bitkit-ios#1067

Description

• Shows the payee under "To" instead of "Contact" on payment requests a merchant sends, such as a Pubky Market order, so a Shop order no longer reads like a request from a personal contact. Personal requests keep "Contact".
• An incoming request counts as a merchant request when the Paykit server created it for the seller: its proposal app id is paykit-server, the id the deployed Paykit server stamps on the requests it prepares for the Shop. Requests created by a person's Bitkit carry bitkit and stay "Contact". Outgoing requests are unchanged.
• The label changes on the on-chain and Lightning confirm sheets, the USDT confirm sheet and the incoming payment request details.
• Reuses the existing wallet__send_to label ("To"), already translated in every locale, so no new copy.
• Wording: "To" is the interim choice; the final wording is the design lead's call.

Out of Scope

• USDT activity details: the finished transfer keeps "Contact", because the activity has no request to read the app id from; labelling it needs the flag stored with the payment.
• Requests from other merchants' Paykit servers with a different app id: they keep "Contact" until such a server exists.

Design

N/A — label copy only; wording pending design.

Preview

On-chain confirm sheet with details shown. Before: "Contact", as a Shop order reads before this PR and a personal request still reads. After: a Shop order request with this PR, "To".

Before	After

QA Notes

Journeys

• updated issuer-interoperability.xml (the Paykit server fixture request reads "To")
• request-summary.xml (unchanged; a Bitkit-to-Bitkit request still reads "Contact")

Manual Tests

N/A

Automated Checks

• updated PaykitPaymentRequestRepoTest.kt (paykit-server requests are merchant requests)
• updated SendConfirmScreenTest.kt (To for merchant requests, Contact otherwise)
• ran compileDevDebugKotlin, detekt, lintDevDebug, PaykitPaymentRequestRepoTest, and the new SendConfirmScreenTest case on an emulator

[chatgpt-codex-connector]

Codex Review Summary

This comment shows the latest Codex review activity on this pull request.

Review	Status	Commit	Review trigger
📝 Code Review	✅ Completed 2026-10-20T23:54:26.727385Z	292ed05	PR opened

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review" or "@codex security review".

Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings.

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 292ed05248

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[greptile-apps]

Confidence Score: 5/5

[Medium impact] The PR appears safe to merge.

Summary

Labels sellers as “Seller” on Shop payment requests while keeping “Contact” for personal requests.

• Shop payment requests label the payee as Seller.

_{Reviews (1) · Last reviewed commit: "feat: label the payee as seller on shop ..." · Reviewed by Greptile}

[github-actions]

Regtest APK

Built from 2ccec78 (run).

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

[talosmachina]

No findings. Labels the payee Seller instead of Contact when a payment request was proposed by paykit-server, on the on-chain, Lightning and USDT confirm sheets and the incoming request details. Reviewed 292ed05, full tier.

What I checked, and 4 candidates I ruled out

Read in full: PaykitPaymentRequestRepo.kt (record mapping), AppViewModel.kt (every resetSendState caller), SendConfirmScreen.kt, UsdtSendContent.kt, PaykitUsdtReview.kt, IncomingPaymentRequestDetailsScreen.kt
CI: lint, detekt, build, build-local green; e2e running, one shard (lnurl_transfer) failed in Create AVD and generate snapshot for caching, before the app was installed
Build: Bitkit track: the branch was not built here (Android branches are not built on this box, iOS does not build on Linux), so this review is reasoned from the code and from CI.

Ruled out

• Flag lost on a send-state reset: isMerchantPaymentRequest is set on both reset paths that carry an incoming request (the scan path and the retained hardware-payment path); the other callers (showInitialSubscriptionPaymentFailure, unresolved on-chain retry) are subscriptions or keep the existing state, and the label only renders for one-off requests (isOneOffPaymentRequest).
• Flag lost on a request copy: PaykitPaymentRequest is a data class, so copy() keeps it; outgoing requests built by toCreatedPaykitPaymentRequest are never shown with this label.
• Personal Bitkit request mislabelled: Bitkit stamps bitkit as the proposal app id, and the new repo test covers bitkit, paykit-server and an unrelated id.
• Every locale has the key: wallet__payment_request_seller is added to the 16 values*/strings.xml files the PR touches.

Merge confidence: 4/5, e2e is still running and the one red shard failed in emulator setup, not in a test of this change.

[ovitrif]

Pushed f0f57f6: the Seller label now applies only to incoming requests, so a merchant viewing their own outgoing request still sees the buyer as "Contact" (raised on the iOS twin). issuer-interoperability.xml now asserts "Seller" for the Paykit server fixture; request-summary.xml keeps "Contact" coverage.

[ovitrif]

@aldertnl this PR now shows the payee under "To" instead of "Contact" on payment requests from a Pubky Market seller (screenshots under Preview), reusing the existing send label; personal requests keep "Contact". The wording is your call: is "To" right, or would you prefer something else?

[ovitrif]

Pushed 2ccec78: the Shop payee label is now "To", reusing the existing wallet__send_to string instead of a new "Seller" key and its translations; still incoming-only. Test, journey, title, description and screenshots updated.

[jvsena42]

Code scan at 2ccec78: no issues found.

• Trust boundary: the "To" label is chosen from the request's app id, which the counterparty sets. It only switches the caption from "Contact" to "To". The avatar, name and key still come from the contact profile, and no counterparty text reaches the UI. The payee shown before paying doesn't change.
• Outgoing requests excluded.
• Coverage: every place that sets up a send for an incoming one-off request sets the flag. History and lifecycle copies keep it.
• No new strings. The interim "Seller" key is gone.
• Journey: issuer-interoperability.xml updated. request-summary.xml still covers "Contact".
• Design: Figma frames: Send (Paste) (On-chain) › Confirm Send Onchain, and Subscriptions › Payment Request Details. The wording is waiting on design.
• Parity: same rule and the same four screens as synonymdev/bitkit-ios#1067.

Device gate (partial): 2ccec78 — not run yet. Pending: issuer-interoperability.xml (shop request shows "To") and request-summary.xml (contact request shows "Contact"), on on-chain, Lightning and USDT confirm and on request details.

Device results will follow in a separate review.