Agent-First Pay v0.2: Settlement IDs Became Real
The v0.2 release made receive --wait flows return real on-chain transaction IDs and improved reproducible self-hosted payment deployments.
A payment connector should not invent the identifier an agent will later use for verification.
Agent-First Pay v0.2 focused on that boundary. When an agent waits for a payment to settle, the result should point to the actual network event, not a local placeholder.
The problem: synthetic wait IDs are not settlement proof
A local wait operation can produce a convenient ID: “wait completed”, “receive matched”, “payment observed”. That may be useful for logs, but it is not what an agent needs when it has to prove settlement to another system.
For on-chain payments, the durable reference is the chain transaction ID.
The change: receive –wait returns real chain IDs
The v0.2 release made EVM and Bitcoin receive --wait flows perform a
post-settle history sync so they can return actual transaction hashes.
That means an agent can take the result and verify it through the chain, a block explorer, another service, or a later history query. The result is tied to the network, not only to afpay’s local wait loop.
The deployment change: self-hosting became repeatable
The same release consolidated container deployment into Docker and Apple Container workflows with backup and restore scripts.
Payment tools often hold state: wallets, invoices, cursors, limits, and history. A reproducible deployment path matters because losing or splitting that state is not a small logging bug; it can affect money movement.
The test change: Lightning backend coverage improved
v0.2 also added an LNbits backend integration test suite against FakeWallet. That covered a provider path that was previously too easy to trust by assumption.
For an agent-facing payment connector, provider behavior needs tests because the agent will branch on the resulting events.
Where this fits: payment results need external meaning
Agent-First Pay is not trying to hide payment networks. It is trying to return network facts in a consistent shape.
v0.2 made that clearer: when settlement happens on-chain, give the agent the on-chain ID it can carry forward.