How to Implement Stripe Billing the Right Way for B2B SaaS

Integrating payments seems simple on the surface: A user enters their credit card, and you give them access to your software. But in the world of B2B SaaS, billing logic is notoriously complex.

You have to handle free trials, prorated upgrades, failed payment retries, cancellations, grandfathered pricing, and usage-based metered billing. If you architect your Stripe integration poorly, you will end up with a brittle system that locks users out accidentally or gives premium features away for free.

Here is the GrassHopper Digital playbook for implementing Stripe Billing the right way.

1. Stripe is the Source of Truth

The most common mistake developers make is trying to mirror Stripe’s complex state entirely within their own database. They create custom columns like is_paid, trial_end_date, and current_plan_id, and try to update them manually via API calls.

This creates race conditions and synchronization nightmares.

Best Practice: Treat Stripe as the absolute Source of Truth for subscription status. Your database should only store the Stripe customer_id and the Stripe subscription_id. Whenever you need to know if a user has access to a feature, you either query Stripe directly or, better yet, rely strictly on Webhooks to update a simplified access control list (ACL) in your database.

2. Master the Webhook Architecture

Since Stripe handles recurring charges automatically in the background, your application needs a way to know when a payment succeeds or fails. This is done via Webhooks.

Best Practice: Build a robust, idempotent Webhook handler.

• Idempotency: Webhooks can sometimes be sent twice by Stripe due to network retries. Your code must check if a specific event has already been processed before executing it to avoid double-crediting an account.
• Queueing: Do not perform heavy database operations directly in the Webhook handler. Acknowledge the Webhook immediately with a 200 OK response to Stripe, and push the event payload into a background job queue (like AWS SQS or BullMQ) for processing.

3. Utilize Stripe Checkout and Customer Portal

In the past, developers built custom credit card forms using Stripe Elements and built custom pages for users to view their invoice history. This is no longer necessary and is a massive waste of engineering time.

Best Practice:

• Use Stripe Checkout for onboarding. When a user clicks “Upgrade,” redirect them to a Stripe-hosted checkout page. It is highly optimized for conversion, handles 3D Secure authentication automatically, and supports Apple Pay/Google Pay out of the box.
• Use the Stripe Customer Portal for account management. Instead of building a UI for users to update their credit cards, download PDF invoices, or cancel their plans, generate a secure link to the Stripe Customer Portal and let Stripe handle it.

4. Handling Webhook Failures Gracefully

If your server goes down and misses a invoice.payment_succeeded Webhook, a customer might be charged but not granted access to your app.

Best Practice: Implement a daily reconciliation cron job. Every night, a script should query the Stripe API for all active subscriptions and compare them against your local database access rights. If there is a mismatch (e.g., Stripe says they are active, but your database says they are canceled), the script automatically corrects your local database and flags the anomaly.

Conclusion

Billing is the lifeblood of your SaaS. Do not try to reinvent the wheel. By relying on Stripe as the source of truth, utilizing robust asynchronous Webhooks, and leaning on Stripe’s pre-built UIs, you can build a rock-solid billing engine that scales effortlessly from your first $1 to your first $1M.