
Frameworks, core principles and top case studies for SaaS pricing, learnt and refined over 28+ years of SaaS-monetization experience.
Thank you! Your submission has been received!
Oops! Something went wrong while submitting the form.
Join companies like Zoom, DocuSign, and Twilio using our systematic pricing approach to increase revenue by 12-40% year-over-year.
Payment processing SaaS companies rarely misprice PCI DSS because they forget the audit. They misprice it because they treat PCI as an audit expense rather than a product and operating design choice. The first surprise arrives after launch: an embedded card field brings new script controls; a new processor requires fresh evidence; enterprise buyers request an Attestation of Compliance; finance discovers that the security team is spending weeks collecting screenshots, access reviews, scan reports, and vendor records.
The stakes have risen since PCI DSS v4.0.1 became the active standard and its future-dated requirements took effect on March 31, 2025. PCI DSS applies not only to firms that store, process, or transmit card data, but also to entities that can affect the security of the cardholder data environment. Whether a company must submit an SAQ, an Attestation of Compliance, or a QSA-led Report on Compliance is determined by the payment brands, acquirer, or other compliance-accepting entity, not by PCI SSC alone.
Monetizely’s position is clear: a payment processing SaaS company should recover PCI costs through a minimum platform commitment plus a payment-volume rate, with gross payment volume as the primary meter. The company should not sell PCI as a separate surcharge, and it should not set pricing until it has chosen an architecture that limits its PCI scope.
A PCI budget starts with one question: where does raw card data go? A SaaS company that redirects customers to a PCI-compliant processor’s payment page has a very different cost base from one that renders payment fields in its own checkout or runs a token vault.
That distinction is not semantic. PCI SSC states that a merchant may be eligible for SAQ A when all payment-page elements originate directly from a compliant third-party service provider. A redirect can simplify eligibility further. An embedded payment form can still qualify, but the merchant must confirm that its own site is not susceptible to script attacks that could affect the e-commerce system.
The practical effect is large. A founder may see “hosted fields” as a front-end choice. Security, however, sees a decision about which systems, scripts, engineers, and vendors enter the annual evidence process.
Exhibit 1: Three-year PCI DSS cost bands by payment architecture
| Payment architecture | Typical validation posture | Year 1 cost | Annual cost in years 2-3 | Three-year cash cost | Main source of cost growth |
|---|---|---|---|---|---|
| Redirect or fully hosted checkout | SAQ A may be possible | $35,000-$70,000 | $25,000-$55,000 | $85,000-$180,000 | Security ownership, scans, vendor evidence |
| Embedded hosted fields or merchant-controlled payment-page elements | SAQ A or SAQ A-EP, depending on implementation | $90,000-$180,000 | $65,000-$130,000 | $220,000-$440,000 | Script controls, testing, monitoring, remediation |
| SaaS platform processes or transmits PAN, or operates a payment service-provider environment | QSA-led validation often becomes likely when required by acquirer or card brands | $300,000-$650,000 | $240,000-$540,000 | $780,000-$1.73 million | Full control testing, personnel, assessor work, architecture changes |
The table makes the central point: the move from hosted checkout to a card-data environment can multiply three-year cost by roughly ten times, even before a breach or a major redesign.
Hosted payment products from established providers demonstrate the economic value of keeping raw card data out of the SaaS platform. PayPal Braintree says its Hosted Fields send payment data directly from the customer’s browser to Braintree rather than to the merchant server, and it positions the product for SAQ A eligibility. Stripe Checkout similarly provides a processor-hosted checkout option within its integrated payments offering.
None of this removes responsibility. A redirect, iframe, or tokenization flow lowers scope only when implemented as the provider specifies and when the company meets the relevant eligibility criteria. A sales deck that says “PCI compliant” is not a substitute for documented data flows, a current service-provider attestation, and an approved validation path.
The external assessment fee draws attention because it is easy to identify. It is also usually only one part of the bill. A 2026 State of Michigan QSA-services contract priced an annual remote and onsite assessment, ROC, and AOC at $86,091.67, with senior audit and technical consulting billed around $300 per hour. That is a useful public benchmark for an assessment engagement, not a full PCI operating budget.
A payment SaaS firm must also fund the people and systems that allow the assessor to reach a conclusion. The spend hides in engineering backlogs, cloud-security configuration, access governance, incident exercises, penetration tests, evidence collection, and third-party reviews.
Exhibit 2: A mature service-provider PCI operating year has five cost pools
| Cost pool | Annual modeled cost | What the company is paying for |
|---|---|---|
| QSA assessment, ROC or AOC support | $60,000-$120,000 | Assessment planning, interviews, testing, reporting |
| Security personnel and evidence collection | $90,000-$180,000 | Control owners, engineering time, access reviews, policy upkeep |
| Testing, logging, scanning, and monitoring | $45,000-$110,000 | Vulnerability scans, penetration tests, alerting, evidence retention |
| Remediation and architecture maintenance | $25,000-$100,000 | Fixing gaps, replacing components, hardening integrations |
| Vendor oversight and incident readiness | $10,000-$30,000 | Reviewing service providers, tabletop exercises, contract records |
| Total ongoing annual cost | $230,000-$540,000 | The recurring cost of sustaining evidence, not merely passing an audit |
The implication is straightforward: cutting the assessor’s scope without reducing the systems and people in scope will not materially change the total cost.
PCI DSS v4.0.1 has made the boundary between product engineering and compliance even more important. PCI SSC’s guidance for e-commerce environments highlights requirements for managing payment-page scripts and detecting unauthorized changes. Those controls turn an otherwise ordinary JavaScript release process into a regulated process when payment-page security is in scope.
For a vertical SaaS company, this often becomes a product roadmap issue. A team may choose a custom payment form to preserve visual control, then discover that a modest conversion improvement created a permanent security control burden. The cost of that decision does not belong in a security budget alone. It belongs in the business case for the feature.
PCI cost is largely fixed at low and medium scale. Payment economics are not. Processing fees, fraud costs, chargeback operations, and support load all rise with transaction activity. Payment volume is therefore the most defensible primary meter for recovering the compliance program, even though a minimum commitment is necessary to cover the fixed base.
The market already teaches customers to think this way. As of September 7, 2026, Stripe’s standard U.S. online-card price is 2.9% plus $0.30 per successful domestic transaction. Adyen charges a fixed processing fee plus a payment-method fee, and makes interchange-plus pricing available for relevant methods. Shopify combines monthly software plans with payment rates that decline on higher plans.
Those companies differ in market, scale, and product breadth. Yet their commercial logic is consistent: payment value and payment costs are tied to activity. PCI should be recovered inside that same economic engine, not attached as a line called “compliance fee.”
A simple sensitivity calculation shows why a low-volume customer cannot carry a complex payment platform through a small basis-point charge alone.
Exhibit 3: The payment volume needed to recover a $250,000 annual PCI program
| Annual gross payment volume | PCI recovery rate needed before processor fees, fraud losses, and margin |
|---|---|
| $10 million | 250 basis points |
| $50 million | 50 basis points |
| $100 million | 25 basis points |
| $500 million | 5 basis points |
| $1 billion | 2.5 basis points |
At $10 million in annual payment volume, a platform would need 250 basis points merely to recover a $250,000 compliance program. That rate is commercially untenable in many categories, which is why the minimum platform commitment matters.
The correct commercial structure is therefore not “flat fee versus usage.” It is a payment-volume model with a firm floor:
A per-seat PCI fee fails because the number of finance users or support agents has little relationship to the card-data environment. A standalone PCI surcharge fails for a different reason: buyers treat it as a negotiable nuisance rather than as part of the payment service they are purchasing.
Monetizely’s 5-Step Pricing Framework begins with goals and segmentation, moves to packaging, then to choosing the pricing metric, finding price points, and finally operationalizing pricing. The sequence matters because a price cannot correct a product architecture that creates avoidable scope, nor can a clever meter save a package that forces low-volume customers to subsidize complex enterprise requirements. As described in Monetizing Agentic AI, the framework treats price as the outcome of linked business decisions rather than a number selected at the end of a spreadsheet.
For payment processing SaaS, each step produces a concrete decision.
Exhibit 4: The five pricing decisions that determine whether PCI costs are recoverable
| Step | Decision for payment processing SaaS | Practical output |
|---|---|---|
| Goals and segmentation | Decide whether the priority is payment adoption, margin expansion, enterprise readiness, or market entry | Separate low-volume software customers from high-volume platform customers |
| Packaging | Match payment controls, fraud tools, reporting, onboarding, and support to segments | Core payments package plus enterprise controls and services where justified |
| Choosing the pricing metric | Select the measure that tracks value and cost | Gross payment volume as the primary meter, supported by transaction charges where needed |
| Finding price points | Set a floor and volume bands using the actual PCI program cost | Minimum annual commitment plus declining basis-point tiers |
| Operationalizing pricing | Make contracts, billing, usage data, reporting, and renewals reflect the offer | Metered GPV, clear true-ups, product entitlement rules, audit-ready records |
The framework means that PCI economics should be settled before the sales team receives a rate card. A company that launches with one all-inclusive payment package will usually face one of two outcomes. Smaller customers pay too much and avoid activating payments, or larger customers negotiate away the margin needed to support their security and assurance demands.
Stripe shows the first pattern: broad availability can be paired with simple transaction pricing. Its standard fee is easy for a smaller business to understand, while larger or unusual businesses can move to custom pricing.
Adyen shows the second: payment-method economics are not uniform. A fixed processing fee sits beside fees that vary by payment method, and interchange-plus structures expose underlying card cost differences. A payment SaaS company that serves international or enterprise customers needs similar discipline when its cost varies by payment route, card mix, or country.
Braintree shows the third: a provider can reduce a customer’s scope while maintaining a sophisticated checkout experience. Hosted Fields lets a merchant style its payment flow while routing raw card inputs to Braintree. That is a product decision with pricing consequences because it protects the merchant and platform from taking on unnecessary card-data responsibilities.
Shopify shows the fourth: SaaS subscription and payments can coexist, but they should not be confused. Its platform plans fund commerce software, while payment rates monetize payment activity. The model recognizes that a merchant with $2 million in annual volume and a merchant with $200 million in annual volume do not create the same payments workload or economic opportunity.
Together, these examples support a single principle: software access may justify a subscription, but payment infrastructure should earn revenue when money moves.
The common mistake is to charge a flat platform fee and assume payment volume will take care of itself. That approach may work when a company is using payments only to improve retention. It fails when the company is building a material payments business with PCI accountability, underwriting exposure, support obligations, and enterprise assurance requests.
A more durable offer has three customer-facing versions:
The logic is not to charge every customer more. It is to stop charging every customer as though they impose the same payment, compliance, and support burden.
PCI DSS should shape the payment product before it shapes the price list. The cheapest security strategy is rarely the lowest QSA bid. It is the architecture that keeps sensitive data, payment-page responsibility, and evidence burden as narrow as the product can sustain.
Payment processing SaaS leaders should therefore take five actions:
Make payment architecture a board-level unit-economics decision. Require every major checkout, vault, or orchestration change to show three-year PCI cost, projected GPV, and required basis-point recovery.
Set a minimum annual payment commitment before discounting basis points. A customer below the volume needed to cover fixed assurance costs should not receive the economics designed for a scaled platform.
Build separate P&Ls for software ARR and payments contribution. Gross payment volume, processor expense, fraud loss, PCI operating cost, and payment support should be visible in one operating view.
Segment customers by expected payment maturity, not employee count. A 30-person marketplace processing $150 million annually needs a different offer from a 2,000-person SaaS company processing $3 million.
Treat scope reduction as a product KPI. Reward product and engineering teams for reducing the number of systems that can touch or affect card data, because every removed system lowers recurring assurance work.
Assumptions: Cost bands model a U.S.-based B2B SaaS company operating cloud software, exclude card-brand penalties and breach losses, and use the State of Michigan’s published QSA assessment price as one public assessment-cost anchor. Actual validation requirements, assessor fees, staffing costs, and processor agreements vary by acquirer, payment architecture, geography, transaction mix, and the company’s evidence readiness.
Monetizing Agentic AI: https://www.amazon.com/Monetizing-Agentic-AI-Handbook-Transformation/dp/B0H7Z13VKJ/
PCI Security Standards Council, PCI DSS overview, PCI DSS v4.0.1 materials, and e-commerce SAQ eligibility guidance, accessed September 7, 2026. (pcisecuritystandards.org)
State of Michigan, Qualified Security Assessor Services procurement pricing, accessed September 7, 2026. (michigan.gov)
Stripe, Pricing & Fees, accessed September 7, 2026. (stripe.com)
Adyen, Pricing for Supported Payment Methods, accessed September 7, 2026. (adyen.com)
PayPal Braintree, PCI compliance and Hosted Fields documentation, accessed September 7, 2026. (braintreepayments.com)

Join companies like Zoom, DocuSign, and Twilio using our systematic pricing approach to increase revenue by 12-40% year-over-year.