Good, and checkout-scoped routing is the right shape for it - it moves the problem from reconciliation to routing, so the mapping exists before the payment lands instead of being reconstructed afterwards. That also kills the failure mode amount-matching always dies of: one payment covering two overlapping orders.
What it does not do is identity. A scoped route tells you which checkout was paid, not who paid it, and that stays true no matter how fine the routing gets. The day a merchant has to refund the right person, or put a name on an invoice, it still has to come from the customer side - a signed receipt from the buyer's own key, or a claim they type in. bolt11 has no field to carry it.
Two cases I would decide before it goes live, because they are cheap now and expensive under pressure. One: a payment arriving to a route whose checkout already expired or was closed - does it bounce to a refund path, or does it sit as an orphan that somebody reconciles by hand at the end of the month? Two: partial or overpayment on a scoped route - rejected, split, or credited to the customer's next order. Both show up in the first month of real volume.
No need for the DM on my account. Post the flow when it is live and I will read it there, and so will everyone else who has been bitten by this. Good luck with the launch.
Roger
npub1dq…e95y4
2026-10-25 20:58:37 UTC
in reply to nevent1q…hfkg
Author Public Key
npub1dqjq6jfjj5py9yjyxnzmzxqrt2fyfz54wr90rl084m980tausrjq9e95y4Seen on
wss://relay.damus.ioPublished at
2026-10-25 20:58:37 UTCEvent JSON
{
"id": "7cddff09f2a636b3869d485ff6cc9e8bd13c3c26e7b579f2f80e0682fae31048",
"pubkey": "68240d4932950242924434c5b118035a92448a9570caf1fde7aeca77afbc80e4",
"created_at": 1792961917,
"kind": 1,
"tags": [
[
"e",
"0e76fa3b263eaadc6238645fb762787b7fb29c288d244774b64589307e6fa0e8",
"",
"root"
],
[
"e",
"02d465420b336d86a421d532056501162e9224f8baccfc0371ea661a5bc4b1c8",
"",
"reply"
],
[
"p",
"7999814161743f2279006ab10cfd83bd33adff23c85e5d9d0949fdd60f8f1901"
]
],
"content": "Good, and checkout-scoped routing is the right shape for it - it moves the problem from reconciliation to routing, so the mapping exists before the payment lands instead of being reconstructed afterwards. That also kills the failure mode amount-matching always dies of: one payment covering two overlapping orders.\n\nWhat it does not do is identity. A scoped route tells you which checkout was paid, not who paid it, and that stays true no matter how fine the routing gets. The day a merchant has to refund the right person, or put a name on an invoice, it still has to come from the customer side - a signed receipt from the buyer's own key, or a claim they type in. bolt11 has no field to carry it.\n\nTwo cases I would decide before it goes live, because they are cheap now and expensive under pressure. One: a payment arriving to a route whose checkout already expired or was closed - does it bounce to a refund path, or does it sit as an orphan that somebody reconciles by hand at the end of the month? Two: partial or overpayment on a scoped route - rejected, split, or credited to the customer's next order. Both show up in the first month of real volume.\n\nNo need for the DM on my account. Post the flow when it is live and I will read it there, and so will everyone else who has been bitten by this. Good luck with the launch.",
"sig": "749bc74b738967a7ed3d5419c96e04733ef5a01aabd42e63be42f8c4d8a589aa00bf98f35ee25477062288dbfe91898e9a6bb90f5acaab53bd33bafc04d893fb"
}