Payments Product Pricing and Packaging: Price the Service You Can Operate

Price a payments product around the value and service the customer receives, while making rail cost, risk, support and funding constraints explicit. A percentage fee alone can hide expensive exceptions, cross-border costs or a promised payout window that the business cannot sustainably provide.

The European Commission’s interchange-fee rules illustrate a basic constraint: parts of card economics are externally set or bounded. A product team still chooses its merchant proposition, but should not present every payment cost as freely negotiable margin.

Build the pricing view

For each segment, map four layers: customer job and willingness to pay; variable rail and partner cost; operating cost from onboarding through support and reconciliation; and risk/funding exposure. Then decide which service attributes are bundled, metered or excluded.

Do not make packaging a disguise for uncertainty. If a payout is subject to partner availability or risk review, say so in the product and commercial terms.

Choose the pricing unit before the number

Pick a unit that the buyer can predict and the business can reconcile: a processed transaction, a completed payout, an active account, a supported method, or a contracted service tier. A single percentage may fit one collection product and fail for a workflow dominated by fixed support, settlement or review costs. If more than one unit is necessary, state the trigger for each in plain language.

Write down which costs vary with the customer action and which costs belong to the service model. Then test a small set of representative scenarios: an ordinary transaction, a failure and retry, a refund or dispute, and a period with unusually high support. The output is a decision aid, not an assumed margin forecast. Finance should own the underlying assumptions and their approval.

Worked illustrative example

Illustrative example, not a reported offer. A platform serves small merchants needing a simple local collection method and larger platforms needing reporting, multiple methods and integration support. A single flat rate looks simple, but the larger segment creates more implementation and support work while the smaller segment may never use the advanced service.

The team can test a basic package with self-service documentation and standard reporting, and a platform package with agreed integration support and reporting scope. Before discounting, compare each package’s expected method mix, support contact rate, exception workload and funding terms. A “premium” package is not viable if it promises a response or payout arrangement operations cannot meet.

Validate comprehension in sales calls and implementation handovers: can the buyer explain what is included, what changes the price and what happens when a payment is disputed or delayed? Confusion that closes a deal can become expensive churn.

Worked take-rate and contribution calculation

All figures below are synthetic, in one illustrative currency, and are not provider prices or a forecast. Suppose a merchant segment processes 10,000 settled transactions worth 1,000,000 in one month. Processing revenue is 12,000. For this example, processing take rate is revenue divided by settled payment value: 12,000/1,000,000 = 1.2%.

Contribution is 0.25 per settled transaction and 0.25% of settled payment value. This is not net profit: fixed overhead, tax and any omitted costs still matter. Finance should confirm the accounting treatment, revenue perimeter and whether any cost is already included elsewhere.

Now hold volume and revenue constant while exception work adds 1,000 and partner charges rise by 1,000. Contribution falls to 500, or 0.05 per transaction, even though the take rate remains 1.2%. The pricing decision is whether to change the service scope, operating process, commercial terms or eligible segment, not simply whether the headline rate looks competitive.

Define treatment of refunds, reversals, failed attempts, FX revenue and platform fees before comparing periods. A denominator based on authorized value cannot be compared directly with this settled-value example. Keep provider quotes and agreed contracts separate from assumptions.

Review price as an operating decision

For each package, establish a review table with the promised service, price unit, cost drivers, owner, exclusions and review trigger. A trigger might be a material method-mix change, higher-than-assumed exception work, a partner-cost change or a proposed settlement commitment. This separates routine commercial discretion from a product promise that would change operational risk.

Decisions and limits

Use pricing research to learn which job matters and which trade-off a segment accepts; do not ask buyers to set the price for you. Run commercial changes through legal, risk, finance and operations review where they alter fees, disclosures, credit, FX or settlement. The payment-cost guide is useful for understanding why rail mix and failure recovery can change economics, but it is not a pricing template.

Review realised margin and service performance by segment after launch. Price changes should have a rollback and customer-communication plan. A price that looks efficient in aggregate can be loss-making or harmful for a particular corridor, method or customer type.