Crypto invoices fail reconciliation for a boring reason: a USDC transfer does not carry an invoice ID. The usual fix is a unique deposit address. The usual implementation of that unique address is a keypair the platform generated.
That last step is the product. It is also custody.
What “invoice-scoped” actually means
The address exists because of this invoice. Payment to it maps 1:1. You do not scan a shared wallet and guess which memo belongs to which bill.
That does not require you to mint a key. It requires a derivation from something the merchant already controls.
Bitcoin: BIP-84 watch-only
Merchant xpub. Account 0. Next unused index per invoice. Platform stores the xpub and the index — never the seed. Address is a native SegWit child. Merchant spends with their own wallet. If we disappear, the xpub still works in Electrum.
EVM: CREATE2
address = keccak256(0xff ++ factory ++ salt ++ keccak256(initCode))[12:]
Put the merchant destination in init code. Salt is the invoice id (or a hash of it). The address is determined before any contract is deployed. First payment can still land. Settlement path is the merchant wallet, not a forwarding inbox we control.
What this is not
- Not a platform hot wallet with a label.
- Not “we hold the key for 30 seconds then sweep.”
- Not an MPC shard that still fails the Control test.
Longer write-up: Invoice-scoped wallet addresses, explained.
I work on this at Settlematic. Collect is live. Gateway is sandbox. This is the architecture, not a GMV pitch.
Top comments (0)