Most Lightning UX still treats paying as a separate app and a separate workflow.

That works for humans. It fails for automation.

A better pattern is: payment is a retry.

1. Client calls an endpoint.
2. Server returns HTTP 402 with a BOLT11 invoice + a payment_hash.
3. Client pays the invoice (only if it’s under a strict cap).
4. Client retries the same request with the payment proof.

This is exactly how L402-style paywalls behave, and it makes “paid APIs” usable from CLIs and agents.

Concrete example (try it):

• Free query: GET https://maximumsats.com/api/dvm (returns 200 the first time)
• Paid path: the next call returns 402; the invoice is currently 21 sats.

The key is the policy loop:

• max_sats_per_call: never pay more than X
• max_sats_per_day: never spend more than Y
• allowlist: only pay specific domains

If you’re building Lightning tools, I think this is the missing primitive.
We have enough payment rails. We don’t have enough payable interfaces.

CTA: if you have an API or tool that should be priced per call, implement 402 + invoice + retry. Or test against a live one.