How we implemented our Stripe Integration - 10 Slices, No Webhook Nightmares

Our entire Stripe integration consists of 10 slices.

No webhook nightmares. No 2am production bugs. No “oh shit, we didn’t think about that” moments three months in.

It’s boring. Straightforward. And that’s exactly what we’re proud of.

Six Months Ago

We identified a problem in the market and founded a company to solve it. We built a SaaS platform where payments aren’t optional. Users buy licenses, activate seats, scale up and down as their needs change. We needed a payment system that could handle this cleanly.

Why Stripe?

The answer seemed obvious - Stripe is easy to integrate and provides everything we need. We also leveraged Supabase’s Stripe integration to avoid webhook hell.

But here’s what most people miss: we didn’t let Stripe dictate our model.

We knew our payment flow long before we ever touched Stripe’s API.

Event Modeling First

We event modeled the entire system before writing a single line of code. And here’s the key insight that changed everything:

The information flow doesn’t change if you switch payment providers - if you model it right.

This isn’t about making our model adhere to Stripe. It’s about using Stripe to fulfill our model. Our domain speaks one language. Stripe speaks another. We control the translation.

Those 10 clean slices cover the entire payment lifecycle. Each one is a discrete, manageable piece. The picture is from our Event Model.

How It Actually Works

Let me give you a concrete example of one flow:

A user activates a seat in the platform. This fires a “User Activated” event in our system. That event populates a TODO list called “License Quantity to Update.” An automation watches this list and updates the quantity in Stripe. When Stripe processes it successfully, a “Quantity Updated” event fires back into our system.

Technically we don’t react to webhooks, we watch a subscriptions table for updates. Clean and simple.

Clean handoff. Clear boundaries. No confusion about where our domain ends and the external system begins.

When Things Go Wrong

Here’s the reality - external integrations always fail sometimes. APIs go down. Payment methods get declined. Networks timeout.

But here’s the beauty of thinking this through up front: it forces you to model the process, not just handle exceptions.

Business doesn’t know exceptions. They only know processes.

So what’s the process when Stripe rejects a quantity update? In our case, we automatically remove the last ordered license seats. Simple. Because we use event sourcing, we know exactly what happened - we just replay the state and reverse it.

But it’s not quite that simple, is it?

What if the user already invited someone to that seat? What if they got a confirmation email? What if they’ve already started using it?

We mapped all of this out during event modeling - long before we wrote code. We played through these scenarios with stakeholders. We extracted the knowledge when it was still cheap to change things.

Catching Disasters Early

Those questions - “what if the seat is already in use?” - those are disasters when you tackle them later. They might change the whole process. And if you’ve already written code, if you’ve already deployed to production, the cost of that change becomes catastrophic.

Event modeling catches these problems before a single line of code is written.

That’s where the real value lives. Not in the elegance of the technical solution, but in spotting the gaps early - when they’re still just sticky notes on a board instead of emergency patches at 2am.

Process Before Provider

If you’re building a payment system, here’s my advice:

Understand YOUR process first. Then understand how to map that to Stripe.

Don’t let the third-party API dictate your domain model. The integration should be a translation layer, not your core logic. When you get this right, switching providers becomes trivial. Your domain stays stable. Only the adapter changes.

Boring is Beautiful

When people ask me which slice I’m most proud of, I tell them the truth: there’s absolutely nothing special about any of them. They’re straightforward.

And maybe that is the thing to be proud of.

Payment integrations are usually nightmares. They’re the thing developers dread. The thing that causes production bugs. The thing that takes three times longer than estimated.

Ours just works.

No heroics. No firefighting. No technical debt we’re planning to “fix later.” Just boring, reliable infrastructure doing exactly what it’s supposed to do.

The Hard Part

For me, event modeling first has become second nature. But for most developers, it’s a hard pill to swallow. It requires a real mindset shift.

There’s always that voice saying “let’s just start coding and figure it out as we go.” The urge to skip the boring, unglamorous work of modeling and jump straight into implementation.

It takes discipline to resist that. To sit with stakeholders and map out processes. To play through failure scenarios. To think deeply about edge cases before they become production incidents.

But that discipline - that’s what makes the implementation straightforward.

The Takeaway

When you understand your process deeply - when you model the happy paths AND the failures, when you think through edge cases with stakeholders, when you design your domain independent of your tools - the implementation becomes almost trivial.

Ten slices. Straightforward. Boring.

And that’s exactly how critical infrastructure should be.

Want to Build Systems Like This?

Want to learn how to build those systems for real? Grab on of the last seats in my upcoming Event Sourcing And Slicing Foundations Workshop - Building a real system Slice by Slice.

As a Newsletter Subscriber, you’ll get the additional Event Modeling Foundations Workshop for free - on January 19, we model what we’ll implement on January 20 and 21. Just answer “I’m in” to this E-Mail and I’ll send you some details.

Related Articles

Event Modeling Anti-Patterns

Common mistakes when implementing event modeling and how to avoid them

Event Modeling • December 2025

80% Planning - The Secret to Successful Software Projects

Why spending more time on planning leads to faster delivery

Event Modeling • November 2025

Event Sourcing - Keeping It Simple

Practical approaches to event sourcing without over-engineering

Event Sourcing • November 2025