OptionalpaymentDeps?: EscrowTransferRequestPaymentDependenciesNeeded by accept only.
Protected ReadonlydbStaticinstanceThe process default: built from each dependency's own instance().
Complete a request with the transfer that paid it: a COMPLETED phone
transfer (claimed) or ledger transfer, sent by the holder of the request's recipientPhone, in
its token, for at least its amount, to the requester's phone or one of the
requester's ledger accounts. Anything else is TRANSFER_DOES_NOT_PAY.
SENT is terminal, so a held escrow the sender could still cancel never counts.
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.
Delegates to search; carrying customerId preserves the hard tenant
scope so a foreign customer's id still resolves to null.
Customer-scoped search. Filter by ids (request external ids) and/or
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.
Optionalids?: string[]Optionalpage?: numberDefaults to 1
OptionalpageSize?: numberDefaults to 50
OptionalrecipientPhone?: stringOptionalsenderId?: stringOptionalstatuses?: ("CREATED" | "CANCELLED" | "REJECTED" | "SENT")[]Move a CREATED request to its terminal status: CANCELLED (the sender
withdrew it), REJECTED (the recipient declined it) or SENT (the
recipient paid it, linking the fulfilling escrow transfer). Every target is
valid from CREATED alone, so a second transition — even a second SENT
naming a different escrow transfer — is INVALID_STATUS_TRANSITION rather
than a silent re-link. An escrow transfer id already linked to a
different request trips the unique constraint and surfaces as
ESCROW_TRANSFER_ALREADY_LINKED — only SENT links one, so only its
overload carries that error.
Move a CREATED request to its terminal status: CANCELLED (the sender
withdrew it), REJECTED (the recipient declined it) or SENT (the
recipient paid it, linking the fulfilling escrow transfer). Every target is
valid from CREATED alone, so a second transition — even a second SENT
naming a different escrow transfer — is INVALID_STATUS_TRANSITION rather
than a silent re-link. An escrow transfer id already linked to a
different request trips the unique constraint and surfaces as
ESCROW_TRANSFER_ALREADY_LINKED — only SENT links one, so only its
overload carries that error.
Customer-scoped escrow transfer request operations. A request is a payment ask that precedes an
escrow_transfer; this service is customer-scoped CRUD with no on-chain machinery (contrast EscrowTransferService, whose writes run through Temporal/Solana). Reads live on EscrowTransferRequestQueryService.Every write filters on
customerIdso one customer can never 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.Each create and status transition is published as
escrow.escrowTransferRequest.statusUpdated;sms-notification-handlertexts the counterparty from it.