Per-transaction pricing and monthly pricing use different assumptions
Separate each offer’s recurring commitment from the charges triggered by documented activity, then apply both offers to the same complete historical periods. Match each variable term to the event or amount it actually bills; an order count or a fee-report row count is not automatically that quantity. Keep missing prices, unclear allowances and future activity unknown. The result is a conditional comparison of written terms against past activity, not a prediction of the next bill or proof that either provider will approve the business.
For: A research-only merchant comparing written payment-service offers with different recurring charges, usage charges or included allowances.
Classify the charge by its formula, not its billing date
A monthly invoice can collect usage charges, and a recurring subscription can include only a defined service or allowance. “Monthly pricing” therefore does not establish that every transaction is included. Copy the recurring amount, billing period, included scope and any usage terms from each written offer. A per-transaction offer may also contain a recurring charge; retain both when both are documented.
Stripe’s general terms distinguish fee agreements, subscription scope and ways fees are collected. Written pricing can differ from public prices, and fees may be deducted, charged or invoiced. Collection method answers how a charge is paid. The fee formula answers what activity changes the charge. Use the agreement and regional terms for the actual account; Stripe’s terms do not define another provider’s offer.
Find the historical quantity each term needs
Choose complete historical periods for the same business, account scope, currency and services. For every variable term, write its billable event definition and the record that counts it. A transaction fee needs the transaction definition in that offer. A percentage term needs its stated amount base. A feature fee needs the feature activity it names. Do not replace a missing definition with total store orders.
On Stripe, the Fees report separates product and feature information and can connect fee entries to an object through incurred_by. Multiple fee rows can refer to the same underlying transaction. Counting those rows as customer payments can inflate the input to a per-transaction comparison. Conversely, grouping every row into one fee can hide distinct charge components. Use the event record for the event count and the fee records to understand the charges.
Calculate only the components the offers define
For a written flat charge per event, multiply that charge by the actual count of that defined event in the selected period. For a written percentage component, apply it to the documented amount base for the same period. Add a recurring charge only on the period and scope its terms specify. These are conditional calculations from your documents, not prices supplied by this guide.
Included allowances, minimums, tiers, caps and waivers require their own written treatment where they appear. If an offer says a monthly fee replaces a usage component, do not add that component again. If it says the monthly fee is additional, keep it separate. If the wording does not answer that question, stop the affected calculation and mark it incomplete. A subtotal of known components must not be labeled the full cost.
Keep currencies separate. Also show one-time charges and any documented tax treatment separately from the recurring comparison. A charge collected once cannot be converted into a monthly amount without adding an allocation assumption; leave it visible as a separate commitment instead.
Use several actual periods to show sensitivity
Where genuine history is available, repeat the same calculation for periods with different actual activity. This shows how much of each calculated subtotal remains fixed and how much changes with documented events. Keep each period’s transaction mix and service use intact. Replacing the mix with an average can erase the conditions that trigger a fee.
Label each result as that offer applied to the named historical period. It is not what the business actually paid under that offer unless the offer was in force, and it does not predict future activity. If an event count, rate or included-service definition is missing, show the unresolved input beside the known subtotal. Without real history, there is no historical comparison to calculate.
Check completeness before interpreting a difference. Stripe’s Fees report covers most balance-paid fees but excludes specified items, including after-use invoiced fees, and data may take up to 96 hours after its balance effect to appear. Match date basis and range when comparing reports. A missing recurring invoice or incomplete period can make a variable-cost offer appear cheaper without establishing that it is.
Choose whether the offers are comparable yet
The useful outcome is a documented comparison for the activity you actually had, plus a short list of terms that prevent a complete comparison. An offer with a smaller known subtotal and more unknown charges has not established a lower full cost. Ask the issuing provider to resolve the precise event definition, inclusion or rate that prevents calculation.
For a Prism processing consultation, summarize which written offers you have, which periods you can substantiate and which terms remain unclear. Confirm any pricing-comparison work, responsibilities, fees and terms before it begins. Pricing analysis does not decide account eligibility or establish that either offer covers the actual research-only catalog.
Fixed-versus-variable cost comparison
Complete a separate set for each written offer and actual historical period, retaining the same account scope and currency. Record figures with their document references. A blank price or count means the comparison is incomplete, not that the charge is zero.
Worksheet entries are not submitted by Prism’s worksheet and are not saved by the site. Use record types, availability, anonymized observations, or match/mismatch results. Do not enter government identifiers, customer names or addresses, customer messages, receipt-access links, card or bank details, passwords, or keys. Send sensitive documents only through the provider’s verified secure channel.
Fixed-versus-variable cost comparison. The last column is for temporary notes.
Comparison input
Record to use
Interpretation rule
Your offer and period
Historical period and scope
Record to useDated activity records for the entity, account, currency and services being compared.
Interpretation ruleUse identical period boundaries and activity for both offers; do not mix accounts or currencies.
Fixed recurring charge
Record to useWritten recurring amount, billing cycle and service scope.
Interpretation ruleState what remains payable independently of the recorded event count, if the terms establish that.
Included activity
Record to useAllowance or inclusion clause and any overage terms.
Interpretation ruleIdentify exactly which variable components the recurring charge replaces or includes; silence remains unknown.
Billable event definition
Record to useOffer wording defining the charged event or amount base.
Interpretation ruleAn order, a payment attempt and a fee-report row are not interchangeable counts.
Actual event count source
Record to useReport name, filters, date basis and the event identifiers counted.
Interpretation ruleUse real counts matching the definition; multiple Stripe fee rows may share one incurred_by reference.
Variable charge term
Record to useWritten flat rate or percentage and its stated scope.
Interpretation ruleApply the term only to its matched count or amount base; do not borrow a public price.
Conditional charge treatment
Record to useAny documented minimum, tier, cap or waiver clause.
Interpretation ruleApply the actual relationship between terms; missing mechanics block that part of the total.
Excluded or unknown cost
Record to useSeparate invoices, one-time commitments and unanswered pricing questions.
Interpretation ruleKeep them visible outside the known subtotal; report exclusions are not fee waivers.
Historical comparison result
Record to useCalculated components for each offer using the same actual period.
Interpretation ruleLabel as a conditional historical comparison; no future savings or future volume is established.
These are temporary notes. Leaving or reloading this page may clear them. Worksheet entries are not sent automatically. If you copy notes into the consultation message and submit the form, Prism receives them as part of your request.
Limits
This comparison supplies no provider rate, forecast, break-even volume or savings claim. Apply only documented terms to genuine activity.
Stripe report and agreement details are Stripe-specific and depend on account, product and regional scope. A technical integration or quoted price does not establish eligibility.
Keep full statements, bank details and customer-level exports in authorized systems. Use a non-sensitive summary for a public consultation inquiry.
Stripe Services Agreement general terms — checked 2026-09-29. Stripe distinguishes written fee agreements, subscription scope and collection methods; account-country and applicable service terms matter. Public pricing need not be the account’s agreed pricing.
Stripe Fees report — checked 2026-09-29. Product and feature fields help identify fee components, and incurred_by can connect multiple fee rows to one transaction. The report covers most balance-paid fees, has exclusions and can lag up to 96 hours; its data does not supply an offer’s prices.
Discuss my processing options
Want to talk through your own processing situation?