The technology is not going away. The easy money is. Here is what changes over the next 24 months.

Your feed says AI will take your job.
Your boss says AI is the future.
Your investment app says AI just lost a trillion dollars in a day.
All three can be true at the same time.

On 26 October, Reuters ran a headline saying China’s AI bubble had already burst. Four days later, the Nasdaq had its worst day since June, and Intel had its worst day since 1974.

If you build software, manage a team, or just want to know whether your career is safe, you need to understand what happened. This article explains it in plain English: what broke, which companies took the hit, and what the next one to two years probably look like.

A quick note on the word “burst.” In China, the numbers fit it. In the USA, the more honest word is “crack.” The damage is real, but the debate about what comes next is still wide open. I will show you both sides.

All market data is as of the close on Friday, 30 October 2026. Prices move fast, and this is not financial advice.

1. China: The Bubble That Popped First

For two years, Chinese savers were encouraged to move money into stocks. Beijing wanted a calm, steady “slow bull” market that would help fund the AI boom. What it got, in the words of one Beijing fund manager quoted by Reuters, was a speculative crazy bull.

Here is how it ended:

• The STAR 50 index, which tracks China’s AI and chip leaders, fell about 40% in under four months. Reuters estimated that wiped out roughly $480 billion.
• By 30 October the index closed at its lowest level this year, about 47% below its 30 June peak.
• China’s broad blue-chip index, the CSI 300, entered a bear market, which means a fall of 20% or more from its high.
• Goldman Sachs says AI-related stocks had grown to 42% of China’s total market value and 57% of trading volume. When one theme is that big, its fall hurts everyone, not just AI investors.

Retail excitement made it worse. Robot maker Unitree’s share sale was 8,000 times oversubscribed when it listed in August. The stock has since lost about half its value.

Prices were also stretched. At its peak, the STAR 50 traded at roughly 250 times its earnings. After the crash it is still near 100 times, compared with about 30 times for the Nasdaq-100.

The plot twist: profits went up and the stocks still fell.

Cambricon, often called China’s answer to Nvidia, reported nine-month revenue up 106.8% and profit up 131.5%. Its shares are still about 45% below their 30 June peak. Why?

• Its inventory grew 136% since December.
• Inventory write-downs jumped from RMB 87 million to RMB 502 million.
• The stock still trades at about 116 times its yearly profit.

Another example is CXMT, a Chinese memory chipmaker. Reuters reported that only 20% to 30% of its advanced HBM chips are usable, compared with about 70% at SK Hynix. Good headline growth does not help if the product has quality problems.

Pro tip: When great earnings cannot lift a stock, the price was already assuming perfection.

Why this matters:

• Fast growth and overpricing can exist together. China’s chip firms are proof.
• Too much of one theme in one market turns a sector problem into a national one.
• Morgan Stanley expects offshore Chinese stocks to fall another 10% to 15% before they bottom, so the pain may not be over.

2. USA: Not a Collapse, but a Very Loud Crack

The Nasdaq hit a record close on 6 October. By 30 October it was 7.8% below that peak and had just finished its worst month since March 2025. Most of the damage came in three days.

Alphabet’s report shows the strange mood. Its cloud business grew 103%. Revenue rose 25% to $127.6 billion. Yet the stock crashed, because of two numbers: it spent $51.4 billion on equipment and data centers in one quarter, and its free cash flow turned negative at $9.1 billion.

Free cash flow is the money left after a company pays its bills and its investments. When it goes negative, the company must borrow money or sell new shares to keep spending.

That is exactly what is happening elsewhere:

• Meta reported its first negative free cash flow in more than ten years and plans to raise up to $95 billion in new shares.
• Amazon’s free cash flow over the last 12 months was negative $42.4 billion, with its online retail growth at a three-year low.
• On Friday alone, chip stocks lost roughly $1 trillion in market value at one point in the morning, according to Benzinga’s tally. Intel’s warning about weak PC demand set it off.

Bloomberg described the mood as the start of a “show me” phase. Investors used to ask for a good AI story. Now they ask for profit.

Why this matters:

• The spending is enormous. Goldman Sachs expects the five biggest cloud companies to spend about $800 billion in 2026, $1.2 trillion in 2027, and $1.4 trillion in 2028. It estimates they need about $300 billion a year in AI revenue to justify that.
• The gap is being filled with debt and new shares. The IMF says these companies now make up about 10% of high-quality bond sales, up from under 1% in 2024.
• Investors are not punishing AI demand. They are punishing cash burn. Microsoft, which still makes positive free cash flow, barely moved.

3. Ten Companies at the Center of the Storm

This is not an official ranking. It is ten of the most closely watched names in the AI trade, mixing the USA, China and Korea.

Also in the blast zone: Intel (-28.6%, but still up about 78% this year), AMD (down roughly 7% to 11% on Friday, depending on the tally), CoreWeave (-9.7%), Dell (-10.8%), and Unitree (down about half since its August listing).

Look at the pattern. The biggest falls hit companies where hopes ran far ahead of cash. The calmest name on the list, Microsoft, is the one that actually produces cash while it spends.

4. So, Is It Really a Bubble?

Smart people disagree, and the evidence points both ways.

The IMF has said the world economy is standing on one leg, the AI leg. Its downside model, where AI investment drops sharply, cuts global growth by 1.1% by 2028 and US output by 1.8%. That is painful, but the IMF says even its worst AI case is unlikely to cause a global recession.

My reading: the technology is real, the profits at some companies are real, and the prices and the funding methods got ahead of both. That is how most bubbles look. The dot-com crash did not stop the internet. It removed the companies that could not pay for themselves.

5. What This Means for Companies in the Next 1 to 2 Years

The problem you have been avoiding: Many companies bought AI first and measured it later.

What changes:

1. Every AI project needs a receipt. Boards will ask what each project earns or saves, in money. Expect pilots without clear numbers to be cut in 2027.
2. Money gets more expensive. With the 10-year US bond yield near 5% and a possible Fed hike, borrowing to fund AI gets harder. Reports say tighter financing has already pushed some planned IPOs onto the shelf.
3. AI vendors may change prices or terms. If your AI supplier loses its cheap funding, it may raise prices, cut free limits, or merge with a rival. Even the AI labs are heading to public markets: Anthropic has filed for an IPO, and CNBC reported that its filing raised eyebrows.
4. The gap between cash-rich and cash-burning firms widens. Companies that fund AI from real profit will keep investing. Companies that fund it by borrowing will cut costs, including jobs.
5. The supply chain feels it. Chipmakers, memory makers, server builders and data-center suppliers all depend on the same spending plans.

Here is a practical way to protect your product. Build a thin gateway between your app and any AI vendor, with a fallback and a hard budget limit:

from dataclasses import dataclass
from typing import Callable, Tuple


@dataclass
class Provider:
    name: str
    cost_per_1k_tokens: float                      # USD; keep in config so finance can update it
    call: Callable[[str], Tuple[str, int]]         # returns (text, tokens_used)


class BudgetExceeded(Exception):
    pass


class LLMGateway:
    def __init__(self, providers: list[Provider], monthly_budget_usd: float):
        self.providers = providers                 # ordered: preferred vendor first
        self.budget = monthly_budget_usd
        self.spent = 0.0

    def complete(self, prompt: str) -> str:
        last_error = None
        for provider in self.providers:
            # A hard stop beats a surprise invoice when vendor prices jump.
            if self.spent >= self.budget:
                raise BudgetExceeded(f"Spent ${self.spent:.2f} of ${self.budget:.2f}")
            try:
                text, tokens = provider.call(prompt)
                self.spent += tokens / 1000 * provider.cost_per_1k_tokens
                return text
            except Exception as err:               # outage, rate limit, vendor shutdown
                last_error = err                   # one vendor failing must not take your product down
        raise RuntimeError("All AI providers failed") from last_error

Pro tip: Track AI cost per feature, not per vendor. When the board asks “what does this earn?”, that is the number you will need.

Why this matters:

• No more single-vendor dependency for a feature your customers rely on.
• Cost surprises become alerts instead of invoices.
• You can switch providers in days, not quarters, if prices or terms change.

6. What This Means for People Who Write Software

Let’s separate the noise from the facts.

What we know:

• Tech trackers counted roughly 170,500 tech layoffs across about 480 events in 2026 as of late July.
• Challenger, Gray & Christmas data shows AI was blamed for about 7% of job cuts in January and about 40% by May.
• Stanford HAI data, as reported by TechTimes, shows software developer employment for workers under 26 fell nearly 20% since 2024.
• Oracle’s cuts, around 30,000 roles in 2026, were reported as a way to stem a cash drain from AI infrastructure spending.

What is still debated: how much of this is truly AI replacing work, and how much is AI used as a reason for cuts that came from over-hiring or cost pressure. One analysis argues the AI label is partly a story that investors reward.

Here is the part most people miss. Many companies cut staff in order to fund AI spending. If the money for AI gets tighter, the cash-burning companies have two options: cut spending, or cut people. Expect both.

Where the risk is higher:

• Roles at startups whose only product is a thin wrapper around someone else’s AI model, and whose funding depends on the next big round.
• Entry-level roles, where companies are already hiring fewer people.
• Jobs whose main title is “AI” but whose output nobody can measure.

Where the ground is firmer:

• Roles tied to revenue and reliability: data engineering, testing and quality, security, and site reliability.
• Engineers who can measure what AI actually delivers, and who understand its cost.
• People with deep knowledge of a specific industry, such as property, payments or healthcare, who can judge if an AI answer is right.

Why this matters:

• A bubble bursting does not delete the tools. The dot-com crash did not stop the web, and it will not stop AI coding assistants.
• What changes is who gets paid to use them, and how carefully the work is checked.
• Verified, tested, cost-aware work becomes more valuable when budgets tighten, not less.

7. Three Paths for the Next 24 Months

These are scenarios, not predictions. Any of them could be wrong.

In my reading of the evidence, the grind is the most likely path. The demand numbers are too strong for a hard bust, and the funding strain is too visible for a calm soft landing. That is a judgment, not a forecast.

What to watch:

• 3 Nov: AMD earnings.
• 10 Nov: CoreWeave results, a read on AI cloud demand and debt.
• 17 Nov: Nvidia earnings, the biggest single test.
• 9 Dec: The Fed’s decision on a possible rate hike.

Quick Wins: Five-Minute Moves This Month

1. Find your AI cost per feature — one query tells you where the money goes.

-- Which features use the most AI budget? Run monthly.
SELECT feature_name,
       SUM(total_tokens) / 1000.0 * 0.002 AS est_cost_usd,   -- replace with your vendor's rate
       COUNT(DISTINCT user_id)            AS active_users
FROM llm_usage_log
WHERE created_at >= DATE_TRUNC('month', CURRENT_DATE)
GROUP BY feature_name
ORDER BY est_cost_usd DESC;

Reach for it before any budget meeting.

2. Pin your model versions and name a fallback — so a vendor change never surprises you.

llm:
  primary:  { vendor: vendor_a, model: model-v3, pinned: true }
  fallback: { vendor: vendor_b, model: model-v2, pinned: true }
  monthly_budget_usd: 5000
  alert_at_percent: 80

Use it when you set up any new AI feature.

3. Keep a proof-of-impact log — write down what your work saved or earned, in numbers, every month. It is the best defense in a layoff round and the best answer in a review.

Key Learnings

What this moment is really saying is:

• Profit is the new password. The market stopped rewarding AI stories and started rewarding AI cash flow. Microsoft held up. Cash burners did not.
• Good earnings are not enough. Cambricon doubled revenue and still fell 45%. Price matters as much as growth.
• Concentration is the hidden risk. When 42% of a market is one theme, there is no place to hide inside it.
• Funding, not demand, is the weak point. Cloud growth is strong. The worry is how the spending is paid for.
• The technology survives, the weakest businesses do not. That was the dot-com lesson, and it likely applies again.
• Vendor risk is now a design problem. Build fallbacks and budget limits into your systems today.
• Measured work wins. In tighter budgets, engineers who can prove impact are the last ones anyone wants to lose.

A glowing lightbulb, the moment an idea clicks

References

• In China, the AI bubble has already burst (Reuters via Yahoo Finance)
• AI Bubble Bursts in China, Wiping $480 Billion: Is America Next? (Yahoo Finance)
• China’s AI Bubble Bursts With $480 Billion Wiped Out (Yahoo Finance)
• Wall Street closes sharply lower as AI cash burn fears spark tech selloff (Reuters)
• Nasdaq suffers worst month in over a year as AI nerves roil markets (CNN)
• Tech Stocks Plunge as Wall Street Enters ‘Show Me’ Phase (Bloomberg)
• The AI investing story had a rough week (CNBC)
• Chip Stocks Wipe Out $1 Trillion in Friday Bloodbath (Benzinga)
• AI Bubble: What Alphabet’s Results Mean Before Nvidia Reports (Admirals, summarizing IMF, Goldman Sachs and company filings)
• Growth Dragons Weekly: Cambricon, HSBC, WuXi AppTec and ZTE
• From boon to burden: AI spending woes leave Kospi among worst-performing major indexes (Korea JoongAng Daily)
• Tech Layoffs 2026: 170,000 Cut, Is AI to Blame? (Tech Journal)
• Tech Layoffs Reach 142,000 in 2026 (Tech Times)
• Trading Economics: United States Stock Market

Which path do you think we are on: digestion, the grind, or a hard bust? And has your team already changed how it budgets for AI? Tell me in the comments.

The AI Bubble Just Cracked: What China’s Crash and Wall Street’s Worst Weak Mean for Your Job and… was originally published in Syntest on Medium, where people are continuing the conversation by highlighting and responding to this story.

You do not need to be an automation expert to start automating repetitive UI tests. If you understand your product, know the expected behavior, and can write clear manual test cases, Claude, Playwright MCP, Playwright, and TypeScript can help you turn repetitive manual flows into reusable automated tests.

The idea is simple:

You define the behavior. Claude helps translate it into automation. Playwright MCP helps Claude understand the real application. Playwright runs the final tests independently.

What You Need

A practical setup can start with:

• A paid Claude account
• Claude Code
• Node.js
• Playwright with TypeScript
• Playwright MCP
• A CLAUDE.md file
• Markdown documentation containing your test cases

You do not need to memorize the Playwright API before starting. You do need to know what should be tested and what the correct result should be.

Start With CLAUDE.md

CLAUDE.md acts as the instruction manual for Claude when working inside your automation repository.

Instead of repeatedly explaining your project rules, you document them once.

It can define:

• Project structure
• Testing conventions
• Locator preferences
• Browser and device coverage
• Reusable helper expectations
• Rules around waits and retries
• Test isolation requirements
• How test data should be organized

For example, you can define rules such as:

• Prefer accessible roles, names, and visible text instead of fragile selectors.
• Every test should run independently.
• Avoid fixed waits unless there is a valid reason.
• Keep reusable interactions outside individual test files.

Claude can then follow these instructions whenever it creates or modifies tests.

Keep Your Manual Test Cases in Markdown

The next piece is your existing QA knowledge.

Write the repetitive scenarios you already test manually in Markdown files inside a docs folder.

A test case only needs to clearly describe:

Precondition → User actions → Expected result

For example:

Scenario: User closes the player and restores it

Precondition:
The player is visible on the page.

Steps:
1. Close the player.
2. Verify the minimized state appears.
3. Click the minimized state.

Expected:
The full player should be restored.

This tells Claude what the test should do and what result to expect. The better your test cases describe the real user journey, the better the generated automation will be.

Where Playwright MCP Helps

Playwright MCP allows Claude to interact with the live application instead of guessing how the UI works.

Claude can use MCP to inspect:

• Clickable elements and controls
• Accessible roles and names
• Navigation and page changes
• DOM changes after interactions
• Suitable locators and assertions

For example, your test case may say:

Open Products
Select an item
Open the player
Close the player
Verify the minimized state

Claude already understands the expected journey from your documentation. Using Playwright MCP, it can explore the actual website and map those steps to the real UI. This reduces the manual work of finding and choosing locators.

MCP Is for Exploration. Playwright Is for Regression.

This distinction is important. Playwright MCP helps Claude understand the application while building the automation.

It should not be required every time the regression suite runs.

Once Claude understands the flow and locators, it converts that knowledge into normal Playwright tests.

For example:

test('user can close and restore the player', async ({ page }) => {
  await page.goto(testUrl);

  await player.open();
  await player.close();

  await expect(player.minimizedState).toBeVisible();

  await player.restore();

  await expect(player.fullPlayer).toBeVisible();
});

At this point, Claude and MCP are no longer required to execute the test.

It is now a normal Playwright test inside your automation repository.

Run the Tests Normally

Once the generated automation has been reviewed, you can execute it like any other Playwright project.

Run the complete suite:

npx playwright test

Run a specific test file:

npx playwright test tests/player.spec.ts

Run a specific browser project:

npx playwright test --project=chromium

This is where AI-assisted automation becomes regular automation.

Claude helped create the tests, MCP helped explore the application, and Playwright now runs them independently.

The Complete Workflow

The entire process can be summarized as:

Manual QA knowledge
        ↓
Markdown test cases
        ↓
CLAUDE.md project instructions
        ↓
Claude
        ↓
Playwright MCP explores the application
        ↓
User journey and locators are identified
        ↓
Claude generates Playwright + TypeScript tests
        ↓
QA reviews the tests
        ↓
npx playwright test
        ↓
Reusable automated regression

AI is not deciding what the product should do. QA defines the expected behavior. Claude and MCP help convert that knowledge into automation faster.

What This Can Save

In my case, UI regression that took more than four hours manually after bug fixes could run in roughly 16 minutes through Playwright. The exact savings will vary by project, but the benefit is the same: less time repeating predictable UI checks and more time for exploratory testing, analytics validation, real-device testing, and investigation.

What AI Does Not Replace

This approach does not remove manual QA. Claude does not know what correct product behavior is unless you define it.

A QA engineer still needs to:

• Define expected behavior
• Select meaningful coverage
• Review generated tests
• Challenge incorrect assumptions

Automation should handle the predictable repetition. QA should spend more time on the unpredictable parts.

Start Small

You do not need to automate your entire regression suite. Start with a few repetitive scenarios, document the expected behavior, define your rules in CLAUDE.md, and let Claude use Playwright MCP to explore the application and generate the tests. Review the output, then run it with npx playwright test. QA thinking still comes first. Claude and Playwright MCP simply make the path to reusable automation much shorter.

How Manual QA Engineers Can Automate Repetitive Tests with Claude and Playwright MCP was originally published in Syntest on Medium, where people are continuing the conversation by highlighting and responding to this story.

Testing Stripe is not just about entering a test card and checking whether a payment succeeds.

Behind a successful payment are customers, subscriptions, prices, invoices, PaymentIntents, webhooks, usage events, billing cycles, and application workflows that must stay in sync.

That is where Stripe testing becomes interesting.

A payment can succeed while the application still fails to activate the customer’s plan. An invoice can remain in Draft. A webhook can fail. Usage can be reported twice. A subscription can behave perfectly during signup but fail during its first renewal.

I learned very quickly that testing the payment itself is often the easiest part.

This guide is based on hands-on QA work testing subscription billing, usage-based pricing, invoice lifecycles, webhooks, renewals, and Stripe Test Clocks in Sandbox environments.

The goal is not to explain every Stripe feature. It is to explain the parts a QA engineer needs to understand to test a billing integration properly.

At a high level, a complete Stripe test should validate this flow:

Subscription → Invoice → Payment → Webhook → Application State

For usage-based products, another important flow is:

Application Usage → Meter Event → Meter → Usage Based Price → Invoice

Stripe Sandbox vs Live Mode

Stripe provides Sandboxes so teams can test billing behavior without processing real transactions.

Sandbox and Live environments have separate data and API keys. Customers, subscriptions, invoices, and other objects created in a Sandbox are isolated from Live Mode.

For QA, the Sandbox is where you can test scenarios such as:

• Subscription creation

• Successful and failed payments

• Invoice generation

• Usage-based billing

• Webhooks

• Renewals

• Trial expiration

• Test Clocks

All examples in this guide use a Stripe Sandbox.

The Stripe Billing Architecture QA Engineers Need to Understand

Before testing individual scenarios, it helps to understand how Stripe’s main billing objects relate.

A simplified subscription flow looks like this:

Product → Price → Subscription → Invoice → PaymentIntent → Payment

A Product represents what is being sold.

For example, a Product could be a Pro Plan.

The Product has one or more Prices that determine how the customer is charged.

A Price might define a charge of $9 per month.

When the customer subscribes, Stripe creates a Subscription that references the relevant Price and belongs to a Stripe Customer.

At each billing cycle, Stripe generates an Invoice.

For automatically collected payments, Stripe uses the payment workflow associated with the invoice to attempt collection. PaymentIntents are commonly involved in tracking that payment lifecycle, including additional authentication requirements or payment failures.

The important point for QA is that these objects should not be tested independently.

If an invoice is incorrect, check the subscription and prices.

If payment succeeds but the application does not update, check the webhook.

If usage charges are incorrect, inspect the meter events before blaming the invoice.

What QA Should Check in the Stripe Dashboard

You do not need to know every section of the Stripe Dashboard to test an integration.

The areas I use most frequently are:

Customers

Check the customer’s subscription, invoices, payment methods, and billing history.

Product Catalogue

Verify products, fixed prices, usage-based prices, and pricing tiers.

Billing

Inspect subscriptions, invoices, meters, usage, and Test Clocks.

Developers or Workbench

Investigate API requests, events, webhook deliveries, and integration failures.

During debugging, I usually move between the application, Stripe Dashboard, webhook events, and backend logs rather than relying on only one source.

That cross-checking becomes especially important when Stripe shows a successful operation, but the application is in the wrong state.

Understanding the Subscription Billing Cycle

A subscription’s billing period depends primarily on its recurring Price and its billing cycle anchor.

For example, if a monthly subscription is anchored to January 1, the next renewal would normally occur on February 1.

Stripe uses the billing cycle anchor to align future billing dates.

This matters because many defects only appear during transitions between billing periods.

A new subscription may work perfectly while the following renewal fails because of incorrect usage, missing payment methods, failed payment retries, invoice finalization problems, webhook failures, or application renewal logic.

For that reason, testing only initial subscription creation is not enough.

You should always test at least one renewal.

Understanding the Stripe Invoice Lifecycle

Invoices are one of the most useful objects for debugging Stripe billing.

The main states QA engineers should understand are:

Draft

The invoice has been created but has not yet been finalized. Certain details can still be changed.

Open

The invoice has been finalized and is awaiting payment.

Paid

The invoice has been successfully paid.

Void

The invoice has been cancelled and will no longer be collected, although it remains in the billing history.

Uncollectible

The invoice remains unpaid and has been marked as unlikely to be collected.

A typical successful flow might look like this:

Draft → Open → Paid

For automatic collection, Stripe normally waits after the invoice.created event before attempting payment.

One important QA case is webhook failure. If Stripe does not receive a successful response to invoice.created, automatic invoice finalization can be delayed significantly.

That means an invoice stuck in Draft is not necessarily an invoice calculation problem.

It may be a webhook problem. That distinction can save a lot of debugging time.

How Stripe Collects Subscription Payments

Stripe subscriptions commonly use one of two collection approaches.

Charge Automatically

Stripe attempts to collect payment using the customer’s saved payment method. This is common for SaaS subscriptions and recurring plans.

Send Invoice

Stripe sends an invoice to the customer and expects the customer to pay it before the configured due date.

From a QA perspective, always verify which collection method is configured.

A subscription behaving differently from what you expect may simply be using a different payment collection configuration.

Building a Stripe Setup for Testing

To make the examples easier to follow, consider a subscription that contains two components:

1. Fixed monthly plan
2. Usage-based session billing

The fixed plan charges the customer every month.

The usage-based component allows a certain amount of usage for free and then charges for additional usage.

Step 1: Create the Customer

First, create a Stripe Customer.

Example:

Customer: John Doe

Customer ID: cus_xxxxxxxxxxxxx

The Stripe Customer ID becomes extremely useful when tracing subscriptions, invoices, payments, meter events, and backend records.

Step 2: Configure the Usage-Based Price

Suppose the product allows the first 500 sessions for free and charges $0.01 for every additional session.

A graduated pricing model could be configured so that:

1. 500 sessions = $0.00
2. 501 sessions = $0.01
3. 600 sessions = $1.00
4. 800 sessions = $3.00

For QA, boundary testing is especially important here.

Do not only test a large usage number.

Test values around the pricing boundary:

499, 500, 501

Those three values can expose tier calculation defects immediately.

Step 3: Create and Configure the Meter

A Stripe Meter defines how reported usage events are aggregated during the billing period.

This distinction is important.

Meters attach to usage-based Prices rather than directly to Products.

Depending on the billing model, a meter can aggregate usage using methods such as Count, Sum, or Last.

For example, if an application bills based on individual session events, the application may report one eligible billable event per session and Stripe can count those events for billing.

QA should verify both sides of this flow:

Application calculation → Meter events sent to Stripe → Aggregated Stripe usage

Do not assume that seeing the correct final invoice proves that usage reporting is correct.

Step 4: Create the Subscription

The subscription can now contain both components:

1. Fixed Plan
2. Session Usage

This is an important testing scenario because the final invoice can include both predictable recurring charges and variable usage.

QA should verify that each subscription item references the correct Price.

How to Test Stripe Webhooks

This is where some of the most interesting Stripe bugs appear.

Consider this situation:

Payment succeeded. The customer still could not use the product.

At first glance, that sounds like a payment problem.

But imagine Stripe successfully collects the payment and generates the correct invoice while the application never receives, or never successfully processes, the webhook responsible for updating the customer’s account.

Stripe is correct. The application is not.

That is why checking only the Stripe Dashboard can give QA a false sense of success.

A Real-World Example

In one implementation I tested, every new customer was supposed to receive an included session allowance after signup.

The expected billing workflow depended on an invoice event being processed successfully.

During testing, the invoice remained in the Draft state, which prevented the expected downstream workflow from completing.

From the customer’s perspective, signup appeared successful.

From Stripe’s perspective, the relevant objects had been created.

But the application never enabled the expected allowance.

The root cause was not the visible signup flow. It was the billing and webhook lifecycle behind it.

Whenever I investigate a Stripe issue, I check three things:

1. Was the expected Stripe event generated?
2. Was the webhook successfully delivered?
3. Did the application successfully process it?

A successful payment doesn't automatically mean your application’s billing state is correct.

A Webhook Failure QA Teams Should Specifically Test

The invoice.created event is especially important for subscription billing.

If Stripe cannot successfully deliver this event to the relevant webhook endpoint, automatic invoice finalization can be delayed for up to 72 hours.

That creates a valuable negative test.

1. Reject or fail the webhook.
2. Trigger invoice generation.
3. Inspect the invoice status.
4. Check how the application behaves.

Your application should not silently enter an inconsistent state simply because a webhook failed.

How to Test Stripe Renewals with Test Clocks

Waiting an entire month to test a monthly subscription renewal is obviously impractical.

That is where Stripe Test Clocks are useful.

A Test Clock allows QA engineers to simulate the passage of time for supported Sandbox objects.

Instead of waiting weeks, you can move the subscription forward and test what happens when:

• A trial expires
• A subscription renews
• A new invoice is generated
• Usage is billed
• Payment collection occurs
• Webhooks are triggered

When you advance a Test Clock, Stripe processes the affected objects asynchronously.

Do not validate the results while the clock is still advancing.

Wait until its status returns to Ready.

At that point, the Test Clock objects have advanced to the requested frozen time, and you can inspect the resulting subscription, invoice, payment, and webhook behavior.

The Test Clock has advanced successfully, and the subscription is now frozen at the new simulated time, ready for the next billing event or further time advancement.

My QA Approach to Test Clocks

When testing a renewal, I normally verify all of the following.

Before advancing:

1. Subscription status
2. Current billing period
3. Current invoice
4. Reported usage
5. Expected next billing date

After advancing:

1. New billing period
2. New invoice
3. Invoice amount
4. Payment result
5. Subscription state
6. Webhook events
7. Application customer access

This makes the test much more valuable than simply checking whether a new invoice appeared.

How Stripe Usage-Based Billing Works

Fixed subscription pricing is predictable.

Usage-based billing adds another system into the equation.

Your application must tell Stripe what the customer actually used.

Stripe does not automatically know that a customer consumed 600 API calls, watched 20 videos, generated 80 reports, or used 1,200 sessions.

Your application reports billable usage to the configured meter.

The meter aggregates those events.

The usage-based Price determines what the aggregated usage costs.

Stripe then incorporates the calculated amount into billing.

The flow becomes:

Customer activity → Application → Meter Event → Meter → Price → Invoice

For QA, every part of that chain matters.

Automatically Reporting Usage

In production, applications typically send meter events through Stripe’s API when billable activity occurs.

Each event identifies the relevant usage and customer.

Suppose a customer uses 600 sessions during a billing period.

If the first 500 sessions are free and each additional session costs $0.01:

Billable usage = 100

Usage charge = $1.00

QA should verify:

Application usage = Stripe meter usage = Invoice usage quantity = Expected charge

If any one of those values differs, you know where to start investigating.

Testing Duplicate Meter Events and the 24 Hour Uniqueness Window

Usage-based billing introduces another important risk.

Duplicate usage.

Imagine the application successfully sends a billable event to Stripe, but a temporary network problem causes the application to retry the request.

Without protection, the same customer action could potentially be counted twice.

Stripe meter events support an optional unique identifier.

Stripe enforces uniqueness for this identifier within a rolling period of at least 24 hours.

For example, a meter event is sent at 2:00 PM.

Because of a retry, the same event identifier is submitted again at 2:05 PM.

Stripe can recognize the duplicate identifier within its uniqueness window and prevent duplicate usage from being recorded.

This is a very useful QA scenario.

1. Send the original event.
2. Retry using the same identifier.
3. Verify that usage does not increase unexpectedly.
4. Then send another event with a new identifier.
5. Verify that usage increases.

Usage duplication is the kind of defect that may not break the UI at all.

Instead, it appears later as an incorrect customer invoice.

Those are exactly the billing bugs QA needs to catch before production.

Manually Adding Usage During Testing

During development and QA, you may not always want to generate hundreds of real application actions just to validate a pricing tier.

Usage can also be added or simulated through Stripe’s available testing workflows.

This is useful when validating:

• Pricing boundaries
• Large usage volumes
• Invoice calculations
• Renewal behavior
• Usage-based subscription configuration

For example, if your pricing boundary is 500 sessions, you can quickly validate behavior at:

499, 500, 501, 600, 800

without manually performing hundreds of application actions.

For full end-to-end validation, however, I still recommend generating usage through the real application flow at least once.

That proves that the application-to-Stripe integration works, not just Stripe’s calculation.

Payment Failures Should Be Part of Every Stripe Test

One of the most common QA mistakes is testing only successful payments.

A subscription integration should also be tested with failure scenarios.

Important cases include:

• Card declined
• Missing or invalid payment method
• Failed renewal
• Retry behavior
• Subscription status after failed payment
• Customer access after failed payment

The most important question is not simply whether Stripe rejected the payment.

The real question is whether the entire application responded correctly after Stripe rejected the payment.

For example, if a renewal fails, does the user immediately lose access?

Does the application provide a grace period?

Does the subscription move to the expected state?

Does the customer receive the expected notification?

Does retrying with a valid payment method recover the account correctly?

Those are application-level QA questions, not just Stripe questions.

Common Stripe Testing Mistakes

After testing subscription and usage-based billing integrations, these are some of the mistakes I consider most important to avoid.

1. Testing Only the Initial Purchase

Signup succeeds, so the feature is marked as tested.

But recurring billing systems are defined by what happens later.

Always test a renewal.

2. Checking Only whether Payment Succeeded

Payment success does not prove that the subscription, invoice, webhook, or application state is correct.

3. Ignoring Invoice States

Draft, Open, Paid, Void, and Uncollectible mean very different things.

Treat them as different test conditions.

4. Validating the Invoice Without Checking Usage

If an invoice contains a usage charge, trace it back to the underlying meter events.

5. Ignoring Duplicate Usage

Retries and asynchronous systems can produce duplicate events.

Verify the application’s identifier and retry strategy.

6. Testing Test Clocks Without Checking Downstream Effects

A successful clock advancement is not the actual test.

The subscription, invoice, payment, webhooks, and application state after advancement are what matter.

7. Mixing Sandbox and Live Configuration

Sandbox and Live environments contain separate objects and credentials.

Always confirm which environment your application is using before debugging missing data.

Stripe QA Testing Checklist

Before signing off a Stripe billing integration, this is the checklist I would use.

Customer and Subscription

• Correct Stripe Customer created or mapped
• Correct Product and Prices assigned
• Correct billing interval
• Correct billing cycle
• Trial behavior verified
• Subscription status verified
• Cancellation behavior verified
• Renewal tested

Usage-Based Billing

• Correct Meter configured
• Meter attached to the intended usage-based price
• Correct aggregation method
• Usage events mapped to the correct customer
• Usage recorded accurately
• Pricing boundaries tested
• Duplicate usage tested
• Usage reflected correctly in billing

Invoice

• Invoice generated at the expected time
• Draft to Open transition verified
• Correct subscription items included
• Usage quantity correct
• Invoice total correct
• Failed finalization behavior tested
• Void and Uncollectible behavior understood where applicable

Payment

• Successful payment tested
• Declined payment tested
• Missing payment method tested
• Authentication required flow tested where applicable
• Payment retry behavior tested
• Invoice reaches the expected final state
• Application responds correctly to payment failure

Webhooks

• Expected events generated
• Webhooks delivered successfully
• Failed webhook behavior tested
• Duplicate webhook handling considered
• Application processes events successfully
• Customer access changes correctly
• Stripe and application states remain synchronized

Test Clocks

• Trial expiration tested
• Renewal tested
• Invoice generation tested
• Usage carried into billing correctly
• Payment collection tested
• Webhooks verified after advancement
• Test Clock reaches Ready before validation

Final Thoughts

Stripe becomes much easier to test once you stop treating payments as isolated transactions.

The payment itself is only one part of a larger billing lifecycle.

A strong QA approach follows the complete chain:

Customer → Subscription → Usage → Invoice → Payment → Webhook → Application State

When something goes wrong, trace the flow instead of looking only at the final result.

This is especially important for subscription products because many of the most serious billing defects do not happen during signup.

They appear later during renewal, after a webhook failure, at a pricing boundary, during a payment retry, or when usage is converted into an invoice.

Those are the scenarios that deserve the most attention.

If there is one principle I would keep when testing Stripe, it is this:

Do not stop testing when Stripe says the payment succeeded. Test until the application and Stripe agree on what happened.

How to Test Stripe: QA Guide to Billing and Webhooks was originally published in Syntest on Medium, where people are continuing the conversation by highlighting and responding to this story.