What Is a True Non-Custodial Crypto Invoice Platform? (And Why Almost None of Them Are)

Ask ten crypto payment vendors whether they're non-custodial and ten will say yes. Ask them what happens in the eleven seconds between the customer's transaction confirming and the merchant's wallet receiving it, and the answers get vague fast.

That gap is where the whole argument lives. Not in the marketing page. Not in the private key policy. In the gap.

We built Settlematic because we went looking for a non custodial crypto invoice platform that could survive that question, couldn't find one, and eventually worked out why: the honest version isn't a feature you bolt on. It's a constraint you design the entire settlement path around, before you write a line of code. This post is the reasoning, not the pitch.

Everything below is the long version of that short answer.

"We never store your private keys" is answering a question nobody regulated

The industry has convinced itself that custody is a storage question. Do you have the keys, yes or no. It's a comfortable framing because it's easy to pass.

Regulators didn't write it that way.

MiCA defines the regulated service — providing custody and administration of crypto-assets on behalf of clients — as safekeeping or controlling client crypto-assets, or the means of accessing them, where relevant in the form of private keys. Read the conjunction carefully. Safekeeping or controlling. Keys are named as one form the means of access might take, introduced with "where applicable" — an example, not the definition.

New York's BitLicense rule lists, among the activities requiring a licence, storing, holding, or maintaining custody or control of virtual currency on behalf of others. Control again, sitting on equal footing with holding. And NYDFS has kept sharpening this: the January 2023 custody guidance was replaced effective immediately by updated guidance issued on 30 September 2025, which continues to stress that equitable and beneficial interest must always remain with the customer. Note always. Not "on average." Not "except for a thirty-second forwarding window."

The DFS FAQ makes the boundary unusually concrete for anyone building payment software: writing software that lets customers self-custody virtual currency would not by itself require a licence, but running a wallet service where you keep custody of other people's funds likely would. Same code, different architecture, different regulatory universe.

FinCEN is the one that should end the debate. Its 2019 consolidated CVC guidance assesses intermediaries on four factors: who owns the value, where it's stored, whether the owner interacts with the payment system directly, and whether the intermediary has "total independent control" over the value. And it applies that test with teeth — a multi-signature wallet provider becomes a money transmitter where value sits as an entry in the provider's accounts, the owner doesn't interact with the payment system directly, or the provider holds total independent control. That's an or list. Fail any one and you're in.

Three regulators, three drafting styles, one shared instinct: custody is about control, not possession. You can hold nothing and still be a custodian. You can hold a key and, structurally, not be one.

The three-question custody test

We use this internally when reviewing any settlement design, ours included. Any single yes means custody exists somewhere in the path.

Dependency is the one that catches everybody. It's easy to design a system where nobody can steal the money and still end up with one where nobody can retrieve it if you go under. If the only record of which address belongs to which invoice lives in a database you control, and that database is the difference between funds being spendable and funds being lost, then your merchants are exposed to your uptime, your solvency, and your legal jurisdiction. That's a dependency. It's also, quietly, most of the market.

Why crypto invoicing keeps producing custody by accident

Nobody sets out to become a custodian. It happens because of a mundane operational requirement: reconciliation.

If you're issuing invoices, you need to know which incoming payment settles which invoice. On-chain there's no memo field you can rely on across wallets, exchanges and chains. So you need one unique address per invoice.

And the obvious way to get a unique address per invoice is to generate a fresh wallet you control, take the payment there, and forward it on.

That's the whole story. A reconciliation requirement turns into an address-generation requirement, which turns into key management, which turns into custody, which turns into licensing exposure, hot-wallet risk, insurance questions, and a trust assumption that has no business existing in what is fundamentally an invoicing tool.

What the industry has tried, and where each approach gives out

We went through all of these before landing where we did. Every one of them is a reasonable idea. Every one of them breaks somewhere specific.

Amount disambiguation. Bill $8,300.01 and $8,300.02 so the amounts identify the invoice. Elegant, zero infrastructure, no custody. Dies the moment a customer rounds to $8,300, overpays, underpays, or their exchange skims a withdrawal fee off the top. Also unusable at any volume, because your disambiguation space collides with itself.

Direct-to-merchant-wallet with automatic reconciliation. Genuinely non-custodial. Works beautifully right up until a merchant has two open invoices for the same amount from two first-time payers, at which point a human sorts it out in a spreadsheet. It's not wrong, it just doesn't scale past a certain invoice density, and merchants discover the ceiling at the worst possible moment.

Customer-called smart contract payment functions. The customer invokes a contract that tags the payment with an invoice reference. Clean in theory. In practice it excludes anyone paying from a centralised exchange — which is a very large share of real B2B crypto payments — because exchange withdrawal flows send plain transfers and cannot sign arbitrary contract calls. Chain support is uneven too. You've built something that works for crypto-natives and fails for your merchant's actual customers.

Temporary wallet plus automatic sweep. The industry default. Generate a fresh keypair per invoice, monitor it, sweep to the merchant on confirmation. Solves reconciliation perfectly. It is also, unambiguously, custody — more on this below.

MPC or threshold-signature sweeping. The sophisticated version: no single party holds a complete key, shards are distributed, sweeps require a threshold. Real security improvement over a hot wallet, and we respect the engineering. But run the three questions. The platform holds a shard, so it participates in every movement of funds. Depending on the threshold scheme it may be able to refuse to participate. And merchants now have an operational burden — co-signing, approving, maintaining a shard — that they did not have with a plain wallet address. Better custody is still custody.

The thirty-second window is not a rounding error

Here's where we'll be blunt, because vendors keep hoping this one slides.

If your platform generates a keypair, funds land at that address, and your infrastructure signs the transaction that moves them to the merchant, you held someone else's money. The duration is irrelevant. There is no regulatory de minimis for "briefly." A custodian who holds funds for eleven seconds is a custodian who holds funds.

And it's not a paperwork problem. It's a real one. During that window:

• A compromise of your signing infrastructure redirects live funds, not future ones.
• A court order, a sanctions listing, or an overzealous internal process can freeze money mid-flight.
• Your insolvency puts in-flight merchant funds into the bankruptcy estate — precisely the scenario NYDFS's insolvency guidance exists to address.
• The merchant's money is, for that window, indistinguishable from your money on-chain.

The temp-wallet model doesn't remove trust. It compresses it, then labels the compressed version as absence. Those aren't the same thing, and merchants who've read a FinCEN factor test can tell.

Why this is an architecture problem, not an engineering problem

You cannot refactor your way out of custody. That's the part that takes teams a while to accept.

If your settlement path has a step where funds sit somewhere your infrastructure controls, no amount of HSM hardening, key rotation, MPC ceremony, SOC 2 evidence or insurance changes the answer to question one. Can the platform move the funds? Yes. Better locks on a door you can open is still a door you can open.

The only way out is to make the answer structurally impossible rather than procedurally discouraged. Which means the destination of every invoice payment has to be fixed — not policy-fixed, not database-fixed, cryptographically fixed — at the moment the address is issued, before any money exists to protect. Then the security question stops being "can we be trusted with funds in transit" and becomes "was the address correct when we issued it," which is a completely different and much more tractable problem.

That reframing is the entire design. Everything else is consequence.

It also inverts where you spend your security budget. In a custodial model, the danger zone is the whole lifecycle — every second funds are in your control. In a properly structured non custodial crypto invoice platform, the danger zone is one moment: address issuance. Get that moment right and the rest of the timeline is mathematically uninteresting. So you pour everything into that moment — out-of-band, time-delayed payout changes with the old destination staying live during the delay, append-only hash-chained audit logs anchored externally, signed invoice payloads, and verification tooling served from an origin the platform doesn't control, because JavaScript we serve cannot meaningfully defend against a compromise of us.

That last point is one we'd encourage every merchant to press vendors on. Verification performed by the party being verified isn't verification. See our security architecture and developer verification docs for how we expose independent checks — and the how it works page for the supported assets and networks in production today.

The claims a true non-custodial platform should be willing to put in writing

Not "we take security seriously." Specific, falsifiable statements. These are the ones we hold Settlematic to:

• We never hold the merchant's private key.
• We hold no key, key shard, or secret value capable of controlling, holding, or directing funds anywhere in the payment path.
• We hold nothing whose loss, corruption, or withholding could make merchant funds unreachable.
• Customers can pay by QR, copied address, wallet connect, or straight from an exchange — no contract calls required.
• If Settlematic vanished tomorrow, every merchant could complete settlement unilaterally, using only records they already hold plus public information.

And two more that apply from the instant an invoice address is issued:

• Funds sent to an issued address cannot be redirected by anyone — not us, not an employee, not an attacker in total control of our infrastructure.
• Even fully compromised, we cannot hold issued-invoice funds hostage or delay settlement.

Claim 5 and claim 7 are the ones that hurt to commit to, and they're the ones that matter. Claim 5 is the dependency test. Claim 7 is the veto test. Any vendor can pass the control test by talking about key storage; almost none will sign their name to the other two.

What to actually ask a vendor

Skip the marketing page. Six questions, in this order:

• Between confirmation and my wallet, does any address exist that your systems can sign for? (Control.)
• Can any employee, process, or court order stop a confirmed payment from reaching me? (Veto.)
• If you shut down tonight with no warning, what exactly do I need to recover funds — and do I already have all of it? (Dependency.)
• Can I independently verify that a payment address belongs to me, without trusting your API? Show me the tool.
• Can I compute the same answer from a public source that isn't yours?
• What's your process for changing a payout destination, and how long does the old one stay live?

If question 3 gets answered with "we'd help you migrate," you have your answer. Migration assistance is a support policy. Support policies do not survive insolvency.

Where Settlematic sits

We're a non custodial crypto invoice platform in the strict sense of all seven claims above. Every invoice still gets its own address, so reconciliation is automatic and exact. But the address is bound to the merchant's own wallet before it's ever shown to a customer, and the binding is cryptographic rather than administrative — there is no configuration change, database edit, insider action, or full infrastructure compromise that redirects a payment to an issued address.

We never generate a temporary wallet, because there is no temporary wallet in the design. There is no sweep we can refuse to perform, no approval we can withhold, and no step in the settlement path that only we can execute. Merchants can verify any invoice address against an independent public source and against open tooling that takes no secret input from us. Currently live across BTC, ETH, USDC and USDT on Ethereum, Polygon and BSC, MATIC, TRX and TRC-20 stablecoins, and SOL.

We'd rather be judged on the three questions than on an adjective. Run them on us. Then run them on whoever you're using now.

Explore Settlematic

Ready to try the workflow in your own workspace? Start on testnet, then explore our how it works guide and product features.

• Merchant sweeps
• Conversion flows