Skip to content

CONCEPT Cited by 1 source

Pay-as-you-go abuse

Definition

Pay-as-you-go abuse (or consumption-billing abuse / post-paid-nonpayment abuse) is the fraud class where customers exploit the structure of consumption-based pricing — charges accumulate throughout a billing cycle, payment happens later — to consume large amounts of compute / API calls / inventory and then never pay when the bill comes due.

Per the 2026-05-27 Stripe Radar disclosure:

"Pay-as-you-go abuse occurs when customers abuse your service by racking up usage costs with no intention of paying when the bill comes due. These bad actors exploit the structure of consumption-based pricing, where charges accumulate throughout a billing cycle, but payment happens later. For example, a customer could consume thousands of dollars of compute over the course of a month, get billed at the end, and never pay."

Why this is an LLM / agentic-era problem

Three forces concentrate the abuse class on LLM platforms:

  1. High per-unit cost — LLM compute (tokens, audio generation, video generation) is expensive, so the abuser's gross extracted value is large.
  2. Consumption-billing latency — usage-based pricing inherently lags payment by a billing cycle. Pre-paid / subscription pricing forecloses the abuse vector but limits product elasticity.
  3. Tier graduation — many platforms graduate accounts from free-tier to pay-as-you-go after light verification, so sign-up-time fraud detection (multi-account abuse) doesn't catch this class.

The novel mechanism: predictive intervention before billing

The Stripe Radar disclosure's architectural contribution is shifting detection from post-billing to mid-cycle:

"Radar now helps predict nonpayment abuse as usage accumulates, allowing you to intervene before a customer is billed. This allows you to require a top-up, cut off service, or take whatever action fits your risk tolerance."

Mid-cycle prediction lets the platform act before unrecoverable losses accrue. Possible actions surfaced by the post:

  • Require a top-up (effectively converting the customer to pre-paid for the remainder of the cycle).
  • Cut off service (accept the costs already incurred but cap exposure).
  • Throttle / rate-limit (slow accumulation while investigating).
  • Flag for review (human-in-the-loop check).

Distinction from sibling abuse classes

The architectural insight is that the billing event is too late for the post-paid model — the platform must predict and intervene as usage accumulates to avoid the consumption- billing-latency loss window.

Caveats

  • Prediction horizon and precision/recall not disclosed. How early in the cycle can Radar predict? What's the cost of false positives (legitimately-paying customers throttled)?
  • Signal mix not disclosed. What predicts non-payment intent? Usage-acceleration curve? Account-age? Payment-method- freshness? Network signals from other Stripe merchants?
  • Threshold / action policy is merchant-controlled. Radar emits the prediction; the merchant chooses whether to throttle / cut off / require top-up.

Seen in

Last updated · 542 distilled / 1,571 read