How Stripe Saved OpenCode From $323 Million in Fraud (And Why It Could Have Destroyed Them)

On August 25, 2026, a developer at Opencode named Dax posted something to X that stopped people mid-scroll. The screenshot showed a single number from the Stripe dashboard: $323,033,617.04 blocked in fraud in the past few days. Three hundred and twenty-three million dollars. The follow-up tweet made the stakes even clearer. This is much, much, much more than we make. If Stripe had let these through, it may have ended our company.

The product at the center of this story is OpenCode, an open-source AI coding agent. The plan being attacked is called OpenCode Go, priced at approximately ten dollars per month. The math of that combination, three hundred million dollars in attempted fraud against a ten-dollar subscription product, is the thing that requires a full explanation because the gap between those two numbers only makes sense once you understand how AI token economics work, how payment fraud has evolved to specifically target this category of business, and why the people running these attacks are operating sophisticated financial operations that have almost nothing to do with the product they are nominally purchasing.

The post generated 2 million views, 11,300 likes, and 344 replies. Many of those replies expressed amazement at the scale. But the number that actually tells the deepest story is not $323 million. It is the follow-up context Dax provided in the same thread. This batch is them distilling credit cards. They are trying to test which stolen cards work. That single clarification transforms the story from a company being attacked to a company being used as infrastructure for a completely different criminal enterprise, one that has been running at industrial scale for years and that has recently discovered AI subscription businesses as an optimal testing environment.

What OpenCode Actually Is and Why the Economics Make It a Target

To understand why OpenCode attracted this specific kind of fraud at this specific scale, you need to understand what the product is doing economically and why that economic structure creates an unusual attack surface. OpenCode is an open-source AI coding agent. The Go plan offers access to popular AI coding models, inference capacity, and token usage for approximately ten dollars per month.

The economics of delivering that plan require Dax and the team to negotiate deals with inference providers that allow them to offer substantially more usage value than the subscription price alone would suggest. One example they provided publicly is that the goal is for ten dollars to deliver approximately forty dollars worth of underlying inference value. The margin is thin to nonexistent at the planned usage level. The plan is designed to break even or produce minimal profit when legitimate users use it at expected rates.

This structure is the source of both the product's appeal and its vulnerability. Legitimate users get meaningful AI coding capability at a price that is dramatically lower than what they would pay accessing the same models directly through the underlying providers' APIs. The team achieves this through volume pricing negotiations. The arrangement works when usage matches expectations. When abuse occurs, the economic structure inverts immediately and catastrophically.

If fraudulent accounts access the platform at the same rate as legitimate users, the company pays the underlying inference costs without collecting the subscription revenue, because the subscription was paid with a stolen card that will be disputed. If fraudulent accounts access the platform at higher-than-expected rates, trying to extract maximum value before the account is banned, the losses scale proportionally. If the abuse reaches sufficient scale that payment processors observe elevated dispute rates, the merchant account itself becomes threatened, which is existential to any subscription business.

The sequence of anti-fraud actions Dax documented publicly tells the story of a business that has been fighting this problem at escalating scale throughout the summer of 2026. On July 20, they banned someone operating 8,000 fraudulent OpenCode Go accounts who was reselling $480,000 worth of tokens every month. On August 11, they obliterated 7,013 fraudulent accounts representing an estimated $400,000 per month in savings. On August 24, they removed a promotional intro offer because it attracted a crazy amount of abuse.

And then on August 25, the Stripe dashboard screenshot showed $323 million blocked in a few days. The escalation is not accidental. It reflects the dynamics of how fraud rings operate when they identify a profitable target. Each successful ban eliminates one set of accounts while providing the attacking operation with information about what triggered detection. The surviving accounts continue operating. New accounts are created to replace the banned ones. The volume scales upward as the operation becomes more sophisticated.

The Three Distinct Types of Fraud and Why Each Is Different

The fraud documented in dax's posts represents three different criminal activities that are related but not identical. Understanding each one separately is necessary to understand why the Stripe dashboard showed $323 million rather than a number one or two orders of magnitude smaller.

The first type is account farming for token resale. This is the simplest to understand conceptually. A fraudster creates multiple accounts on OpenCode Go, pays the ten-dollar monthly fee for each one, and then resells the token access to third parties at a markup. The resale price for AI tokens through underground markets reflects the cost of acquiring legitimate direct access to the same models, minus a discount that makes the resale attractive to buyers while still generating profit for the seller.

The operation that was banned on July 20 had 8,000 accounts and was generating $480,000 per month in resale revenue. The math implies an average of $60 per month per account in resale revenue against a $10 per month subscription cost. The margin is significant enough to justify the operational overhead of managing thousands of accounts and the risk of eventual detection and banning.

The challenge for this fraud type is account creation at scale. Creating 8,000 accounts requires either 8,000 email addresses or a system for generating and managing synthetic email addresses, 8,000 payment methods that successfully complete the subscription, and systems for managing the access credentials and routing the token usage to resale customers. The payment methods are the binding constraint. This is where stolen payment cards enter the picture.

The second type is direct token extraction and resale through account farming with fraudulent payment methods. This is the same model as above but executed without intending to pay the subscription at all. Fraudulent accounts are created using stolen payment card details. If the cards successfully complete the subscription charge, the fraudster receives the token access and begins reselling or using it immediately. When the real cardholder eventually notices the unauthorized charge and disputes it, the merchant, in this case OpenCode, faces a chargeback. The money is returned to the cardholder and the merchant faces chargeback fees. In the meantime, the fraudster has extracted the AI tokens.

This model scales more aggressively than the legitimate subscription resale model because the cost of the payment method is low compared to the value of what it unlocks. A stolen card that successfully completes a ten-dollar subscription charge costs the fraudster essentially nothing to obtain in bulk, while it unlocks access to forty dollars or more of underlying inference value. The constraint is having enough valid cards to complete enough subscriptions before detection.

The third type is the one dax specifically identified in his clarifying reply as the mechanism behind the $323 million figure: card distillation, also known as card testing. This is distinct from the subscription fraud and token resale operations in a crucial way. The fraudster is not primarily trying to obtain AI tokens. They are using the OpenCode subscription checkout as a testing environment to identify which of their stolen card numbers remain valid and usable.

Card Testing: Why $323 Million Is Not What It Sounds Like

Card testing is one of the most sophisticated and widespread forms of payment fraud, and understanding it explains why a company with modest revenue can face hundreds of millions of dollars in blocked fraud attempts without most of that figure representing money the company would have actually received. When criminal operations obtain large batches of stolen credit card data, through database breaches, dark web purchases, phishing operations, or other means, they face a practical problem.

Not all of the cards in a stolen database are still valid. Cards expire. Accounts get closed. Banks cancel cards preemptively when they suspect compromise. The useful cards, the ones that can complete successful charges and generate purchasing power before they are cancelled, need to be identified as efficiently as possible from the invalid ones.

Card testing solves this problem by running small test charges through legitimate payment processors. If the charge succeeds, the card is valid. If it fails, the card is not useful. The test transaction ideally involves a real merchant charging real amounts, because merchants that look legitimate to the payment processor are less likely to trigger fraud filters that would invalidate the test results. AI subscription products at low price points have become a preferred testing environment for several reasons.

The ten-dollar charge amount is small enough not to trigger immediate alerts from card issuers but real enough to produce a meaningful test result. The subscription model means a single successful charge commits the card to ongoing monthly billing, which extends the testing value. The merchant has a legitimate-looking online presence and established relationship with payment processors, which means charges to the merchant are less likely to be preemptively flagged as suspicious by the card issuer's fraud detection.

When Dax says they are distilling credit cards, the $323 million figure represents the total face value of the card charges that Stripe Radar identified and blocked as fraudulent before they could complete. The fraud rings submitting these charges are not expecting or even hoping that all $323 million will succeed. They are running what amounts to a systematic validation process across a large portfolio of potentially stolen card numbers. A success rate of even a few percent would identify millions of dollars worth of usable fraudulent purchasing power from a card database that cost a fraction of that to obtain.

The implications for the merchant are severe even when Stripe is successfully blocking the attempts. The volume of payment attempts represents computational load on the checkout infrastructure, which dax addressed by rate-limiting the API that generates the Stripe checkout in the first place. Elevated volumes of declined transactions can trigger risk reviews from payment processors. And the operational burden of monitoring, detecting, and responding to these attacks is itself a meaningful cost.

Why the Volume Is Measured in Hundreds of Millions Despite a Ten-Dollar Product

The gap between OpenCode Go's ten-dollar price point and the $323 million in blocked fraud is the detail that generates the most confusion in discussions of this story. People familiar with payment fraud understand it immediately. People who are not find it counterintuitive. The explanation requires understanding how card testing operations are scaled and incentivized. A criminal operation that has obtained a database of one million stolen card numbers needs to test those cards before they can be monetized.

If each test involves a ten-dollar charge attempt, and if the operation runs all one million cards through the test, the total face value of the attempts is ten million dollars. But modern card testing operations do not limit themselves to a single pass through a single database. They run multiple tests per card, they test across multiple merchants simultaneously, they refresh their databases regularly, and they operate continuously rather than as one-time events.

When a card testing operation discovers that a specific merchant, in this case OpenCode, is an effective testing environment, they scale up. The same efficiency that makes OpenCode Go attractive to legitimate users, low price, real payment processor integration, legitimate-looking merchant profile, makes it attractive to card testers. The fraud rings allocate computational resources and stolen card inventory to the testing opportunity and run it at maximum capacity until blocked.

The $323 million in a few days figure implies an operation running at extraordinary scale. If we assume an average test charge of ten dollars, that represents approximately 32 million charge attempts. If we assume tests were running for five days, that is approximately 6.4 million attempts per day. For an automated system, that volume is not particularly difficult to achieve. The infrastructure for submitting payment requests is cheap and scalable. The stolen card databases contain enough inventory to sustain that rate. The only binding constraint is detection and blocking, which is exactly what Stripe Radar did.

The clarification about rate-limiting the checkout API is significant because it shows how OpenCode's team responded operationally. Card testing operations rely on the ability to submit payment requests quickly and in volume. If the merchant rate-limits how frequently checkout sessions can be generated, it reduces the throughput of the testing operation and makes the testing environment less efficient. This does not stop the fraud entirely but it degrades the economics enough to push the operation toward less-protected testing environments.

How Stripe Radar Actually Works and What It Detected

Stripe Radar is the fraud detection system that blocked $323 million in attempts against OpenCode's payment flow. Understanding how Radar works contextualizes both its success in this case and the legitimate frustrations many users expressed in the replies to dax's post. Stripe Radar uses machine learning models trained on transaction data from across Stripe's entire merchant network. Because Stripe processes payments for millions of businesses, it has visibility into patterns that no individual merchant could detect on their own. A card that was used in a suspicious pattern at ten different merchants in the past twenty-four hours will be flagged when it is used at an eleventh merchant, even if that eleventh merchant has never seen the card before.

The models Radar uses evaluate dozens of signals simultaneously. Card number patterns that appear in known compromised databases. Velocity patterns where too many transactions originate from the same email address, IP address, device fingerprint, or card in too short a time period. Geographic anomalies where the cardholder's registered address is in one country but the purchase IP is in another. Behavioral patterns in how checkout sessions are initiated and completed.

Merchant-specific patterns where the ratio of declined to successful transactions exceeds normal parameters. Card testing operations specifically trigger velocity signals. When a single IP address or device submits fifty checkout attempts in an hour using fifty different card numbers, that pattern is highly anomalous and easy to detect. Sophisticated testing operations counter this by rotating IP addresses through proxies and VPNs, distributing the testing across many devices, spacing out submission timing, and using card numbers that have not yet appeared in known compromised databases.

The $323 million in blocked attempts suggests that Stripe identified the operation as fraudulent despite the countermeasures, which implies either that the operation was not using sophisticated evasion techniques or that the volume was so high that the velocity signals became detectable even with evasion. The $8.25 million in failed transactions, which represents a different category from blocked transactions, may represent the portion of attempts that reached further into the transaction process before being declined by card issuers rather than stopped by Stripe Radar.

Some of the community commentary in Dax's replies expressed skepticism about Stripe Radar's effectiveness, with users noting that it sometimes blocks legitimate customers. This frustration is genuine and well-documented. Radar's false positive rate, the proportion of legitimate transactions that get incorrectly flagged as fraudulent, affects real users who find their payments declined when they are trying to make a legitimate purchase. Other users in the thread reported needing to switch to specific payment methods like Revolut to successfully subscribe to OpenCode, which is a symptom of Radar's rules being calibrated aggressively in response to the fraud environment.

The tension between false positive rate and false negative rate is fundamental to fraud detection. A system tuned to block more fraud will inevitably also block more legitimate transactions. OpenCode's fraud environment, with hundreds of millions in attempted fraud, puts significant pressure on the calibration toward more aggressive blocking, which creates collateral friction for legitimate customers.

The Economics That Make Token Businesses Specifically Vulnerable

The specific vulnerability of AI token subscription businesses to this type of fraud has structural roots that are worth understanding because they apply to every company in this product category, not just OpenCode. Traditional subscription businesses, streaming services, software licenses, news subscriptions, sell access to a product that has effectively zero marginal cost per user. If a fraudulent account watches a million hours of video on a streaming service, the direct cost to the company is bandwidth and server load, not a proportional payment to an upstream supplier. The fraud creates indirect costs through chargebacks and potential account termination, but the primary product delivered is digital and the marginal cost is minimal.

AI token subscription businesses are fundamentally different. Every token consumed represents a real-time API call to an underlying model provider that charges based on usage. When OpenCode Go delivers forty dollars of inference value for a ten-dollar subscription, the additional thirty dollars of subsidy comes from the platform's negotiated pricing with providers. If a fraudulent account extracts ten times the expected token usage before being detected, and the subscription fee associated with that account is then charged back, the company has delivered $400 in upstream compute costs while receiving nothing.

This unit economics structure means that the severity of fraud is not just a function of the number of fraudulent accounts but of how aggressively those accounts extract tokens before detection. A fraud ring that creates accounts and immediately runs them at maximum token consumption, knowing the accounts will eventually be banned, is racing to extract maximum value before the window closes. The faster the fraud ring can consume tokens, the higher the losses before detection.

This is why dax specifically noted that higher-priced tiers, where legitimate users might expect even more token access for a larger subscription fee, are complicated by the reality that losses scale up with the tier. A fraudulent account on a one-hundred-dollar plan consuming four hundred dollars in inference before being banned inflicts four times the damage of a fraudulent account on a twenty-five-dollar plan. The economics of the attack scale with the economics of the product.

The intro offer that Dax mentioned removing on August 24 is a specific example of this dynamic. Promotional pricing is a standard growth tactic for subscription businesses, but in AI token economics, a discounted introductory period invites fraud rings to create accounts specifically to capture the promotional value. A free first month on a token subscription is not a free month of streaming access. It is a free month of extracting actual compute cost from the provider at zero revenue to the platform.

The Cat and Mouse Game That Has No Ending

Every anti-fraud action Dax documented publicly is part of an ongoing dynamic that has no permanent resolution. Understanding why requires understanding how fraud rings operate and adapt. When OpenCode bans 8,000 accounts operated by a single fraudulent actor in July, several things happen simultaneously. The fraudulent actor loses access to the accounts and the revenue stream they were generating. The actor analyzes what triggered detection and identifies the signals that led to the ban. New accounts are created that avoid those signals.

The operation resumes at a different scale using different identifiers. The pattern repeats. Each ban cycle provides information to both sides. The fraud team learns about the techniques being used. The fraud operation learns about the detection methods. The more sophisticated the fraud operation, the faster it adapts. The better the detection, the more sophisticated the fraud operation needs to become to continue operating. This is the cat and mouse dynamic that payment fraud researchers have documented for decades and that is now playing out in AI token businesses at scale.

Rate-limiting the checkout API, the specific mitigation dax mentioned in the thread, represents one move in this game. The fraud operation will respond by adapting its submission rate to stay below the limit, distributing across more IP addresses or devices to avoid triggering rate limits per source, or shifting to a different merchant testing environment where the rate limits are less aggressive. None of these adaptations eliminate the fraud. They relocate it and degrade its efficiency.

The August 25 Stripe dashboard screenshot, showing $323 million blocked, is not a victory announcement. It is a measurement of the current scale of the problem. Stripe blocked those transactions, which is the correct outcome. But the fraud operations that submitted them are still operational. They adapted to OpenCode being an effective testing environment, then found the environment rate-limited, and will adapt again to something else. The $323 million figure represents one period in an ongoing dynamic, not a final score.

Why the Reactions Split Between Awe and Skepticism

The two million views and 344 replies dax's post generated included a range of reactions that themselves reveal important things about how different communities understand payment fraud and AI business economics. The awe reaction, represented by the thousands of people who simply found the scale remarkable, reflects an intuitive response to large numbers in a context that seems disproportionate. A ten-dollar subscription product generating three hundred million in fraud attempts feels surreal. The number is real and the explanation for how it got that large is technically sound, but the gap between the price of the product and the scale of the attack is genuinely counterintuitive unless you understand card testing specifically.

The skepticism reaction, focused on Stripe Radar's limitations, reflects accumulated frustration from developers and businesses who have experienced false positives, where Stripe blocks legitimate customers, and from those who believe Radar's numbers are partly theatrical. This skepticism has some merit. Stripe's dashboard figures are reported by Stripe's own systems and represent their internal accounting of what was blocked. The specific definition of blocked, whether it represents charges that were submitted and rejected or estimated charges based on identified fraud patterns, affects the precise interpretation of the number. Community members who raised these questions were asking legitimate analytical questions.

The commentary about Stripe blocking legitimate customers alongside the fraud is particularly worth noting because it documents a real tension in OpenCode's situation. In the replies, users reported needing to switch payment methods to successfully subscribe, which suggests that Radar's aggressive calibration in response to the fraud environment was creating friction for people genuinely trying to use the product. This collateral damage is a hidden cost of operating in a high-fraud environment that does not show up in the dashboard screenshot.

The discussion about chargebacks revealed a common misunderstanding. Multiple replies assumed that if a fraudulent card successfully charged, the company would keep the money even when the real cardholder disputed the charge later. The reality is the opposite. Chargebacks result in the merchant returning the money to the cardholder, paying a chargeback fee to the payment processor, and potentially facing merchant account review if the dispute rate exceeds thresholds. A successful fraudulent charge that generates a later chargeback is worse for the merchant than a blocked fraud attempt, because it involves both revenue reversal and additional fees. The comment about legitimate customers being blocked by Stripe highlights a genuine operational challenge.

When fraud volumes are high, the calibration of fraud detection tends toward more aggressive blocking, which increases false positive rates. Some of the users reporting difficulty paying for OpenCode subscriptions with certain cards may be experiencing exactly this effect, where cards that are legitimate but match patterns associated with the fraud environment get blocked collaterally.

What OpenCode's Experience Reveals About the AI Infrastructure Moment

The broader context of OpenCode's fraud situation reflects something important about where AI tooling businesses sit in the current moment. The product is generating twelve trillion tokens in twenty-four-hour periods, handling infrastructure scaling challenges under high demand, and fighting fraud operations that are sophisticated enough to threaten the company's existence. All of this is happening while the team is simultaneously building product features, managing inference provider relationships, and communicating transparently with users about the economics and challenges of the service.

The scale of fraud activity directed at OpenCode is itself a measure of the product's success. Fraud rings target products that are worth attacking. A service with meaningful token value, established payment infrastructure, and growing user base is an attractive testing environment precisely because of those qualities. The fraud problem is, in a perverse way, a consequence of building something people want to use.

The token resale economy that emerged around OpenCode Go, with operations generating hundreds of thousands of dollars per month by arbitraging the difference between OpenCode's negotiated prices and direct API costs, reflects the same market dynamics that drive demand for the legitimate product. If tokens are genuinely more valuable than the price at which OpenCode offers them, both legitimate users and arbitrageurs will want them.

The difference is that legitimate users pay for them with real payment methods, while arbitrageurs use stolen cards or mass-created accounts to acquire them without cost. The challenge for OpenCode and every similar business is that the structural features that make the product valuable to legitimate users, low price relative to underlying value, established payment infrastructure, accessible subscription model, are exactly the features that make it attractive to fraud operations. The solution is not to eliminate those features. The solution is to build detection and prevention systems that are sophisticated enough to distinguish legitimate users from fraudsters faster and more accurately than the fraud rings can adapt.

The Practical Reality for AI Subscription Businesses Going Forward

What OpenCode's experience documents is a new reality for the category of AI subscription businesses that offer token access at negotiated prices. The economics that make these products attractive to users, meaningful AI capability at a fraction of direct API cost, also make them attractive to a growing ecosystem of fraud operations that have discovered AI tokens as a profitable commodity. Every business in this category faces the same fundamental challenge. The product delivers real value, which means fraudsters will attempt to obtain it at zero cost and resell it at a profit. The subscription model creates a testing environment for stolen cards, because a successful test charge commits ongoing billing. The margin structure means that fraud at scale can exceed revenue quickly, threatening viability.

The mitigations available are not novel. Rate limiting, device fingerprinting, email verification, phone verification, progressive account trust, delay between account creation and full access, fraud detection partnerships with processors like Stripe, manual review of flagged accounts, and rapid response to suspicious patterns are all documented techniques that the OpenCode team is clearly employing given Dax's public communications about specific anti-fraud actions.

What is new is the scale and sophistication of the operations these businesses face and the speed at which those operations adapt. The July operation with 8,000 accounts and $480,000 monthly was banned. A month later, a different operation with 7,013 accounts was banned. A month after that, $323 million in card testing attempts appeared in a single dashboard screenshot. The progression suggests fraud operations that are scaling their activity in response to both the opportunity and the increased difficulty of operating as defenses improve.

The public transparency that dax has maintained throughout this process, posting about bans, posting about the economics, posting about the fraud scale, is itself an interesting choice. It communicates to legitimate users that the platform is actively protecting its economics for their benefit. It signals to investors and observers that the team is aware of and addressing the problem. It contributes to public understanding of the fraud landscape facing AI businesses.

And it creates a record of the specific techniques and scales being used that the broader community can learn from. The $323 million number that stopped people mid-scroll is real. The mechanism that produced it is technically understandable. The threat it represented to a company built around a ten-dollar subscription product is genuine. And the fact that Stripe Radar blocked it, combined with the team's own rate-limiting mitigations, meant that OpenCode survived an attack that, in dax's own words, may have ended our company if it had succeeded.

That is what fraud at scale against an AI token subscription business looks like in 2026. It looks like three hundred million dollars in a few days, blocked by a payment processor's machine learning models, against a product that costs ten dollars a month and is genuinely trying to make AI coding tools accessible to developers who want them.