Accepting Crypto Payments for SaaS Subscriptions

The subscription challenge with crypto

Cards make recurring billing easy because the processor holds a token you can charge whenever you want. Crypto has no equivalent primitive — every transaction needs a fresh signature from a customer wallet. If you try to force a monthly card model onto Solana, you end up with a broken experience: customers keep having to open their wallet, approve, and confirm, and any lapse in their attention breaks the loop.

Most SaaS teams that add crypto end up in one of two camps. They either move to a top-up-and-consume balance model, or they issue payment links per renewal cycle. The former usually converts better and produces fewer failed renewals — but both have a place, and the right choice depends on how predictable your usage patterns are.

Top-up model

The top-up model is simple: customers move funds into a credit balance held on your side, and your metering system draws from that balance as they use the product. You handle the crypto acceptance once per top-up, then never touch a wallet again until the balance runs low.

A good default is to offer a handful of preset amounts — $20, $50, $100, $250 — and let the customer pick one or type a custom amount. Your server calls POST /api/company/{companyId}/payment-session, gets back a hosted checkout URL, and redirects the customer. On confirmation the webhook fires and you credit the balance in fiat units (not native token amounts).

Metered credit

Store balance in cents or another minor-fiat unit — not in SOL or in USDC lamports. If a customer tops up 50 USDC, that becomes 5000 cents of credit. Your usage meter deducts against that number as calls hit your metering endpoints.

The reason: you don't want your customers exposed to SOL price swings against the invoices you're computing. Once the payment is confirmed, the conversion and the credit are done at that moment's rate, and your bookkeeping stays in one currency.

Rules that tend to work

• Credit balance is denominated in the merchant's reporting currency (usually USD).
• Refunds go back as balance, not to the original wallet.
• Low-balance email at 30% remaining, hard stop at 0.
• Balance carries indefinitely — expiring credit is a support headache.
• Bulk top-up discount ("Add $500, get $550") is your main lever for larger deposits.

Handling failed renewals

In a top-up model, there's no such thing as a declined card — but you still have to handle the case where a customer's balance runs out mid-cycle. Two things matter here.

First, warn early. When usage projections show they'll hit zero in less than a week, send an email with a one-click top-up link. Second, give a short grace period at zero — 48 to 72 hours where the service still runs but shows a persistent banner — before pausing. If you go straight to a hard stop, you'll churn customers who just didn't check their inbox.

For teams that need something closer to classic recurring billing, you can issue a monthly payment link and email it three days before renewal. The tradeoffs are covered in our payment sessions vs payment links guide.

A working setup

A minimal SaaS-with-crypto stack on Solpaygate looks like this:

1. Customer clicks "Add funds" in your dashboard and picks an amount.
2. Your server calls POST /api/company/{companyId}/payment-session with the amount in USDC.
3. Redirect the customer to the returned url. They pay in SOL, USDC, or USDT — all land as your configured stablecoin on your master wallet.
4. Solpaygate delivers a webhook to your webhookUrl. You verify the signature and credit the balance atomically.
5. The customer returns to your app via the returnUrl you set on the session.

If you're wiring the top-up flow itself, our complete guide to building a top-up flow covers the UX details — button placement, amount presets, the confirmation screen — that make the difference between a 40% and a 70% completion rate.