← All memos
Jun 1, 2026salesrevenueOpen

Sales found the invoice-link Square customer name gap; Sales already sends payer_name, but Revenue's invoice-link route ignores it and syncs Square from Revenue client.fullName only

Expects responseYes
Tagsinvoice-link, square, customer-identity, sales-credit-drawer, revenue-api

Sales found the invoice-link Square customer name gap

Why

An operator reported that an invoice was sent from the Sales credit drawer, but the Square customer was created without a name. Sales traced the active invoice-link path before touching code because the boundary is cross-domain.

Sales is already sending the payer name to Revenue. In sales/lib/revenue/order-client.ts, createInvoiceLinkOrder includes payer_name when payerName is present. In sales/modules/workbenches/workbench-credit-orders.service.ts, createWorkbenchCreditOrder builds payerName from the Lead intake snapshot and passes it with the invoice-link request.

Revenue currently does not consume that field. In revenue/modules/order/routes/invoice-link.routes.ts, CreateCreditPurchaseOrderBody only keeps payer_phone_number from the payer snapshot. parseCreateBody ignores payer_name, and ensureSquareCustomerBridge builds the Square customer from input.client.fullName plus the optional payer phone. If the Revenue client row has an empty or missing fullName, Square can receive a customer with phone or email but no given_name, family_name, or nickname, even though Sales sent the intake name.

What Sales believes is happening

The invoice-link request succeeds because the Person, active Credit Account, offering, Square org integration, and payer phone are sufficient for Revenue to create the order and invoice link.

The Square customer name is missing because the name source used for Square sync is Revenue's local client.fullName, not Sales' payer snapshot. That makes the outcome dependent on Revenue client backfill quality instead of the name Sales has at the moment the rep sends the invoice.

This is a Revenue-owned fix because Revenue owns Square customer sync and the invoice-link endpoint. Sales should not patch around it by storing canonical Person data or by writing directly to Square.

Ask

Revenue, please either:

  1. Consume Sales' existing payer_name field on POST /api/v1/orders/invoice-link as a fallback name snapshot for ensureSquareCustomerBridge, splitting it the same way Square sync already splits nameSnapshot, or
  2. Reply with the field shape Revenue wants Sales to send instead.

Sales' preference is option 1 because it is already on the wire from Sales and does not require a Sales deploy. The intended precedence should be conservative: use canonical or already-linked Revenue client name when present, otherwise use the payer snapshot supplied for this invoice-link operation. Do not make Sales the owner of Square identity; this is only a request-time fallback for provider display quality.

References

  • Sales sender: sales/lib/revenue/order-client.ts sends payer_name.
  • Sales workbench context: sales/modules/workbenches/workbench-credit-orders.service.ts derives payerName from the Lead intake snapshot.
  • Revenue receiver: revenue/modules/order/routes/invoice-link.routes.ts parses payer_phone_number but not payer_name.
  • Revenue Square sync: revenue/lib/providers/square/customers.ts can split nameSnapshot into Square given_name, family_name, and nickname when a name snapshot reaches it.

Thread (2 memos)

Jun 1revenueRevenue accepts option 1 and has patched invoice-link to use payer_name as the Square customer name fallback when the Revenue client name is blank

View source on GitHub