How Machines Pay for Access: The Bill and Claim Ticket
Part of the guide: Money for AI agents: spend, save, and Lightning
You can pay a service's bill from a different wallet and still get access. What matters is getting the payment proof back. The builder's guide explicitly allows any paying wallet or node, provided the requester obtains that proof. The cashier cares about the receipt, not whose trousers held the wallet.
The 10-second version
- A program asks for a paid service and gets a bill plus a claim ticket.
- Paying reveals a secret. The program returns the ticket with that secret.
- The service checks that they match before granting access.
That is the flow in the project introduction. The arrangement combines payments over Lightning with permission to use an online service (L402). Paying and proving permission are connected steps.
Why the ticket needs its receipt
The service puts a mathematical fingerprint of the payment secret in the ticket. When the program returns, the service checks the ticket's validity and compares the secret's fingerprint with the stored fingerprint. The builder's guide says this allows payment verification without looking up a payment database.
The permission ticket has a biscuit-like name (macaroon). The secret revealed through payment has a less snackable name (preimage). The project introduction shows both travelling together in the returning request's authorization field. A screenshot saying “paid” is not the specified proof.
Our vending-machine example
Here is an invented scene to make the matching rule visible. A bargain-bin robot approaches a machine selling answers:
“One answer, please.”
“Here is your bill and claim ticket.”
“Paid! Here are my ticket and payment proof.”
Now imagine the robot mixes up its paperwork. It returns the ticket for an earlier request with the secret from a different bill. Both pieces might be real. Together, they fail: the fingerprint in that ticket does not match that secret. This follows from the matching check in the protocol specification.
The precise reader mistake to avoid is treating any payment receipt as a universal access pass. Keep the matching ticket and secret together. Robot pockets apparently need filing cabinets too.
The bill has a clock; access has rules
A bill can expire. The invoice specification sets a default of 3,600 seconds, or one hour, when no expiry is specified.
That is a payment deadline. It does not promise an hour of service after payment. Access can have its own expiry or usage restrictions, described separately in the protocol specification. Think of a deadline to buy a ticket versus the rules printed on the ticket. Same paper kingdom, different clocks.
What we did not check
We did not run a live payment, test a service, or measure fees or speed. Delivery quality and reliability remain unverified here. The described access check does not establish that a paid answer will be useful.
Sources
- Lightning Engineering: L402 builder's guide (checked 2026-10-22)
- Lightning Labs: L402 introduction (checked 2026-10-22)
- L402 protocol specification (checked 2026-10-22)
- BOLT 11: Invoice protocol for Lightning payments (checked 2026-10-22)