Optionalnotifier?: EscrowTransferRequestNotifierOptional SMS notifier. When wired, create / accept / reject / cancel each fire a best-effort customer-branded SMS to the counterparty. Omitted by read-only and test callers — notifications then no-op.
Record that the recipient accepted the request and was paid: link the
fulfilling escrow transfer id and move the request to SENT. Only valid
from CREATED, so a second accept (even with a different escrow transfer
id) is rejected rather than silently re-linking. An escrow transfer id
already linked to a different request trips the unique constraint and
surfaces as ESCROW_TRANSFER_ALREADY_LINKED.
Mark the request CANCELLED (the sender withdrew it). Only valid from
CREATED — a fulfilled (SENT) or already-terminal request cannot be
cancelled.
Create a request for payment. Self-send (requesting from your own phone) is
rejected. The recipient is addressed by phone and may not be a known
identity, so recipientIdentityId is left null.
senderId is resolved to its int identity FK via the identityInternalId
subquery, scoped to the customer — an unknown or cross-customer sender id
yields NULL and trips the NOT NULL sender_identity_id FK.
Look up a single request by id, scoped to the calling customer. Returns
null for both "missing" and "owned by a different customer" — never
leaks existence of another customer's row. Controllers map null to 404.
Mark the request REJECTED (the recipient declined it). Only valid from
CREATED.
Customer-scoped search. Filter by senderId (requests this identity sent)
and/or recipientPhone (requests addressed to this phone) and/or
statuses. Ordered newest-first. The customer-scope is a hard WHERE so no
filter combination can leak rows across tenants.
Optionalpage?: numberDefaults to 1
OptionalpageSize?: numberDefaults to 50
OptionalrecipientPhone?: stringOptionalsenderId?: stringOptionalstatuses?: ("CREATED" | "REJECTED" | "CANCELLED" | "SENT")[]
Customer-scoped escrow transfer request operations. A request is a payment ask that precedes an
escrow_transfer; this service is pure customer-scoped CRUD with no on-chain machinery (contrast EscrowTransferService, whose writes run through Temporal/Solana).Every read and write filters on
customerId(the API caller's customer external id resolved fromrequest.customerId) so one customer can never read or mutate another's requests. Per-actor authorization (only the sender may cancel, only the recipient may reject) is the caller's responsibility — the API has no notion of the acting end user.