# What actually happens when a reader pays for a book in bitcoin

The ninety seconds between a reader clicking checkout and the coins arriving in your wallet — one address per order, a rate locked for thirty minutes, one confirmation, and no account at either end.

- Published: 2026-08-10
- Last updated: 2026-08-31
- Author: Inkwharf
- Canonical: https://www.inkwharf.com/blog/what-happens-when-you-pay-in-bitcoin
- Publisher: Inkwharf — https://www.inkwharf.com/llms.txt

## Takeaways

- Most readers will pay by card. This is the rail for the ones who ask, and it is off until you switch it on.
- Every order gets its own address, which is how a payment is matched to a basket with no invoice number and no account.
- The dollar-to-BTC rate is locked for thirty minutes; after that a late payment is re-quoted at the live rate, in both directions.
- One confirmation releases the download, and the coins go to a wallet you hold rather than a balance held here.

---
Cards are what almost every reader will use, and what the checkout leads with
everywhere. Bitcoin is the rail some authors want and most never switch on, and
this post exists because the authors who do want it ask a specific question:
what actually happens between the reader clicking pay and the money being mine.

Here is the whole sequence, from the side of the person selling the book.

## 1. The order gets an address of its own

When a reader chooses bitcoin, the shop requests a fresh receiving address
derived from your own extended public key. That address is used for that order
and nothing else.

This is the trick that makes invoice-free payment work. There is no reference
number to paste into a transfer, and no risk of two readers sending the same
amount at the same minute and getting tangled. The address *is* the invoice:
when coins land on it, the shop knows exactly whose basket was paid for.

It also means nothing about the reader is stored to make the payment work. There
is no payment profile, so there is nothing to leak — which is the same reason
the card checkout asks for an email address and no password.

## 2. The price is locked for thirty minutes

Your book is priced in dollars. At the moment the order is created the current
BTC rate is read once, written to the order, and used to compute the satoshi
amount. That figure holds for thirty minutes.

If bitcoin moves four per cent while the reader is finding their phone, the
amount owed does not change. After thirty minutes it does: a late payment is
re-priced from the dollar total at the live rate, because the dollar total is
the price you actually agreed to sell at and the satoshi figure was only ever a
half-hour convenience.

That re-quote is symmetric, and uncomfortable in one direction. If the rate rose,
a late payer owes fewer satoshis than they were told. If it fell, they owe more,
and a reader who sends exactly the quoted amount one minute late is told they
are short. The alternative would leave the price of every late payment as a free
option the buyer could exercise for as long as they felt like waiting, with you
on the other side of it.

## 3. The reader sends one transaction

The payment page offers a QR code, a `bitcoin:` URI that opens a wallet with the
amount filled in, and the raw address to copy. All three point at the same place.

Matching is done on the total received at that address, which has two useful
consequences:

- **Underpay and the order sits unpaid.** Sending the remainder to the same
  address completes it. Nothing is lost and nothing needs an email to you. A
  shortfall of under one per cent is accepted as paid, so a wallet's fee
  estimate cannot strand an order over a few hundred satoshis.
- **Overpay and it completes anyway.** The excess is the reader's to ask you
  for. It is not quietly kept.

The network fee goes to miners and is paid by the reader on top of the price,
rather than deducted from it. This is the one place the two rails genuinely
differ in your favour: a card sale arrives about 59¢ lighter on a $9.99 book,
and a bitcoin sale arrives whole.

## 4. One confirmation releases the book

Two things watch for the payment: the gateway calls the shop when the
transaction appears and again as it confirms, and the payment page polls the
address balance directly every few seconds, which is what keeps things working
when a webhook goes missing.

| State | What it means |
| --- | --- |
| Waiting | Nothing on the address yet |
| Seen | Broadcast, unconfirmed, waiting for a block |
| Short | Coins arrived, less than the quote |
| Paid | Confirmed, and the book is released |

One confirmation is the default, which in practice is about ten minutes from
broadcast. It is a deliberate middle ground: accepting zero confirmations makes
a small shop cheap to defraud, and demanding six means an hour of staring at a
page for a $12 novel. You can raise it for your own shop if you would rather
wait.

> **The verdict:** one address, one amount, one transaction, and every failure
> mode resolves by sending the rest to the same place.

## 5. The reader gets a permanent page, not an account

This is the part that differs most from what people expect, and it is the same
on both rails.

There is no reader account. Confirmation sends the buyer to a permanent download
page carrying the EPUB, an in-browser reader and a send-to-Kindle button, and
the link in their email returns them to it years later. If they lose the email,
they enter the address they paid with and a fresh link is issued while the old
one stops working.

Nothing is authorised per device, because there is no DRM to authorise against.
Once the file is downloaded it is a file: if this site vanished tomorrow, every
book already downloaded would keep opening, which is more than most of the
industry can say.

## Who is holding the money

Nobody, in the sense you are worried about. The gateway is a watcher rather than
a custodian — it derives addresses from a key you control and reports when coins
arrive at them. The coins go from the reader's wallet to yours in one hop. There
is no float, no balance sitting on this site, and no account that can be frozen
with your money inside it.

The trade-off, plainly: bitcoin payments are final. There is no chargeback, and
a refund means you sending coins back to an address the reader gives you. That
cuts both ways — it is also why no one can reverse a legitimate sale sixty days
later and leave you carrying it.

## Whether to switch it on at all

Most authors should not, at first. It is one more thing to understand on the day
you are trying to sell a book, and the card rail already keeps you about $9.40
of a $9.99 sale with no cut taken here. Turn bitcoin on when a reader asks for
it, or when you have readers who would rather pay that way — not because it is
the interesting rail.

The reader-facing version of all this, including the card path, is on
[how buying works](/how-it-works). What the sale is worth to you on each rail is
in [what the royalty split actually costs](/blog/what-the-royalty-split-costs-you).

**[Open a shop](/register?role=author)** — cards from the first day, bitcoin
when you want it, and no cut of a sale on either.