Why we moved beyond Stripe for AI billing — and built Macropay.

The easiest version of this story would be: "Stripe failed, so we replaced it." It would also be wrong.

Stripe made it dramatically easier to accept an online payment. Its APIs, hosted checkout, webhooks, and ecosystem remain a strong default for many companies. Our problem appeared one layer above payment processing. We were building AI products whose costs changed on every request, whose customers expected prepaid credits and hard budgets, and whose global sales created tax and compliance work long before the finance team was ready.

This is the end-to-end account of why we built Macropay, what we kept from the Stripe mental model, what we changed, and how to decide whether the same move makes sense for your company.

What Stripe solved well

Stripe solved the movement of money and the developer experience around it. A team can create a customer, collect a payment method, issue an invoice, and receive event notifications without building direct card-network or banking integrations. That is real infrastructure value.

Stripe also supports usage-based billing. Its current model includes meters, meter events, configurable aggregation, idempotency identifiers, and dimensions for segmentation. The official usage-based billing documentation is clear about the lifecycle: ingest usage, attach it to catalog prices, invoice the customer, and monitor thresholds.

If your product has a monthly seat price plus a predictable overage, this can be exactly the right model. We found the boundary when billing became inseparable from product runtime and cost accounting.

Why our billing stack fragmented

An AI request can touch several paid systems before it produces a result: a model provider, vector database, search API, browser session, voice service, or third-party tool. The customer may be charged per token, request, minute, task, or outcome. The upstream cost can vary even when the customer price does not.

Our first architecture treated those concerns as separate products:

• application telemetry recorded product usage;
• a metering job aggregated billable quantities;
• the payment platform generated invoices and collected funds;
• a tax product calculated transaction tax;
• finance spreadsheets estimated customer margin;
• product code enforced credits, limits, and entitlements.

Every system was reasonable on its own. The problem was reconciliation. When an event arrived late, was replayed, or needed a correction, usage, invoices, credits, tax reports, and margin could disagree. A billing incident became a distributed-systems incident with a finance deadline.

Usage is a ledger, not a counter

A counter answers one question: how many units did the customer use? A revenue ledger needs to answer more:

• Which customer, workspace, agent, and model generated the event?
• What was the customer price at that moment?
• What did the upstream infrastructure cost?
• Was the event accepted, rejected, retried, refunded, or adjusted?
• Which invoice, tax record, entitlement, and payout reference it?

We built Macropay around an immutable metered event because every downstream operation should read the same source record. Invoices and margin reports can aggregate it differently, but they should not disagree about whether it happened.

This design also changes how limits work. A warning at 80% usage is an analytics feature. Refusing an expensive model call after a prepaid balance reaches zero is a runtime guarantee. The balance reservation, event, and eventual charge must be coordinated under concurrency, not reconciled hours later.

Why Merchant of Record mattered

Payment processing and Merchant of Record are different operating models. In a standard processor setup, your business is the seller to the customer and generally retains responsibility for indirect tax, refunds, disputes, and local consumer requirements. Tax software can automate meaningful parts of that work, but the operating responsibility still needs an owner.

Stripe Tax has evolved and now offers both calculation-focused and more complete compliance plans. Its current official pricing page distinguishes Tax Basic from Tax Complete, which can include registrations and filings. That is an important improvement over treating Stripe Tax as calculation-only.

We chose a Merchant-of-Record foundation because we wanted the legal seller, payment flow, tax records, disputes, and payout ledger to be designed together. For supported transactions, Macropay becomes the merchant of record rather than asking each software company to assemble and operate that responsibility itself. See the Merchant of Record product overview for the practical scope.

The missing customer-level margin view

Revenue is not enough for an AI business. Two customers on the same $99 plan can have opposite economics if one uses a small hosted model and the other runs long, tool-heavy workflows against a premium model.

We wanted margin at the same dimensions used for billing: customer, agent, model, feature, and event. That required recording cost next to billable usage, not joining a payment export with infrastructure invoices at the end of the month. Once cost and price share the event ledger, teams can change routing, pricing, budgets, or entitlements before a loss-making cohort becomes a quarterly surprise.

How we designed migration to avoid a cliff

The riskiest part of changing billing systems is not creating new prices. It is preserving customer state: subscriptions, billing anchors, discounts, trials, tax IDs, payment references, and the audit trail around all of them.

Our migration design follows four rules:

1. Read-only import. Connecting an existing provider should not mutate it.
2. Idempotency. Every import step must be safe to resume or repeat.
3. Dry-run reconciliation. Teams should see mismatches before cutover.
4. Staged traffic. New checkout and recurring revenue do not need to move at the same instant.

The goal is not a dramatic midnight switch. It is a boring sequence of verified state transitions. Our Macropay vs Stripe page explains the operating-model differences and migration path side by side.

What about Stripe Managed Payments?

Stripe now offers Managed Payments, a Merchant-of-Record product for eligible digital products. According to Stripe's official documentation, it assumes responsibility for indirect taxes, fraud prevention, disputes, and transaction support for Managed Payments transactions. Stripe currently labels the product as public preview in its documentation.

That matters because "Stripe is never a Merchant of Record" is no longer an accurate comparison. The real decision is now between products, eligibility, pricing, integration model, usage-billing depth, margin visibility, and the rest of the operating workflow.

Macropay's position is narrower: an AI-first Merchant of Record where usage events, runtime budgets, entitlements, customer-level cost, billing, tax, and payouts share one ledger. Stripe's advantage is the breadth and maturity of its broader payments ecosystem. A useful comparison should acknowledge both.

When you should not switch

You may be better served by staying on Stripe when:

• your billing is primarily fixed subscriptions or straightforward seats;
• you already have reliable tax, finance, and dispute operations;
• you need payment products outside Macropay's supported scope;
• you value a broad integration ecosystem more than a unified revenue ledger;
• your current system is stable and the migration has no measurable business case.

Changing payment infrastructure carries real cost. "New" is not a business case. Fewer reconciliation failures, lower compliance overhead, safer global expansion, or better unit economics can be.

The decision framework

Start with the operating model. Decide who should be the merchant of record and who should own indirect-tax operations. Then map the complete revenue lifecycle from usage event to payout. Count every database, vendor, scheduled job, spreadsheet, and manual approval needed to keep that lifecycle correct.

If your current stack is coherent, keep it. If billing, product access, tax, and margin are separate versions of the truth, the question is not whether your processor can accept a card. The question is whether your company should keep operating the glue.

That was our answer. We moved beyond a standard Stripe stack because the glue had become the product. Macropay is that product, rebuilt as one system.