Anthropic Uses Stripe, Yet Reviews Billing In-House

Anthropic Uses Stripe, Yet Reviews Its Own Billing System

Stripe’s customer showcase describes how Anthropic uses Stripe’s products for payments, billing, and financial reporting. Early on, Anthropic relied on outside infrastructure so it could focus on product development, and as transaction volume grew, it improved how it sends revenue data to BigQuery. Stripe customer case study

Meanwhile, a job posting for Anthropic’s billing platform team describes the role as deciding which parts to outsource to external services and which parts to build in-house. Even while using a payment processor, Anthropic is putting its own engineers on its billing system.

In a previous issue, I covered Stripe’s agreement to acquire OpenRouter. Stripe is expanding into managing AI model usage and costs, and Anthropic—one of its major customers—is looking to handle some of that itself. It’s worth examining where these two moves overlap.

Billing systems cover more ground than card payments

Anthropic’s staff engineer job posting lists pricing configuration, payment flows, contracts and usage entitlements, and revenue data as responsibilities. It notes that the company relies heavily on external billing, payment, and tax platforms, and that the role involves deciding whether to extend those or build proprietary features instead. Billing platform job posting

The posting also covers payment authorization rates, retries, processing costs, dispute handling, and fraud prevention. You can’t conclude that Anthropic is only building billing calculations while leaving card processing entirely out of scope. Nor is this an announcement that it will replace external providers altogether. It’s a search for people who can judge how much to outsource and how much to control directly.

Collecting money from a card and calculating what a customer owes are related but distinct tasks. To generate an invoice for an AI API, for instance, you need to decide: which usage counts as billable, how unit prices apply to input versus output, and in what order discounts and prepaid credits get deducted.

The function that counts usage is called metering. The function that converts that usage into a dollar amount and issues a bill, based on pricing plans and contract terms, is billing. Even identical calls can result in different charges depending on cache usage, batch processing, or customer-specific discount terms.

A service company has to decide what to charge for and how much. That doesn’t mean it must build every part of that calculation itself. If an external product supports the necessary conditions, it can be used. But the company still needs to know which parts it can change on its own when it wants to modify its pricing plans.

Fraud prevention needs both payment and usage data

Anthropic’s financial fraud engineer job posting covers risk assessment at the point of payment authorization, along with refund/dispute handling and detection of trial and promotion abuse. It’s a role that works with payment processors, using signals like device information, transactions repeated in short bursts, and connections between accounts. Financial Fraud Engineer job posting

In AI services, compute costs can arise even without any payment being received. For instance, if someone repeatedly creates accounts to claim free credits and makes massive numbers of API calls, the service company ends up bearing the usage cost. This is a possible abuse scenario, not an actual damage figure disclosed by the job posting itself.

To address this problem, you need to connect card payment data with service usage data. That doesn’t mean stolen-card detection becomes unimportant, nor is free-benefit abuse unique to AI. It’s about adding whatever signals are needed depending on where the costs and losses actually occur.

External payment companies also offer fraud detection features. A Stripe customer case study describes how Anthropic used Radar’s risk scores together with its own rules to reduce false declines on legitimate transactions. This can be seen as a case of combining in-house capabilities with third-party tools.

Payment failures also need to be handled with distinctions. Temporary errors, card-information problems, and suspected fraud each call for different responses. Multiple payment routes can help in some cases, but having only one processor doesn’t mean retries are impossible. And blindly retrying through a different route doesn’t automatically improve approval rates, either. What’s needed is a combination of retry conditions and safeguards against duplicate payments.

You should also check whether you can actually switch payment providers

In its H1 2026 earnings release, Adyen listed OpenAI as one of its newly won major enterprise clients. That said, this announcement alone doesn’t tell us which functions of OpenAI’s existing payment provider were replaced. Adyen H1 2026 results

When a company adds or switches payment providers, it needs to figure out how to migrate card data and existing subscription contracts. That’s why where the data is stored matters so much. Using a separate vaulting service can help with connecting multiple payment providers, but that alone doesn’t mean you can swap providers easily whenever you want.

Conversely, just because a payment provider holds your card data doesn’t necessarily mean customers have to re-register their cards. Stripe offers a process for migrating card data to a new payment provider that meets certain security requirements. However, payment credentials stored in Link are excluded from the export. And the way card data versus payment history and subscription data get migrated also differs. Stripe’s guide to data migration

If it were me, before negotiating fees I’d first confirm what data can be migrated, which payment methods are supported, and how much time and engineering work the migration would take. You only gain real leverage in negotiations once you actually have a viable alternative to move to.

Stripe’s Expanding Business Overlaps With What Customers Build In-House

Stripe completed its acquisition of usage-based billing company Metronome on January 14, 2026. On August 19, it announced an agreement to acquire OpenRouter, which lets developers pick which AI model to route requests to and manage usage costs across them. Note that a completed acquisition and a signed agreement are different stages. Metronome acquisition completed, OpenRouter acquisition agreed

Stripe’s focus is expanding beyond the moment a customer pays — it’s now reaching into AI usage and cost tracking that happens upstream of that payment. This overlaps in part with the billing, pricing, and revenue systems work that Anthropic is hiring for.

It’s hard to draw a clean line here between features you should always buy and features you should always build. Even for the same metering function, the right choice can shift depending on customer count, contract complexity, engineering headcount, and how far third-party products’ coverage extends.

Function	What to check when evaluating a third-party service	What to check when evaluating in-house development
Payment processing	Supported countries, payment methods, fees, approval performance	Capacity to connect and operate multiple payment rails
Usage aggregation	Throughput, accuracy, latency, access to raw data	Aggregation rules unique to your own business
Pricing/contract management	Coverage of discounts, prepayment, usage-based terms	Frequency of pricing experiments and customer-specific exceptions
Usage entitlements	How contract changes link to actual service permissions	Real-time limits and suspension conditions
Fraud prevention	Signal available from external payment networks	Product usage history and cross-account relationships

Customers can build some features in-house while still using external payment and billing services. The fact that job postings and existing customer case studies coexist isn’t a contradiction — it just shows that the scope of what gets outsourced to third-party services can vary.

Cutting fees alone isn’t the point

As revenue and transaction volume grow, even a small difference in rates can turn into a large cost. So it’s only natural to review what you’re paying an outside vendor. But multiplying annualized revenue by some arbitrary rate doesn’t tell you what you actually paid. Payment methods, contract-specific discounts, and which products you use all change the real cost.

Building it yourself carries different costs. You need to hire and manage engineers, integrate tax and accounting systems, and handle bug fixes and customer support. You also have to account for refunds and lost trust when billing goes wrong.

A billing system isn’t something you build accurately once and then forget. It has to distinguish before-and-after pricing changes, honor legacy contracts, prevent double-counting, and give customers a clear basis for their questions. That’s exactly why Anthropic’s job posting emphasizes consistency checks, audit trails, and operational accountability — these all tie back to that same body of work.

Neither an IPO in the works nor fee savings alone can fully explain why a company would consider building its own system. The demands revealed in the posting span product launch speed, contract handling, payment performance, and the accuracy of revenue data.

Oswarld’s Lens

Watching this news, I found myself rethinking the criteria software companies use to decide what to buy versus what to build in-house. In particular, I’d argue that the rules governing what you charge customers are part of the product itself.

A flat monthly plan and a plan where usage, discounts, and limits vary by customer require fundamentally different calculations. Even if you hand off pricing configuration to a third-party product, the company still needs to be able to explain what outcomes that configuration produces for its customers.

As usage scales and contracts grow more complex, a single unsupported condition can block a pricing experiment. This, I think, is exactly where the case for building in-house emerges. You have to weigh not just the cost of using an external product, but the cost of not being able to ship the pricing plan you want, when you need it.

Among domestic SaaS and AI services, it’s common to see a setup where payments are outsourced to a PG (payment gateway) while usage is tallied in an in-house database. That design isn’t inherently flawed. What matters is whether the tallying is accurate and whether you can reproduce the basis for a charge even after the pricing changes.

When agents automate repetitive tasks, one user’s consumption can spike within a short window. So it’s not just what you count that needs defining alongside your pricing policy — when limits kick in and under what conditions things get cut off need to be decided together with pricing, too.

When a customer disputes a charge, simply dumping a log of API calls may not count as a sufficient explanation. You need to be able to show which pricing rule applied to which task, and how discounts and credits were calculated. Whether this evidentiary trail is generated by your own code or received from an external system, I believe the company still has to be able to verify and explain it.

If Reader is running a usage-based or credit-based pricing plan, try checking whether you can recompute a single customer’s bill from the raw usage records. Going through that exercise will make it much clearer which parts you can safely outsource and which parts you need to control directly.

💬 Where does your service currently calculate usage and billing amounts? If you’ve ever run into a system limitation while trying to change a pricing plan, I’d love to hear about it.

References & Further Reading

• Anthropic’s job posting for a billing platform staff engineer.
• Anthropic’s job posting for a financial fraud engineer.
• Stripe’s customer case study on Anthropic.
• Stripe’s announcement of completing its Metronome acquisition, January 14, 2026.
• Stripe’s announcement of its agreement to acquire OpenRouter, August 19, 2026.
• Stripe’s guide to payment data migration.

Related past issues

• Stripe’s deal to acquire OpenRouter and the challenge of managing AI usage
• The difference between subscription, usage, and outcome-based pricing

The author is Oswarld (Kwangseob Ahn). Current roles: Adjunct Professor at Sejong University, Strategy Consultant at INLEVEL9. Career, research, books, and recent work are kept current on the About page. Latest · July 2026: HEMA-2: A Consolidation-Aware Tri-Memory Architecture with Multi-Channel Scheduling for Lifelong Conversational AI.