How SaaS Payments Work: A Stripe Primer for Non-Technical Founders

Why Understanding SaaS Payments Matters Before You Hire

You're about to spend thousands on a SaaS platform. If you don't understand how money actually flows through it—how customers get charged, what happens when a card fails, where your revenue gets tracked—you'll make expensive mistakes and ask your developer the wrong questions.

This article cuts through the jargon. By the end, you'll know what "payment processor" means, why Stripe is the default choice, and the specific questions to ask before work begins.

What Is a Payment Processor and Why Does Your SaaS Need One?

A payment processor is the middleman between your customer's bank and you. When someone enters their credit card into your app, their bank doesn't trust your little startup—it trusts Stripe (or PayPal, or Square). Stripe holds the money, takes a cut (typically 2.9% + 30 cents per transaction for card payments), and deposits the rest into your bank account.

You don't want to handle raw credit card data yourself. It's expensive, risky, and probably illegal without serious compliance work. Stripe lets you avoid that entirely.

The key insight: Your SaaS doesn't actually process payments. Stripe does. Your job is to tell Stripe when to charge someone and how much.

The Three Types of SaaS Payment Models (And Why It Matters)

Not all SaaS billing looks the same. Which model you choose affects cost, complexity, and revenue predictability.

1. Recurring Subscriptions (Most Common)

Charge the customer the same amount every month or year. Examples: $29/month for Slack, $99/year for Notion. This is the gold standard for SaaS because revenue is predictable and customers rarely cancel mid-month.

What happens: Stripe automatically charges the customer's card on the same day each cycle. If the card fails, Stripe retries (usually 3-4 times over two weeks). If all retries fail, the subscription pauses and you get notified.

Stripe's part: Stores the payment method, runs the recurring charge, handles retry logic. Your app just says "Bill customer X every month."

2. Usage-Based Billing (Complex, Growing)

Charge based on what the customer actually uses. Examples: Twilio charges per SMS sent, AWS charges per compute hour. Customer uses 5,000 API calls one month, 50,000 the next—bill varies accordingly.

What happens: Your app tracks usage throughout the month (API calls, gigabytes stored, etc.). At month's end, you tell Stripe "Bill customer X $2,847 for 1M API calls." Stripe charges them, you collect money.

Why it's complex: You need accurate usage tracking. If your tracking breaks, your billing breaks. You also get irregular churn (customers who hit a high bill one month and cancel).

3. One-Time Payments

Just charge once. Less common for SaaS (more common for courses or digital products), but some SaaS use it for one-off features or setup fees.

What happens: Customer clicks "Pay $99." Stripe processes it immediately. No recurring charge, no retry logic needed.

Stripe 101: The Core Concepts You Need to Know

Customers and Payment Methods

When someone signs up for your SaaS, Stripe creates a Customer object. That's just a record: "Jane, jane@example.com, customer ID cus_abc123." You'll reference that ID in your database.

When Jane enters her credit card, Stripe creates a Payment Method object and attaches it to her customer record. Stripe never stores the raw card number on your servers—only a token you can use to charge her later.

If Jane later updates her card in your app, you update that payment method. If she cancels, you delete it.

Subscriptions and Invoices

A Subscription is a repeating contract between Stripe and your customer. "Charge jane@example.com $29 every month, starting today." Stripe keeps this running automatically.

Each time Stripe charges, it creates an Invoice. An invoice is a record: amount, date, payment status, customer. You can send invoices to customers for accounting ("Here's your receipt for January") or they can self-serve in your app's billing dashboard.

Webhooks (How Your App Stays in Sync)

Stripe can't magically update your database. So it sends your app webhooks—notifications when things happen. "Payment succeeded," "Subscription canceled," "Card declined." Your developer sets up an endpoint (a URL on your server) that receives these events and updates your app accordingly.

Example: Customer upgrades from the $29 to $99 plan. Stripe sends a webhook. Your app sees it, updates their permissions, and emails them a receipt.

Why this matters: If webhooks break, your billing logic breaks silently. Make sure your developer tests this thoroughly.

The Money Flow: Where Does Revenue Go?

Here's the timeline from payment to your bank account:

• Day 1: Customer's card is charged. Stripe takes 2.9% + 30 cents. Remaining balance sits in your Stripe account.
• Day 1-2: Stripe settles the charge with the customer's bank (this is automatic background work).
• Day 2-5 (typical): Stripe deposits the money into your business bank account. Exact timing depends on your bank and whether it's a weekend.

You can see all pending and completed payouts in your Stripe dashboard. Most founders set up automatic daily payouts so money leaves Stripe as soon as it clears.

Real number: If a customer pays you $100/month, you'll see ~$96.71 after Stripe's cut. That's your actual revenue. Budget accordingly.

Common Payment Scenarios Your Developer Must Handle

Failed Cards and Retries

A customer's card declines (expired, insufficient funds, fraud block, etc.). Stripe automatically retries the charge 3-4 times over 14 days using its retry schedule.

Your job: Decide what happens to the customer's account while a payment is failing. Do they lose access immediately? Can they keep using the service? You need to tell your developer this policy upfront.

Plan Changes and Proration

Customer is on the $29 plan. On day 15 of the month, they upgrade to $99. Stripe must prorate the charge. If $29 covers a full month and $99 covers a full month, how much do you charge for the remaining 15 days?

Stripe handles the math, but you need to tell it your policy: charge immediately (new card charge today, previous subscription continues), or add to next invoice (don't charge today, just roll it into next month's bill)?

Refunds and Disputes

A customer requests a refund. Can you issue it via Stripe dashboard? Yes, but you need clear policies: refund within 7 days? Full refund only? Stripe doesn't referee disputes—that's between you and the customer.

If a customer disputes a charge (credit card chargeback), Stripe alerts you. You lose the money and pay a $15 chargeback fee unless you fight it with evidence (email receipts, usage logs, etc.).

Stripe Pricing: What You'll Actually Pay

Card payments: 2.9% + 30 cents per transaction (standard US pricing; varies by country).

ACH bank transfers: 0.8% ($0.30 minimum, $5 cap) if you offer customers the option to pay from a bank account.

One-time fees: Chargeback fees ($15), failed payment retries (free), API usage (free), PCI compliance (handled by Stripe, free to you).

Real example: 100 customers on a $50/month plan = $5,000 revenue. Stripe takes ~$145 per month. You keep $4,855. That's your effective cut.

Why Stripe (Not PayPal, Square, or Others)?

Stripe dominates SaaS because it's built for developers who build for non-technical founders. It's cheaper than PayPal, more flexible than Square, and has better documentation and API than almost anyone.

Stripe strengths: Excellent webhooks, clear pricing, works globally, strong anti-fraud, billing automation built-in.

Why not others: PayPal is more expensive (3.49% + 30 cents), Square is simpler but less flexible, older processors lack good APIs.

If you're building a SaaS, assume Stripe. Your developer will thank you.

Questions to Ask Your Developer Before They Start

Use this checklist when you're onboarding a developer to build your payment system:

• "What happens to the customer's account if a card payment fails? Do they lose access immediately?"
• "How do we handle plan upgrades and downgrades? Do customers get prorated refunds?"
• "Will the billing system send test charges during development? How do you avoid accidents?" (Ask if they use Stripe's test mode—they should be.)
• "How are webhook events tested and logged? What happens if a webhook fails silently?"
• "Can customers see their payment history and invoices in the app?"
• "If a customer requests a refund, can I issue it from the dashboard or does it require code?"
• "Are we handling PCI compliance? Are credit card numbers ever stored on our servers?" (Answer: no, never. Stripe handles it all.)

Building vs. Buying: Stripe vs. Billing Platforms

You have two choices: build custom billing (what this article assumes) or use a billing platform like Chargebee, Zuora, or Paddle that wraps Stripe and adds features like dunning (smart retry logic), tax compliance, and multi-currency support.

Custom Stripe + your developer: $3,000-$8,000 for a basic billing system, very customizable, you own the code, scales well.

Third-party billing platform: $100-$500/month on top of Stripe fees, pre-built features, less customization, easier to scale complex scenarios (multi-tenant, reselling, etc.).

For most early-stage SaaS, custom Stripe is the right move. You're not complex enough yet, and you need to keep costs down.

The Technical Debt Risk: What Can Go Wrong

Bad billing implementation is expensive to fix. If your developer builds it carelessly, you'll face:

• Lost revenue: Webhooks fail silently, some customers never get billed but think they're paying.
• Support chaos: Refunds get double-processed, customers get charged twice, prorations are wrong.
• Compliance fines: Bad PCI practices expose credit card data (rare with Stripe, but possible with bad code).

This is why hiring a careful, experienced developer (not a junior or agency that's doing their first SaaS) matters for payments specifically.

Common Mistakes Founders Make

Ignoring failed payments. "Most cards go through, so we don't need a good retry system." Wrong. 5-10% of card charges will fail. Without smart retries, you leave thousands on the table.

Building an "upgrade path" after launch. "We'll build billing in v2." This almost always takes longer and costs more than doing it right upfront.

Trying to avoid Stripe fees by "gifting" early access. "We'll charge later, once we're bigger." You won't. Set up billing from day one, even at $1/month, to build the habit and test the system.

Not testing edge cases. What happens if a customer's annual plan renews and their card is declined? Will you notice? Does the customer? These scenarios need to be tested before launch.

Your Next Step: Know Your Stripe Model Before Hiring

Before you talk to a developer, decide: Are you doing fixed monthly subscriptions? Usage-based billing? How do you handle failed payments? What's your refund policy?

You don't need to have every detail nailed down, but you should be clear on the outline. A skilled developer can help you design it, but they need direction from you on business policy.

SaaS payments aren't mysterious or scary once you understand the flow: Stripe stores payment methods, runs recurring charges, sends webhooks, and deposits money into your bank account. Your job is to build the business logic on top—when to charge, what to charge, what access the customer gets.

The right developer will handle the technical rigor. You'll provide the business rules. Together, you'll have a billing system that works reliably and scales with your business.

Ready to Build Reliable SaaS Billing?

If you have a SaaS idea and need a fixed-price quote for the full platform—including payment processing, invoicing, and subscription management—I'd like to help.

Tell me about your SaaS: What problem does it solve? What's your pricing model? How many customers do you expect in year one? I'll send back a detailed technical plan and a fixed quote within 24 hours. No fluff, no surprises.

Describe your idea and get a quote. Let's build something that doesn't just take payments—it scales with your business.