Transactions list DX: show counterparty name, transaction type, and resolved token symbol (and persist counterpartyId on direct transfers)

[resourcefulmind]

Area: Payments / transactions list (Payments → Overview) + transfers API ·

The transactions list is the reconciliation surface, but a row is hard to read at a glance and one field isn't persisted at all. Four related gaps on the same surface:

1. Counterparty shows a wallet address, not a name, and for direct payments it isn't recorded

The "Counterparty" column renders transfer.destination / transfer.source (a raw wallet address, truncated, monospace) and ignores the counterpartyId the row already carries. So:

• A ramp transfer that has counterpartyId (e.g. an off-ramp to a saved individual) shows the address, or "Unavailable" when destination is null, despite the id being present on GET /v1/payments/transfers/{id}.
• A direct/Pay transfer never persists the counterparty at all: the dashboard createTransfer sends only {source, destination, token, amount, memo}, so counterpartyId is saved as null even when the user explicitly selected the payee. The link to who was paid is lost at write time. (This is the one data bug in this issue, not just display.)

2. No transaction Type in the row

The table shows a Direction column ("Inbound"/"Outbound") but no transaction Type. A plain transfer and an offramp both read "Outbound"; an onramp and an inbound transfer both read "Inbound", indistinguishable at a glance. A label helper (RAMP_TYPE_LABELS) already exists but isn't wired into the row.

3. Token is a raw mint for direct transfers (API side of the already-fixed UI issue)

In GET /v1/payments/transfers, token is a symbol for ramp rows (USDC) but the raw mint for direct transfers (4zMMC9…, the devnet USDC mint, which isn't in the SDK's well-known-token map). The dashboard was fixed to map the mint for display, but the API still returns the raw mint, so any other consumer inherits the inconsistency.

Reproduce

curl "$BASE/v1/payments/transfers?category=ramp"   -H "Authorization: Bearer $KEY"
#   token "USDC", counterpartyId present on detail
curl "$BASE/v1/payments/transfers?category=wallet" -H "Authorization: Bearer $KEY"
#   token "4zMMC9…" (raw mint), counterpartyId null even for a Pay to a selected counterparty

Then open Payments → Overview: rows show an address (or "Unavailable") under Counterparty, "Outbound"/"Inbound" with no type, and (for direct transfers via the API) the raw mint.

Impact: the reconciliation surface is hard to scan and, for direct payments, can't answer "who did we pay" at all because the counterparty was never stored.

Suggested fix

• Persist counterpartyId on direct/Pay transfers (include it in createTransfer).
• Resolve counterpartyId to a display name in the Counterparty column; keep the address on hover (the table already uses truncate + tooltip for signatures).
• Add a Type column or badge using the existing RAMP_TYPE_LABELS.
• Represent token consistently across transfer types in the API (resolve the symbol server-side, including devnet mints), or add a resolved-symbol field alongside the mint.

[resourcefulmind]

Re-verified against current main (ef573405) plus a live query of 20 production transfers. Correcting an earlier assumption of mine: most of this is still open. Only one of the four items has shipped.

Live data, grouped:

 7 offramp  | counterpartyId=set   displayName="Amara N. Okafor"  token=USDC
 6 onramp   | counterpartyId=set   displayName="Amara N. Okafor"  token=USDC
 3 transfer | counterpartyId=null  displayName=null               token=4zMMC9srt5Ri…
 3 transfer | counterpartyId=null  displayName=null               token=DTMXripBh93T…
 1 batch    | counterpartyId=null  displayName=null               token=4zMMC9srt5Ri…

Shipped, striking both: the Type column now renders on Payments → Overview as "Outbound · Transfer", "Inbound · Deposit", "Outbound · Payout" (payments-command-center.tsx:303, with compactType at :215). And counterpartyDisplayName resolves, which is why the ramp rows show "Amara N. Okafor".

Still open, and broader than I filed it. The counterparty is never persisted on a direct transfer, which is why those same rows still show a raw address. The root cause isn't the dashboard omitting it: createTransferSchema accepts only projectId, source, destination, token, amount, memo, privateTransfer. There is no counterpartyId field on the request at all, so no API consumer can record a payee even if they want to. The fix needs the schema change, not just the persist.

Also still open: the API returns a symbol for ramp rows and a raw mint for direct transfers, so any consumer other than the dashboard inherits the inconsistency.

Re-scoping to those two. The schema/persist one is worth doing first.