Every failed renewal is involuntary churn you didn't earn. Disputes on digital subscriptions claw back months of access. Cross-border renewals bleed FX on every charge. Card billing stacks risks against a SaaS business at scale.
Suward charges each billing cycle as one crypto payment. The moment it settles, a signed webhook activates or renews the plan — irreversible by design, no chargebacks, 0.4% per payment, minimum $1. Bill in USDT or USDC and the dollar amount holds end to end — no FX drift between invoice and settlement. Native coins are accepted too. Your billing system sends each charge and the customer approves each cycle, so renewals go through with their sign-off and charges never surprise them.
Two primitives run the whole cycle, and they survive contact with real billing: charge the period, then activate on settlement.
When your scheduler reaches a renewal date, call POST /v1/payments for that period's amount in the customer's chosen asset. Each call is idempotent on your key, so a cron job that retries a stuck renewal never charges the same cycle twice.
When the payment reaches Success, Suward sends a signed payment.success event. Your handler extends the subscription and unlocks the plan. If the cycle never gets paid, you get payment.failed instead and run your own dunning.
The customer approves each cycle, so a renewal only ever goes through with their sign-off. You keep the renewal cadence, the retry timing, and the reminder emails. Suward keeps the charge correct and the signal trustworthy.
POST /v1/payments{ "amount": "49000000", "asset": "USDC_BASE", "externalId": "sub_u789_2026-07"}# amount: smallest unit — USDC has 6 decimals, so 49000000 = 49 USDC → 200 { "id": "pay_f4e1a2", "status": "pending" } # Cron retry — same externalIdPOST /v1/payments { same body }→ 200 { "id": "pay_f4e1a2" } ← same id, no double chargePoint a webhook URL at your project or at a single payment, and Suward signs every event with Ed25519. payment.accepted lands when the deposit is accepted and safe to act on, payment.success when it reaches full settlement and is ready to withdraw. Most teams provision on payment.success and grant a short grace window on payment.accepted, since accepted funds are credited but still within the settlement window. Verify the signature, extend the plan, done.
Events retry at least once, so a five-second blip in your handler doesn't lose a renewal. If a webhook never gets through, polling the payment status over the API stays available as a fallback. Nothing about your billing depends on a single delivery landing.
Digital subscriptions sit in a high-dispute category, and fighting a card chargeback costs more than the amount in dispute once fees and labor are counted. An on-chain payment that reaches Success is irreversible. There is no "friendly fraud" button to claw back a month of access you already delivered.
Cards get declined across dozens of countries on issuer rules and FX controls, and every failed renewal is involuntary churn you didn't earn. A crypto payment doesn't care where the customer banks. Their renewal goes through or it doesn't, with no silent issuer veto in the middle.
Card acquiring plus cross-border and FX lands well above crypto rails on international volume. At 0.4% per payment on larger invoices, an annual B2B license or a high-MRR account keeps meaningfully more per charge. Pricing is 0.4% with a $1 minimum per payment, and the pricing calculator shows the exact crossover.
Bill in USDT or USDC and the amount reads in dollars on both ends. A customer pays 49 USDC for a 49-dollar plan, you receive exactly 49 USDC, and nothing drifts between invoice and settlement.
Test payments run a real hosted checkout. Build your renewal job against it: create a cycle charge, simulate Pending → Accepted → Success, and confirm your webhook handler flips the plan and survives a duplicate delivery. Idempotent requests and v2 API keys with their own rate limits mean your cron can be as aggressive as it needs to be without double-charging or tripping a limit.
Some subscription businesses live where card processors flag them high-risk or where customers simply don't carry usable cards. Crypto rails reach them without rolling reserves or sudden account freezes.
Accept on Ethereum, BSC, Arbitrum, Optimism, Base, Plasma, Polygon. The 21 assets include stablecoins (USDT and USDC, plus USDC.e on Arbitrum) and the native coin of each network. For subscription billing, stablecoins keep the invoice and receipt dollar-denominated without live FX. Each network adds a small fixed Suward fee that covers the on-chain cost, separate from the 0.4%: Ethereum $0.20, BSC $0.01, Arbitrum $0.01, Optimism $0.01, Base $0.01, Plasma $0.01, Polygon $0.01. That keeps a low-priced monthly plan from being eaten by gas.
FAQ
Yes, as approve-each-cycle billing. Your scheduler calls POST /v1/payments each cycle, and a signed payment.success webhook tells your app to extend the plan. You own the cadence; we own the correct charge and the signal.
Subscribe to webhooks. On payment.success, verify the Ed25519 signature and extend the subscription. payment.accepted arrives earlier — accepted, safe to act on — if you want to grant a short grace window before full settlement.
No. Requests are idempotent on your key, so a cron that retries a stuck cycle returns the same payment instead of creating a second one.
USDT and USDC across the networks, plus USDC.e on Arbitrum, and the native coin of each network. Stablecoin billing keeps amounts dollar-denominated end to end; native-coin billing settles in the asset received.
Manually. A settled payment is irreversible, so a refund is a payout from your balance, usually applied as a prorated credit on the next cycle rather than reversing the current one.
Yes. Test payments run a cycle charge end to end so you can verify provisioning and idempotency. Mint test coins with no signup, then create a free account to run it against a test key — no live key needed.
Tell us about your billing stack and we'll walk you through the integration — or run a test cycle first.