ISO software economics
How should an ISO evaluate software revenue?
A practical framework for separating gross recurring software opportunity from activation, partner share, support, delivery, and operating costs.
The opportunity
Make the second revenue stream visible without pretending it is net income.
An ISO may already participate in payment economics while the daily software product, add-on modules, and service relationship belong to another vendor. A white-label software program can create additional commercial layers, but only the layers that merchants actually adopt and the operating model can deliver should enter the plan.
Revenue layers
Model each source separately.
Platform
Recurring access to the approved commerce-software package at active locations.
Modules
Optional loyalty, digital channels, memberships, appointments, intelligence, or other verified additions.
Implementation
Scoped setup, data work, configuration, training, migration, and project services.
Hardware
Approved devices, peripherals, staging, replacement, logistics, and related service.
Support
A separately designed service layer only when ownership, capacity, and service levels are explicit.
Payments
Existing or incremental payment contribution modeled separately from software revenue.
The economics bridge
Move from portfolio headline to contribution.
| Layer | Question to answer | Evidence needed |
|---|---|---|
| Eligible base | Which locations actually fit this vertical offer? | Portfolio and merchant segmentation |
| Activation | How many go live and remain billable? | Measured onboarding and retention |
| Price + mix | Which package and modules are purchased? | Approved price book and signed orders |
| Partner share | How is value divided? | Approved commercial agreement |
| Delivery cost | What does setup and customization consume? | Implementation hours and dependencies |
| Run cost | What does the live location require? | Platform, support, gateway, hardware, risk, and overhead data |
| Contribution | What remains after attributable costs? | Reconciled finance and operating records |
Decision discipline
Keep the calculator honest.
Every model should show the input values, activated-location rounding, gross-versus-net label, period, exclusions, and scenario status. The first proof should then measure onboarding effort, support volume, attach behavior, payment effects, and merchant continuation so the next model is based on operating evidence rather than enthusiasm.
Questions buyers ask
Frequently asked questions
Is monthly software revenue the same as profit?
No. Monthly price multiplied by active locations is a gross revenue scenario. Profit requires subtracting platform cost, partner share, payment and gateway fees where applicable, support, onboarding, hardware, development, sales, compliance, refunds, bad debt, and overhead.
Should an ISO publish software pricing immediately?
Usually not before the offer, product scope, cost base, channel policy, and approval authority are stable. An internal price book can guide discovery while public pricing remains scoped to a written program or merchant package.
What is a useful first economics test?
Choose one merchant segment, model realistic activated locations, attachable modules, support demand, implementation work, partner share, and payment contribution, then compare the scenario with measured proof-stage results.
What should never be promised?
Revenue, margin, attach rate, retention, valuation, and portfolio conversion must never be presented as certain. Treat each as a scenario or measured result with its assumptions, date, scope, and approval.
Use the framework on a real opportunity