How we added Bitcoin, USDT and USDC payments to Speedwrite

A card subscription works because you've given us permission to charge your card again next month. Crypto has nothing like that. There's no way for us to take money from a wallet. Every payment is one you send yourself.

So a "monthly plan" paid in USDT would really be a plan that quietly stops after 30 days unless you remember to pay again. You'd find out when Speedwrite stopped predicting halfway through an essay. We'd rather not sell that.

Instead, you buy a stretch of time. You choose how long, pay once, and know the end date from the start. Nothing renews behind your back, and nothing stops early.

A pass gives you Professional for its whole length, with 6,000 predictions a month refilled every 30 days. That's the same allowance the card plans have. Here is how pass prices compare with paying by card:

The 60-day pass costs about 10% less than two months by card. The 180- and 365-day passes cost the same as the Semi-Annual and Annual card plans, because those plans are already priced for paying up front. Paying in crypto isn't a way around our prices, and it doesn't cost you more either.

1. On the plans page, switch from "Pay with card" to "Pay with BTC, USDT & USDC".
2. Pick 60, 180 or 365 days. You need to be signed in, so the pass goes to the right account.
3. Speedwrite opens a checkout page for your order. Choose how to pay. Bitcoin is a Lightning invoice with a QR code. For USDT or USDC you choose a network (Tron, Ethereum or Solana for USDT; Ethereum or Solana for USDC) and get an address and the exact amount to send.
4. Pay from whatever wallet you use. You don't need to click anything afterwards: the page sees the payment arrive, and your pass starts as soon as it's confirmed. With Lightning that takes seconds.
5. The order page stays as your receipt. The plans page lists your orders and shows when your pass ends.

Every order has its own page. If you close the tab halfway through, open it again and you're back at the same payment. If a USDT or USDC deposit arrives short or too late, it isn't turned into a pass, and that same page is where you claim it back.

Speedwrite is a Rails app, and much of its bookkeeping happens in rake tasks: small jobs that run on a schedule, apart from the website you use.

One of them has been around for years. Every couple of hours it goes through our card subscribers. It checks each one against their card payments, starts a fresh month of predictions when a new month begins, and ends the plan when a subscription has been cancelled.

Our first thought was to teach that task about passes. We didn't. Its whole job is to ask the card processor what happened, and a pass has nothing to ask about. Once a pass is paid, we already know when it starts, how long it lasts and when it ends. Mixing passes in would also make them depend on an outside service they don't need.

So we left the card task as it was, apart from telling it to skip pass holders. Then we wrote a second, smaller task that looks after passes and nothing else. It runs every few minutes and never calls an outside service. Each time, it:

• refills a pass with a new month of predictions every 30 days,
• ends a pass on its end date,
• makes sure a pass that was on hold picks up again once the card plan covering it has ended.

Next to it runs a background worker that comes with OpenReceive. It confirms payments on its own, so a payment still counts if you close the tab before it goes through.

• While a card plan is active, passes aren't on sale for your account. The plans page says so. They become available again once the card plan ends.
• If you start a card plan while you hold a pass, the pass goes on hold. Your card plan supplies the predictions, and the pass keeps its remaining days. When the card plan ends, the pass picks up where it left off, with the same number of days left.
• Buying another pass while one is running adds the new days to the end of the one you have.

We didn't sign up with a crypto payment company. OpenReceive is open-source (MIT licensed) checkout software that runs inside our own app. There was no account to open, no API key to request, and nobody between us and the payment. Payments arrive as bitcoin in our own Lightning wallet. When you pay in USDT or USDC, lightning-swap.com converts it to bitcoin on the way in.

OpenReceive publishes step-by-step directions for adding it next to an existing Stripe setup, written so a coding agent can follow them, with a version for Rails apps like ours. We followed them closely. The work came down to a short list: the checkout itself, a page for each order, a hook that turns a paid order into a pass, the switch on the plans page, and the rake task above.

The code turned out to be the easy part. The real decisions were about the product: passes instead of crypto subscriptions, prices that match paying up front by card, and what should happen when someone has both.