What SaaS Pricing Teaches Post-Purchase Platforms
Key Takeaways
- The best SaaS businesses price on value delivered, not infrastructure consumed. Stripe charges per transaction processed, not per API key issued. Intercom charges per query resolved, not per chatbot deployed.
- Physical product platforms are stuck in "per identity" or "per label" models — borrowed from software seat licensing. This charges for infrastructure, not outcomes.
- The right unit of value for a post-purchase platform is the action: a warranty claim filed, a spare parts order completed, an ownership transfer processed. Each is a discrete, measurable moment of value delivery.
- Flat platform fees create predictability. Action-based pricing creates alignment. The best model combines both.
The Seat Licence Trap
Most B2B software started with the same pricing model: per seat, per month. It was simple. It was borrowed from office software licensing. And for decades, it worked.
Then Stripe came along and said: we don't charge you for having a payment infrastructure. We charge you when a payment goes through. 2.9% + 30¢ per successful transaction. Zero if nothing happens.
That single decision — pricing on value delivered rather than infrastructure deployed — changed the economics of an entire industry. Stripe made it free to start, cheap to test, and expensive only when you're making money. Every competitor had to follow.
The lesson took years to spread. But the best SaaS companies all arrived at the same conclusion: charge when the customer gets value, not when they get access.
Five Pricing Models That Got It Right
Stripe: Per Transaction
Stripe charges 2.9% + 30¢ per successful transaction. Not per merchant account. Not per API key. Not per team member. The fee scales exactly with the value delivered — money moved.
Why it works: The merchant's cost is zero until revenue flows. Growth is frictionless because pricing aligns with the merchant's own success. A startup processing £100/month pays £3. An enterprise processing £10M/month pays £290,000. Both feel fair.
The principle: Price on the unit of value delivery. For Stripe, that's a completed payment.
Intercom Fin: Per Resolution
Intercom's AI agent charges $0.99 per resolution — a customer query that the AI answers without human involvement. Not per message sent. Not per chatbot deployed. Not per seat.
Why it works: The customer only pays when the AI does something useful. An unresolved query costs nothing. Resolution rate becomes a shared success metric — Intercom is incentivised to make the AI better, because better resolution = more revenue.
The principle: Charge for outcomes, not attempts.
Twilio: Per Message
Twilio charges per SMS sent, per minute of voice, per API call. No minimum spend. No seat licence. The infrastructure is free — you pay for usage.
Why it works: A developer can prototype with $5 of credit. A company sending 10 million messages per month pays proportionally. The pricing barrier to adoption is essentially zero.
The principle: Make the first unit nearly free. Revenue scales with usage.
Shopify: Platform + GMV
Shopify charges a flat platform fee ($39–$399/month) plus a percentage of gross merchandise volume (0.5–2% depending on tier). The platform fee covers access to the tools. The GMV percentage aligns Shopify's revenue with the merchant's success.
Why it works: The flat fee is predictable and budgetable. The GMV percentage means Shopify earns more when the merchant sells more — creating genuine incentive alignment. Merchants don't resent the percentage because Shopify's platform is visibly driving the sales.
The principle: Flat base for predictability. Variable component for alignment.
AWS / Cloudflare: Per Request
Cloud infrastructure charges per compute-second, per request, per GB transferred. You pay for what you use. Idle infrastructure costs nothing (in theory).
Why it works: No upfront capacity planning. No wasted spend on unused servers. Costs track perfectly with actual usage.
The principle: Don't charge for capacity. Charge for consumption.
What These Models Have in Common
| Model | Charges for | Doesn't charge for |
|---|---|---|
| Stripe | Completed transaction | Having an account |
| Intercom Fin | Resolved query | Unanswered queries |
| Twilio | Message sent | Platform access |
| Shopify | Platform + sales made | Products listed |
| AWS | Resources consumed | Resources provisioned |
Every model charges for value delivered. None charges for infrastructure deployed. The customer pays when something useful happens — not when something could happen.
Where Physical Product Platforms Got Stuck
Most connected product platforms — including the current generation of DPP, QR, and warranty management tools — price on one of two dimensions:
Per identity / per tag: You pay for each product unit that has a digital identity. 500 identities = £X/month. 5,000 identities = £Y/month. Hit the limit and you upgrade.
Per seat: Traditional helpdesk pricing. £Z per admin user per month.
Both models charge for infrastructure, not value. And both create problems at scale:
The identity ceiling problem
A power tools manufacturer shipping 50,000 units per year needs 50,000 identities. Most platform tiers cap at 5,000 or 10,000. The manufacturer is forced into an enterprise conversation before the product has proved its value — because the pricing model punishes manufacturing volume, not because the platform can't handle it.
The equivalent in Stripe's world would be charging per credit card issued rather than per transaction processed. No payments company would do this — because the card is infrastructure. The payment is value.
This mirrors the challenge in connected product platforms: pricing models that treat infrastructure (identities, labels) as the billable unit instead of outcomes. This is particularly painful for manufacturers at scale, where spare parts revenue and product identity are directly linked to transaction volume.
The "success penalty" trap
If you price per warranty registration and your platform increases registration rates from 10% to 35%, the customer's bill triples. The platform's success is the customer's cost increase. That's misaligned.
Imagine if Stripe charged more when your conversion rate improved. Or if Intercom charged more when its AI resolved more queries. The incentive would be backwards.
What a Post-Purchase Platform Should Charge For
If the SaaS pricing lesson is "charge for value delivered," the question for post-purchase platforms is: what is the unit of value?
Here are the candidate actions — each a discrete, measurable moment where a physical product platform delivers value to the brand:
| Action | Value to the brand | Analogous SaaS model |
|---|---|---|
| Warranty claim processed | Support cost avoided, customer retained | Intercom per-resolution |
| Spare parts order completed | Revenue captured (vs Amazon) | Shopify GMV percentage |
| Ownership transfer processed | Second-owner relationship acquired | Stripe per-transaction |
| AI support query resolved | Phone call deflected | Intercom per-resolution |
| Product registration captured | Known customer acquired, warranty activated | Free (top of funnel) |
Notice what's absent from this list: "identity created." Creating a digital identity for a product is infrastructure. It costs fractions of a penny to host. It delivers no value until someone does something with it.
The valuable actions are the ones that happen after the scan: registering, claiming warranty, ordering parts, transferring ownership, getting AI support. These are the transactions. These are where the pricing should anchor.
The Hybrid Model
The SaaS companies that get pricing right don't use pure consumption models. They combine a flat platform fee with action-based pricing:
- Shopify: Flat platform + GMV %
- Intercom: Seat fee + per-resolution
- Stripe: No platform fee, but payment processing is inherently recurring
- AWS: No base fee, but enterprise customers negotiate committed spend
For a post-purchase platform, the hybrid looks like this:
Flat monthly fee covers: platform access, unlimited product identities, unlimited scans, product experience hosting, basic analytics, DPP data hosting. This is the infrastructure. It should be predictable and simple.
Action-based pricing covers: warranty claims processed, AI support resolutions, spare parts commerce (GMV %), ownership transfers. These are the value-delivering moments. They should scale with the brand's success.
Registrations are always free. Registration is the top of the funnel. Charging for it would be like Shopify charging per product listing — it suppresses the behaviour that drives everything downstream.
This model creates the right incentives on both sides. The platform is motivated to increase registrations (more top-of-funnel), improve AI resolution rates (more revenue per query), and drive spare parts discovery (GMV growth). The brand pays proportionally to value received.
The Pricing Conversation Is a Positioning Conversation
How a platform prices reveals what it believes its value is.
A platform that charges per identity believes its value is being a database. A platform that charges per seat believes its value is being a tool. A platform that charges per action believes its value is delivering outcomes.
For physical product brands evaluating post-purchase platforms, the pricing model is a signal. The platform that charges when your customer registers, your warranty claim gets processed, and your spare part gets ordered is telling you: we succeed when you succeed.
The platform that charges for 10,000 identities whether anyone scans them or not is telling you something different.
FAQ
Q: Doesn't action-based pricing make costs unpredictable? Not if the model includes generous included allowances. Most SaaS hybrid models include a base allocation (e.g. 100 warranty claims/month in the Grow tier) with overage only above that. 80%+ of customers never hit overage. The base is predictable; the variable component catches outliers.
Q: Should registrations really be free? Yes. Registration is the moment a brand acquires a known customer. Charging for it suppresses the behaviour that drives all downstream value — warranty claims, parts orders, support queries, ownership transfers. It's the top of the funnel, not the billable event.
Q: How does this apply to DPP compliance pricing? DPP data hosting is infrastructure — it should be covered by the flat platform fee (or offered as a flat add-on). The value isn't in hosting the data; it's in what happens when a consumer or regulator accesses it. The access event is the action worth tracking.
Q: What about enterprise pricing? Enterprise customers typically prefer committed spend with volume discounts — similar to AWS reserved instances. The action-based model still applies, but with negotiated per-action rates and annual commitments rather than monthly pay-as-you-go.