Most SaaS companies charge subscriptions. Velocity X doesn't. For a custom web design package ($4,995 small, $9,995 medium, $24,995 large), one-off billing makes more architectural sense than recurring revenue. This is the engineering decision nobody talks about because Stripe subscriptions feel like the default.
The Subscription Complexity Tax
Stripe subscriptions are powerful. They're also expensive to implement correctly. You need a Stripe Customer object, a Subscription object, an Invoice, a webhook endpoint to handle invoice.payment_failed events, dunning logic for retries, proration for mid-cycle changes, tax calculations that differ by region, and idempotency keys to prevent double-charges. If you mess up the webhook handling, payments fail silently and you don't get paid. Most solo builders skip the dunning logic entirely and lose 5–15% of recurring revenue to failed cards.
One-off checkout is simpler. You create a PaymentLink, the customer clicks it, Stripe handles the entire payment session server-side (no frontend token handling), and it completes in one request. No Customer object. No webhook gymnastics. No failed-payment recovery. Invoice? Stripe generates one automatically and emails it to them. You check the dashboard or query the Charge object and move forward.
When One-Off Wins (And It's More Often Than You Think)
Velocity X packages are deliverables, not ongoing services. The payment event is singular: customer pays $X, receives website codebase + 30-day support window, done. Subscription implies "I'll keep charging you next month whether anything changes or not." That's only true if you're billing for hosting ($25/month Netlify Pro), domain renewal ($15/year), or ongoing support retainers. For a $9,995 website that you hand off and the customer runs themselves? One-off is the honest model.
The Payment Link pattern also reduces refund friction. If a customer is unhappy within 30 days, issuing a refund takes 90 seconds. With subscriptions, you've got to handle proration, determine which invoices to reverse, and decide whether partial-month credits apply. Velocity X offers a 30-day money-back guarantee; one-off invoicing makes that trivial to honor.
Tax and Compliance: One-Off is Simpler
Australia and globally, one-off payments are tax-straightforward. You record the Charge, it becomes a line item in your P&L, done. Subscriptions require tax jurisdiction rules (is the customer in AU, US, EU, Singapore?), GST/VAT rate lookups, and potentially Stripe Tax integration. If you sell subscriptions across five countries and mess up the tax logic, you're at risk of under-remitting.
For a one-person operation selling custom websites, one-off removes that complexity. Currency conversion is Stripe's problem. GST is a fixed amount per invoice. Tax compliance is annual accounting, not per-transaction engineering.
The Webhook Apocalypse
Every subscription system needs webhooks. You create an endpoint, Stripe sends POST requests to it, and your code updates your database to reflect paid invoices, failed charges, customer cancellations, etc. If your webhook endpoint goes down, Stripe retries for three days and then gives up. If you don't handle invoice.payment_failed, the next invoice fails and you never charge the customer again. If you don't implement idempotency correctly, you can process the same event twice and create duplicate charges.
With one-off checkout, Stripe's responsibility ends when the payment is confirmed. You can query the Payment Link status asynchronously at your leisure. No webhooks required (though you can still use them for email confirmation automation). This shifts risk from you to Stripe's battle-tested infrastructure.
Frequently Asked Questions
What if the customer wants to pay in installments?
Stripe Payment Links support payment_intent.allowed_source_types configuration, which includes BNPL (Buy Now, Pay Later) providers in Stripe's ecosystem. The customer selects Afterpay or Klarna at checkout; Stripe handles the backend. You still receive the full amount upfront.
Can one-off handle add-ons or upsells?
Not cleanly. Subscriptions let you add Subscription items mid-cycle. For one-off, you'd create a second Payment Link (e.g. "Add 3 extra pages for $800"), which creates a separate invoice. If you're regularly selling add-ons, subscription becomes more elegant — but for Velocity X, add-ons are rare, so the separate-link friction is worth the simplified base model.
How do I handle annual vs multi-year pricing?
One Payment Link per tier. You set the amount to the total price (e.g. $24,995 for large), customer pays once, done. Subscriptions would let you bill $24,995 every 12 months, but that's only useful if the service renews yearly (hosting, support retainer). A website doesn't.
What about seat-based or usage-based pricing?
This is where subscriptions win decisively. If you charge per user seat or per API call, you need monthly reconciliation. One-off billing doesn't fit that model. But if your pricing is fixed tiers (Small / Medium / Large), one-off is the right call.
Can I upgrade a customer later without losing their original invoice?
Yes. Create a new Payment Link for the delta amount (e.g. difference between Small and Large package), customer pays, and they get a second invoice. Both invoices stay in their Stripe history and your accounting. Cleanest model for infrequent upgrades.
Does one-off checkout work in AU?
Yes. Stripe Payment Links support AUD pricing, AU-resident payers, and GST recovery. Currency is set in your Stripe Dashboard per link. No regional restrictions for one-off checkout.
The Bottom Line
Stripe subscriptions are for products that recur (SaaS, hosting, retainers, memberships). Velocity X packages are one-time deliverables. Payment Links are simpler, have fewer failure modes, eliminate webhook risk, and align with the actual product model. The only reason to use subscriptions is if you're billing for ongoing value; if you're not, one-off checkout is the senior-engineer choice. Check the packages — every tier uses Payment Links, zero subscriptions overhead.