Why are you still writing payments and billing code?

Payments Today

Leading up to Demo Day, you’ve spent long hours adding new features to your product. A legion of coding agents has shipped thousands of lines of code for you in just a few keystrokes. But when it comes time to add payments, it’s a record scratch moment.

Vibe coding and payments DON’T mix. At least not today. Here’s why:

• Today’s payment processors require webhooks, which are notoriously hard to test, stabilize, and maintain

• The sensitivity of payments-related code means you have to think extra hard about what logic happens on your frontend, vs your backend vs your processor’s backend

• The business logic requires you to store references to your payment processor’s ids for customers, prices, payment methods and more

• You need to revisit all of this fractured code every. single. time. you want to change your pricing

Every single codebase has to re-implement the same state management solution every single time. Even if your agent completes the obstacle course, its payments code is only ever locally correct. This is one of the parts of your codebase that accumulates technical debt the fastest.

Here’s an extremely vanilla, simplified checkout flow for activating a customer’s first subscription. Today’s processors require you to choreograph no fewer than 17 server-client hops, and at least 5 distinct mappings between different entities across at 2-3 different services.

It’s no wonder why most payments code is so brittle.

Enter Flowglad

We’re the first payment processor designed from the ground up for programming in natural language.

We’re bridging the gap between vibe coding and the messy precision demanded by payments. The result: Flowglad’s payments layer requires zero glue code. Instead of managing webhooks, and keeping your DB in sync with your processor, you just read from us in real time.

Here’s what that same flow looks like in Flowglad:

import { useBilling } from '@flowglad/nextjs'

function CheckoutButton() {
  const { createCheckoutSession, catalog } = useBilling()

  const onClickUpgrade = () => createCheckoutSession({
    priceId: catalog.products[0].defaultPrice.id,
    autoRedirect: true
  })

  return <button onClick={onClickUpgrade}>
    Upgrade
  </button>
}

import { createAppRouterRouteHandler, FlowgladServer } from '@flowglad/nextjs/server'

const handler = createAppRouterRouteHandler(
  new Flowglad({ supabaseAuth: { createClient } })
)

export { handler as GET, handler as POST }

For a full example, see a PR here that shows all the code we eliminate from a conventional checkout flow. We’re not just ~80% less code footprint on day 1, we eliminate the most brittle and risky logic. The code we eliminate is the stuff that grows into giant piles of spaghetti as your pricing models evolve.

Demo

Here's a demo setting up payments in minutes with natural language using MCP:

Why not just build a billing software?

The best solution to this problem will be a payment processor, rather than a bolt-on billing SaaS. That’s because:

1. We’re no additional cost to what you already pay (e.g. we’re .65% vs Stripe Billing’s .7%)

2. You don’t need to think about multiple systems: we manage your entire payments layer

3. Processing sets us up to do really cool stuff around global tax compliance (coming soon!)

4. Over time, we’ll tailor our risk and compliance specifically to the weird future of AI

We’re happily built on top of Stripe, and are using their infrastructure to push the bar forward. This is similar to how Supabase and Vercel offer radically simplified alternatives built on top of AWS.