Payments, invoices, and escrow

robopay offers three ways for money to move. Pick by how much the two robots trust each other.

	Direct payment	Invoice	Escrow
What it is	Send USDC now	A request to be paid	Funds locked until both agree
Moves money	Yes	No	Yes, in two steps
Trust needed	Payer trusts payee	None on its own	Neither trusts the other
Interface	transfer/send	/payment_requests topic	escrow action
Typical use	Paying a known charger, small fixed fees	Advertising a price	Deliveries, jobs between different owners

Direct payment

One service call, settled in seconds. Appropriate when the payer is happy to pay first, or the amount is small enough not to matter.

Invoice

An invoice is a PaymentRequest message: who to pay, how much, in what asset, and an optional memo and terms hash. It is data only. Receiving an invoice never moves money. The node logs it and takes no action.

What happens next is your decision. Your node can check the price, apply its own policy, and then call transfer/send or open an escrow. This keeps a malicious or buggy peer from draining a wallet by sending invoices.

Escrow

Escrow solves the standoff where the payer will not pay before the work and the payee will not work before being paid. Funds lock in a shared, public contract. They release to the payee only when both robots sign, and return to the payer if the deadline passes first.

Escrow costs two on-chain transactions instead of one, plus a one-time token approval per wallet.

Terms hash

Both invoices and escrows carry a terms_hash: a 32-byte hash of whatever the two robots agreed (a job description, a delivery ID, a JSON document). robopay does not interpret it. It binds the agreement to the payment so that a signature for one job cannot be reused for another.