Teardown
Teardown: Stripe’s Usage-Based Pricing
This one’s run straight through the ten-step checklist instead of freeform, since that’s the actual test the checklist needs after three teardowns built it. Stripe was chosen because its pricing has no seats, no tiers, and no contact count. It’s usage-based, a percentage of the customer’s own transaction volume plus a fixed fee per charge. That’s a shape none of the first three offers had.
The offer as written. Stripe charges 2.9% plus 30 cents per successful US online card transaction, with no monthly fee and no setup fee on the standard plan. In-person transactions run 2.7% plus 5 cents. International cards add 1.5%. Currency conversion adds another 1%. Disputes cost 15 dollars each, refunded if the merchant wins. Add-on products, Billing, Tax, Connect, Radar, Identity, Atlas, each carry their own separate fee on top of the base rate. Businesses processing above roughly five million dollars a year can negotiate custom interchange-plus pricing instead of the flat rate.
Name the Promise, and size it. The Promise is infrastructure: accept payments without building the plumbing yourself. It’s a claim about eliminated engineering work, closer in shape to HubSpot’s coordination-removal Promise than to Linear’s speed claim or Gong’s operational-visibility claim. The size of the Promise is moderate. It’s not asking a business to trust Stripe with how it manages its whole sales org, the way Gong does. It’s asking a business to trust Stripe with a single, well-bounded function.
Identify where Credibility is sourced. Almost entirely from ubiquity and the free-to-start structure. There’s no fee to begin, no commitment, no sales call. A developer can read the docs and start testing in an afternoon. Credibility here isn’t proven with testimonials, it’s proven by removing the cost of finding out for yourself. This matches the size of the Promise from step 1. A moderate, well-bounded Promise doesn’t need a sales conversation to carry it.
Measure Toll on both dimensions. Friction to start is close to zero, no contract, no minimum, no sales call. Complexity is a different story, and this is where the checklist earns its keep. The headline rate is one number, but the actual cost a business ends up paying depends on transaction size, card origin, currency, which add-on products are active, and dispute frequency. Multiple third-party sources describe real effective rates landing well above the headline 2.9%, sometimes past six percent once billing, tax, and international fees stack. The starting Toll is nearly nothing. The full-cost Toll only reveals itself gradually, after the business is already running transactions through the platform.
Check whether Toll is deliberate. This is a case the first three teardowns didn’t produce. The low starting Toll is clearly deliberate, it drives adoption. But the gradually revealed complexity in the add-on stack looks less like a considered design choice and more like a byproduct of years of new products being priced independently rather than as one coherent system. Worth flagging as a distinct category: Toll that grows through accumulation over time rather than being set once at the design stage.
Name the Best Alternative. Two candidates, and they sit at very different points on the buyer’s journey. Early on, it’s building the payment integration in-house, a real option a technical team could pursue, which is why Stripe leads with developer experience and speed to first transaction. Later, once a business is large enough to negotiate, the Best Alternative becomes a competing processor or a direct interchange-plus deal, which is exactly the point at which Stripe itself offers custom pricing.
Run the complement test. Not directly applicable in the way it was for HubSpot’s Hub bundle, since the core payments product isn’t bundled with unrelated components, it’s a single function. The add-on products, Billing, Tax, Radar, are closer to genuine complements to a business already using Stripe for payments, so the test does apply to those specifically: would a Stripe merchant assemble tax calculation and billing separately if Stripe didn’t offer them. Often yes, which means these are real bundle candidates, priced and sold as optional add-ons rather than forced into the base.
Locate the Value Margin engine. Stripe’s cost to process a transaction is largely fixed by interchange fees it doesn’t control, with its own margin sitting in the spread between what it charges and what it pays upstream. This is the first teardown where Cost is mostly outside the seller’s own control, set by card networks and banks rather than by internal delivery decisions. Pricing at a flat rate for small businesses and custom interchange-plus for large ones is a direct Value Margin management move: the flat rate overcharges small, low-volume merchants slightly to fund simplicity, and the custom rate protects margin on high-volume accounts where the flat rate would otherwise compress it too far.
Check Price visibility. Price is fully visible, immediately, headline and all. This is the opposite of Gong and matches Linear. It fits the pattern the third-party sources point to: a usage-based, self-serve product with no sales process has no room to reframe the comparison before the number lands, so hiding it would only add friction with no offsetting benefit.
Look for filtering built into the price structure. Less present here than in HubSpot’s tier cliff, but not absent. The custom pricing threshold at roughly five million dollars in annual volume functions as a soft filter, businesses below it self-serve, businesses above it get a human sales relationship. That’s a volume-based filter rather than a feature-based one, worth noting as a distinct filtering mechanism from HubSpot’s tier cliff.
What this explains that a fee comparison wouldn’t. A simple fee comparison would say Stripe charges 2.9% plus 30 cents and stop there. The framework explains why that number is both true and incomplete on purpose: the headline rate exists to minimize Toll at the moment of adoption, while the real cost structure, assembled from a dozen smaller fees layered in over years of product launches, only becomes visible to a business once it’s already committed. That’s not necessarily bad design. It’s a coherent tradeoff between low adoption friction and long-run pricing transparency, and it’s a tradeoff none of the first three offers made in quite this way.
What this run adds to the checklist. Two additions worth carrying forward. Step 4 needs a second category. Deliberate Toll isn’t just present or absent, it can also be accumulated rather than designed, the result of many individually reasonable pricing decisions stacking up over time rather than one coherent choice. That’s worth checking for separately, since the fix looks different: a designed Toll is a strategic choice to reconsider, an accumulated one is a cleanup problem. Step 7 assumed Cost was mostly under the seller’s control in all three prior teardowns. It isn’t always. When a large share of Cost is set by an upstream party the seller doesn’t control, Value Margin management shifts from reducing Cost to managing Price segmentation around a Cost floor that’s fixed. Worth naming as its own case rather than folding into the general Value Margin step.
Where This Sits in Offer Physics
Concepts referenced