The Stripe integration docs will get you from zero to taking real payments in an afternoon. What they won't tell you is what you're now legally on the hook for, because that's not Stripe's job, it's yours. None of it is complicated once you know it exists; the problem is that nobody hands you the list.
PCI compliance: simpler than it sounds, if you set it up right
If you use Stripe Checkout (the hosted payment page) or Stripe Elements with the standard hosted-fields approach, and your own servers never see, store or transmit raw card numbers, you generally qualify for the simplest self-assessment tier, SAQ A. You fill out a short annual self-assessment questionnaire rather than a full security audit.
The condition that matters: the payment page has to be genuinely outsourced, served directly from Stripe's domain, not an iframe you've styled to look native, not card fields you're touching in your own code. Recent PCI DSS updates (v4.0.1) also require you to confirm your payment page isn't vulnerable to script-injection attacks and that everything loaded on it comes from a PCI-compliant source, which is a checkbox if you've genuinely kept Stripe's hosted approach and haven't bolted on unrelated third-party scripts to the same page.
The 14-day cancellation right you can't integrate around
UK consumers generally have 14 days to cancel a service contract bought online, no reason required. For digital content and subscriptions this gets specific:
- If your product delivers value immediately (a SaaS tool, not a one-off digital download), you should not start providing the full paid service until either the 14 days pass or the customer explicitly consents to start earlier.
- If they consent to start early and then cancel within the window, you're entitled to charge only for what they actually used, not the full amount, and only because they gave that consent. Skip the consent step and you may owe a full refund regardless of usage.
- For pure digital downloads, the same 14-day right applies unless the customer explicitly waives it to get instant access, and that waiver needs to be a real, recorded action, not assumed.
This is a UI and checkout-flow decision, not just a legal footnote: your signup flow needs an actual consent step if you want customers using the product immediately after paying, which almost every SaaS does.
Refunds: the clock starts when they ask, not when you act
Once a customer validly cancels, you're required to refund them within 14 days of that cancellation, using the same payment method they used to pay, generally without deducting a fee. Stripe handles the mechanics of issuing a refund in a few clicks; the legal clock is separate from Stripe's processing time, so don't sit on a cancellation request.
Information you owe customers before they pay
Total price (including any recurring amount, stated plainly, not just "from £X"), your business identity and contact details, and how to cancel, all need to be clear before checkout, not buried in Terms of Service they'll never open. The Terms of Service guide covers this in more depth; it's directly relevant here because a checkout flow missing this information is a compliance gap, not just a UX one.
The pattern underneath all of this
None of these obligations are unique to big companies, they attach the moment you take a UK consumer's payment online, regardless of team size. What's genuinely optional is doing this badly versus doing it right the first time, which mostly costs a bit of upfront thought, not money.
If working through PCI scope, cancellation flows and refund timing feels like a distraction from the product itself, that's the exact gap Qeetoto closes for the developers we work with, alongside hosting, legal and marketing. Get in touch if you want this reviewed before launch rather than after a support ticket teaches you the hard way.
FAQ
Does using Stripe automatically make me PCI compliant? No, Stripe makes SAQ A achievable if you use their hosted checkout/elements properly and don't touch card data yourself, but you still have to complete the annual self-assessment; it's not automatic just because Stripe processes the payment.
Can I just not offer refunds to avoid this complexity? No. The 14-day cancellation right is a legal entitlement for UK consumers on most online service and digital content contracts; a "no refunds" policy doesn't override it, and stating one you can't legally enforce is itself a problem.
What if my customers are all businesses, not consumers? Business-to-business contracts have more flexibility, the consumer protections above are specifically about protecting individual consumers. If you're B2B-only, this changes what applies, but check your actual customer base honestly; many SaaS products sell to sole traders who count as consumers for this purpose.
Do I need to do anything differently for subscriptions versus one-off payments? The same cancellation-right principles apply, but subscriptions add an ongoing obligation: clear terms on renewal, easy cancellation going forward (not just for the first purchase), and increasingly, rules requiring cancellation to be as easy as signing up.