Agentic payments

Give a software agent its own Lightning wallet with a Phoenixd node. An agent runtime such as OpenClaw can use the node to check its balance, create invoices, and pay invoices. Your application decides which actions the agent can take and how much it can spend.

Connect an agent to its wallet

Give the agent runtime the node's endpoint and restricted Phoenixd password to read balances, create invoices, and check incoming payments. The Phoenixd skill describes these operations for compatible agent runtimes.

Sending payments requires the full-access password. Keep that credential in a trusted service that checks spending rules before calling Phoenixd, rather than giving an unrestricted wallet to the agent.

Put a payment service between the agent and the node

Expose a small set of application tools, such as requesting an invoice, checking a payment, and proposing an outgoing payment. Keep the node password in the service that executes those tools.

An agent can request an action using a task identifier and invoice. Your service authenticates the caller, checks the request against policy, and calls Phoenixd only after approval. This lets you change spending rules without changing the agent's prompts.

Use a separate node for each agent or customer when you need separate payment histories and balances. Agents sharing a node need an application ledger to allocate funds and track spending.

Define spending rules

Before enabling outbound payments, decide:

• The maximum amount for one payment and the budget for a task or time period.
• Which services the agent may purchase from.
• Which requests require a person's approval.
• How routing fees count towards the budget.
• What happens when a payment fails or its outcome is uncertain.

Enforce these rules in backend code. A balance check alone does not impose a spending limit, and a prompt instruction is not an authorization boundary.

Execute a payment once

Record each proposed payment with a unique operation ID. Decode and validate the invoice, including its amount and expiry, before reserving budget and submitting it through Phoenixd's payment API.

Use an atomic budget reservation so concurrent agent tasks cannot each spend the same remaining allowance. Track pending, succeeded, and failed operations separately. Record the payment hash, actual amount, fees, and task reference for reconciliation.

If the request times out, investigate the payment's status before submitting another payment. A lost HTTP response does not establish that the Lightning payment failed.