Most ways for a business to take crypto ask it to make a choice it should not have to make. It can use a payment company, which holds the balance and pays it out later. Or it can hold its own keys and do the work itself: one address for each order, coins scattered over many of them, and network fees to gather them up.
Orrerie Merchant is our attempt at a third way. Orrerie never holds the business's money, and once a payment has arrived it is in a wallet Orrerie cannot move alone. The work of receiving it is done for the business. This article says what we built, how it works, and where it is weaker than we would like. We have tried to write the last part as plainly as the first.
A wallet that needs two of three keys
A business signs up in a browser with an email address and a passkey, and makes its recovery key in its own Orrerie app on its phone; signing up costs nothing. One approval makes a wallet on each of eleven networks: Ethereum, BNB Smart Chain, Polygon, Arbitrum, Optimism, Base, Solana, TRON, Bitcoin, Litecoin and Dogecoin.
Every one of those wallets needs two of three keys. The first is a key in the merchant's browser, locked by its passkey; where a passkey cannot lock a key, the merchant chooses a wallet password instead. The second is a recovery key the merchant's Orrerie app makes and keeps on its phone. The third is on Orrerie's server.
We hold one key of three. So we can never move a merchant's money alone, and we cannot stop a merchant from moving it either: with its browser key backup and its Orrerie app's backup words a merchant can move everything in its wallets with a recovery tool it downloads, without us. One exception: money that reaches an old Bitcoin, Litecoin or Dogecoin address after a change of keys moves only with our co-signer, from the dashboard. That is why the merchant saves the backup and picks it again so we know it was really saved, and its Orrerie app confirms the recovery key it made, before its first real payment. Until both exist, "Orrerie cannot freeze your money" would not be true, and we did not want to say it before it was.

Being paid without gas money
The hard part of holding your own keys as a shop is receiving. Our answer is a routing service called Relay, a separate company.
A customer who uses the Orrerie app taps Pay with Orrerie: the app opens with the order filled in. Any other customer pays from any wallet by QR code and address, choosing the coin and the network. By default that customer is shown an address made for that one order, and Relay takes the coin the customer sent, converts it on the way, and delivers into the merchant's own wallet in the coin the merchant chose to keep, normally USDC on Base.
So a payment that Relay routes leaves the merchant nothing to collect from per-order addresses, and the merchant needs no gas money to be paid. By default the routing and network cost of a converted payment is shown to the payer in the checkout as its own line; a merchant can choose to absorb it instead.

There are two places where this has a limit, and they are on the pricing page too. Sending money out needs a little of the network's own coin on eight networks. On the network the takings are kept on, that coin is taken automatically from the merchant's small sales (US$1 to US$5, or up to US$10 on Ethereum); to send from any other network, from Polygon or TRON, or with only larger sales, the merchant sends a few dollars of that network's coin once. And the Solana and TRON wallets are shown as "Not activated", with no address, until the merchant switches them on (Solana for a fraction of a US dollar, TRON for 100 TRX plus about 1 TRX).
One checkout, many ways in
A merchant can take a payment by payment link, by invoice with a PDF, on a keypad page at a counter, by subscription, with a button on its website, through a WooCommerce plug-in, or from its own software through an API. All of them lead to the same checkout page.
Around that there is what a business needs to run: customers and receipts, exports for the accountant, a ledger, sales figures, seven staff roles, and a test mode with simulated payments. A merchant sees its balances on all eleven networks, withdraws to its own addresses, pays suppliers and staff, shares a sale with a partner, refunds, and changes one coin into another. Every one of those movements is approved by the merchant with a passkey. We cannot approve one.
For developers the public API is ordinary JSON over HTTPS with an API key and idempotency keys: 126 operations, and 115 webhook event types signed with HMAC-SHA-256. The documentation starts at merchant.orrerie.com/docs.
It never pretends
An order is Paid only when the merchant's own wallet shows the money on the network. Never because Relay said so, and never because our server said so. When something cannot be done, the page says exactly why and what still works. It never quietly switches to another way of doing it.
Rules that hold against a stolen session, or a break-in of one part
A newly saved address waits 24 hours before it can be paid, and every owner is emailed when it is added. A refund goes to the address the customer gives through a claim link tied to the order; a refund to an address someone typed waits 24 hours as a new saved address. A change of keys that the recovery key does not sign waits 72 hours (a new browser key) or 7 days (a new recovery key), with emails to every owner and a way to cancel. These rules are kept by our co-signing server, not by the page in the browser, so a stolen session cannot empty a wallet.

Three things you should know
The custody page says these to every merchant before it signs up, so we will say them here.
A merchant in a browser is less protected than a user of our phone app. For a few seconds per payout the merchant's key is in a web page that our server sends. Someone who took over that page and our co-signing server at the same time could take the money of every merchant who approved something while it lasted. The rules above hold against either one alone. To make the page harder to tamper with, every call a dashboard or checkout page makes is encrypted in the browser on top of HTTPS, with no plaintext fallback, and neither page loads a third-party script.
Before a payment arrives, our servers decide where it is sent. The merchant's keys protect money once it is in the wallet, not before.
While a payment is being converted it is with Relay, for seconds to minutes. Orrerie never holds it. Litecoin and Dogecoin are not covered by Relay and arrive unconverted.
And one more: there has been no outside security audit. Every part that touches keys or money ended with an in-house attack review. We would rather say that than let anyone assume otherwise.
What it costs, and the limits
Orrerie charges merchants 0%, and any change is announced 30 days ahead. The way to charge a fee is built into the product and set to zero.
A business can sell at once: up to US$250 for each of its first 3 paid orders, then up to US$1,000 an order and US$5,000 in any 30 days, until US$20,000 of paid orders in total. A business check through Didit raises that to US$50,000 an order and US$250,000 in any 30 days. A merchant's customers are never asked who they are. No tier limit ever stops a merchant withdrawing its own money to an address it saved; only its own safety limit, which it sets (US$10,000 in any 24 hours by default, US$100,000 after the business check), can stop a large withdrawal. A payer's address is screened after the money has arrived; that can flag a payment, it cannot prevent one.
The pictures in this article show the built product with a test business and simulated payments.
Where to start
How it works, step by step. The custody model, with its diagram. What is weaker and what we do about it. Pricing. To ask for an invitation.
