A plain USDC transfer has no invoice ID. So almost every crypto invoicing product does the same thing:
- mint a keypair the platform controls
- take payment there
- sweep to the merchant
That works. It is also custody.
Duration does not change the test
If the platform can sign the deposit address, it can redirect, freeze, or go insolvent while funds sit there. Eleven seconds is not a de minimis. There is no \"briefly custodial\" exemption.
The three questions we use internally:
- Control: can the platform move the funds?
- Veto: can it stop the owner from moving them?
- Dependency: if the platform disappears tonight, are in-flight funds stranded?
Any single yes means custody exists in the path.
Why invoicing keeps producing this
Reconciliation needs unique addresses. The obvious unique address is a wallet you generated. Key management follows. Licensing and hot-wallet risk follow that.
MPC / threshold sweeps are better engineering. They still fail Control (you hold a shard) and often Dependency (the merchant cannot spend without you).
The other design
Bind the address to a destination the merchant already controls at issuance:
- Bitcoin: BIP-84 watch-only child from the merchant xpub. Next index per invoice. No seed on the platform.
- EVM: CREATE2. Merchant destination in init code. The address is the settlement path, not a forwarding inbox.
Then you watch the chain and fire a signed webhook. You do not hold a key that can move the payment.
I wrote the longer version, with the regulator citations, here: What is a true non-custodial crypto invoice platform?
I work on this at Settlematic — Collect is live, Gateway is sandbox. This is the architecture, not a GMV pitch.
Top comments (0)