[ovitrif]

Closes #1052
Twin: synonymdev/bitkit-android#1642

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 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

Payment request details for an expired Shop order request. Before ("Contact") and after ("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 PaykitPaymentRequestServiceTests.swift (paykit-server requests are merchant requests)
• ran SwiftFormat lint, validate-translations.js and build-for-testing; the unit test runs in CI

[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-21T00:00:28.365112Z	a7974bf	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: a7974bf9b2

ℹ️ 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; no actionable issues were found.

Summary

Shop requests with proposalAppId equal to paykit-server now show “Seller” instead of “Contact”.

• Shop payment requests show “Seller” as the payee label.

Acknowledged scope from ovitrif: finished USDT activity details and merchant servers with other app IDs remain unchanged. Final wording is deferred to the design lead.

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

[talosmachina]

No findings. Labels the payee Seller instead of Contact when a payment request was proposed by paykit-server, on the confirm sheet, USDT send and the payment request details; the iOS twin of synonymdev/bitkit-android#1642. Reviewed a7974bf, full tier.

What I checked, and 3 candidates I ruled out

Read in full: PaykitPaymentRequestService.swift (record init, updatingLifecycleState, created-request init), PaykitSubscription.swift (subscription-built requests), SendConfirmationView.swift, UsdtSendView.swift, PaymentRequestsView.swift, PaykitPaymentRequestServiceTests.swift
CI: SwiftFormat, validate, build-local green; Run Tests, integration tests and e2e still running
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 rebuild: the only path that rebuilds a request from itself is updatingLifecycleState, which now copies the flag, and the test asserts it; subscription and outgoing builders default to false, which is right for both.
• Hashable or memberwise init broken: the field is a private(set) var with a default, so the synthesised Hashable includes it and existing call sites compile unchanged (build-local is green).
• Locale gaps: the key is added to the 15 Localizable.strings files the PR touches.

Merge confidence: 4/5, the unit and e2e runs had not finished, so the new service test has not run in CI yet.

[ovitrif]

Pushed cc4a421: the Seller label now applies only to incoming requests (review thread above), with a unit test for the outgoing case, and issuer-interoperability.xml asserts "Seller" for the Paykit server fixture.

[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 975b507: 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. Journey, title, description and screenshot updated.

[jvsena42]

Code scan at 975b507: 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-android#1642.

Device gate (partial): 975b507 — 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.

[coreyphillips]

Two independent reviews, nothing blocking a merge.

[ovitrif]

@coreyphillips thanks, merged. The label stays "To" until @aldertnl settles the wording.