To compare PSPs, divide costs attributable to the same payment population by the number of unique intents that reached your chosen outcome. State whether that outcome is authorization, capture, or an actually paid order, and specify the observation window. A lower percentage rate can coexist with more attempts, lower recovery, or more operational work. Without an explicit numerator, denominator, and horizon, cost per approval does not support a reliable comparison.
The calculation should start with the contract and records, not a savings promise. Fees per attempt, transaction, or service may use different bases. Operational expenses and losses also need classification to prevent one team from comparing processing alone while another presents the extended cost of the entire lifecycle.
This article proposes a measurement method. All amounts, percentages, and results in scenarios A and B are fictional, created to make the arithmetic reproducible. They do not represent the pricing, performance, or customers of AZPay or any other supplier. Technical sources were consulted on October 22, 2026.
What does an approved payment mean in your analysis?
An accepted authorization, a confirmed capture, and a paid order are related but different outcomes. Adyen’s payment lifecycle documentation (opens in a new tab ↗) distinguishes processing states, including authorization and subsequent stages. It is cited to show that the lifecycle has phases, without imposing one provider’s names on others.
For a card operation, define whether the metric counts intents with at least one accepted authorization or orders whose payment was actually captured and allocated. For other methods, use the appropriate financial event. Do not invent a Pix capture to make different methods fit the same column.
Also distinguish intents from attempts. An intent to pay R$100 may generate three attempts before completion. It represents one commercial success but may produce three events relevant to billing or observability. Counting the three attempts as three orders artificially reduces unit cost and increases apparent results.
A useful convention is to publish two indicators: cost per approved intent and cost per paid order. Add the approval rate per attempt for diagnostics. The approval rate guide explores denominators; an economic comparison requires connecting them to the corresponding costs.
Which components belong in the numerator?
Start with processing: percentage charges, fixed fees, and contractual terms that determine when a unit is billed. A fee per settled transaction does not apply in the same way as a fee per received attempt. If there is a monthly minimum or package, explain how its share was allocated to the analyzed population.
Then identify associated services: authentication, fraud prevention, tokenization, currency conversion, or other items actually contracted. Do not add a standalone fee if it is already included in the agreed price. The spreadsheet must record the component and its basis as well as the calculated amount, so an independent person can detect double counting.
Adyen’s Settlement details report documentation (opens in a new tab ↗) illustrates records of gross and net amounts and costs, with components such as markup, scheme fees, and interchange where applicable. This illustrates the need for a breakdown; it does not mean every PSP provides this exact report or that these components are additive under every contract.
If multiple currencies are involved, preserve original amounts and state the conversion rate, date, and purpose of the presentation currency. Separate a contracted currency conversion fee from changes between conversion and receipt dates. Aggregating currencies at a rate selected after seeing the outcome can change the comparison without any processing change. Likewise, confirm whether taxes or early settlement expenses are included, excluded, or simply shown in another view.
Maintain a second layer for operational costs and losses: support, manual reconciliation, recovery, and confirmed net fraud or dispute losses, according to the chosen scope. Call this the extended cost view. A decision can then show what processing costs and what operating the outcome costs, without confusing the two questions.
The principal of a commercial refund does not automatically become a processing cost. A refund may reduce revenue and change the population of retained orders, while an unrecovered fee or support cost belongs to another category. Define the treatment before adding financial events with different meanings.
Which formula can finance and engineering reproduce?
Define C as the sum of components allocated to the cohort and chosen horizon. Define A as the number of unique approved intents and P as the number of unique orders actually paid. Then, cost per approved intent = C ÷ A; cost per paid order = C ÷ P.
The numerator can be processing cost or extended cost, provided the indicator’s name makes that explicit. If the analysis excludes risk and support, keep a separate column for them. Do not present a narrow metric in one proposal and an extended one when evaluating a competitor.
To break down C, use auditable quantities: billable attempts multiplied by the fee per attempt; volume subject to the percentage multiplied by the rate; services by their basis; expenses allocated under the documented rule. Costs from different periods, currencies, and populations must be normalized before being included in the same sum.
If A or P is zero, cost per success is not zero: division is undefined. Show the cost incurred and the absence of successes. Hiding this case as zero or removing the route from the report can make an outage look like savings.
Preserve internal precision and round only for presentation. In small samples, cents per event affect the total. Also record whether the percentage applies to gross captured, authorized, settled, or another contractual basis; the same percentage produces different expenses when the basis changes.
Fictional scenario: A advertises a lower rate, B costs less per paid order
Consider two comparable populations, each with 10,000 purchase intents of R$100. Each population’s commercial potential is R$1 million. To simplify the example, no intent has two successful approvals, there are no partial payments, and all amounts are in Brazilian reais. The observation horizon is the same for A and B.
In scenario A, there are 12,000 attempts, 8,200 authorized intents, and 8,000 paid orders. Paid volume is R$800,000. The fictional percentage rate is 1.8% of that volume, or R$14,400. A hypothetical R$0.12 fee per attempt adds R$1,440, and a hypothetical R$0.08 verification per attempt adds R$960.
Add R$2,000 in net losses allocated to the cohort and R$1,200 in operations, both entirely fictional and outside the preceding fees. A’s extended total is R$14,400 + R$1,440 + R$960 + R$2,000 + R$1,200 = R$20,000.
In scenario B, there are 10,800 attempts, 8,700 authorized intents, and 8,500 paid orders. Paid volume is R$850,000. The fictional 2.1% rate generates R$17,850. The hypothetical R$0.05 fee per attempt produces R$540, and the hypothetical R$0.05 verification per attempt produces another R$540.
With R$800 in net losses and R$770 in operations, also fictional, B’s extended total is R$17,850 + R$540 + R$540 + R$800 + R$770 = R$20,500. These numbers are exercise assumptions; the difference in losses does not demonstrate that B has better fraud prevention.
Extended cost per paid order is R$20,000 ÷ 8,000 = R$2.50 for A and R$20,500 ÷ 8,500 = approximately R$2.4118 for B. B has a higher percentage rate and higher total spending, but a lower unit cost for the paid outcome. The comparison requires showing all three facts together.
If the question concerns only processing and verifications, exclude operations and losses from both sides. A becomes R$16,800 ÷ 8,000 = R$2.10 per paid order. B becomes R$18,930 ÷ 8,500 = approximately R$2.2271. Under this narrower scope, A is lower. The exercise shows why declaring scope matters as much as calculating correctly.
What happens when the denominator changes?
Using extended cost and the authorized outcome, A shows R$20,000 ÷ 8,200 = approximately R$2.4390 per approved intent. B shows R$20,500 ÷ 8,700 = approximately R$2.3563. These amounts must not be labeled cost per paid order, because some authorized intents have not reached that outcome.
A’s approval rate per attempt is 8,200 ÷ 12,000, approximately 68.33%; per intent, it is 82%. For B, the rates are approximately 80.56% per attempt and 87% per intent. The paid order rate is 80% for A and 85% for B. Each indicator describes a different stage of the same population.
Do not use this simplification to automatically deduplicate a real operation. If an intent can receive more than one accepted authorization, the numerator for approvals per attempt will have a different cardinality. For the intent view, count once according to the chosen definition and preserve all attempts to understand cost and risk.
Also disclose the effect of later cancellations and refunds. An order paid on its due date may no longer belong to a retained revenue population after ninety days. That alternative view can be useful, but it needs a different label. Silently changing the denominator destroys historical comparability.
How do you test sensitivity without treating assumptions as forecasts?
In scenario B, if we hold other costs at R$2,650 and the transaction amount at R$100 solely for analysis, each paid order adds R$2.10 in percentage fees. Therefore, extended cost per paid order = R$2.10 + R$2,650 ÷ number of paid orders.
To match A’s R$2.50, the R$2,650 component must be divided by 6,625 orders. The equality point is R$2.10 + R$0.40 = R$2.50. With 7,000 orders, the total would be R$17,350 and unit cost approximately R$2.4786. Below 6,625, this exercise’s conclusion reverses.
This calculation holds attempts, verifications, losses, and operations constant as an educational choice. In production, these components may vary with volume, profile, and outcome. Sensitivity reveals what the conclusion depends on; it does not predict how a supplier will behave with different traffic.
Vary one assumption at a time, then test plausible combinations. A lower transaction amount increases the relative weight of fixed fees. More retries can change attempt costs and recovery. A contractual minimum may prevent expenses from falling proportionally with volume. Document every assumed relationship so you do not attribute economic precision to an incomplete model.
Which measurement window avoids premature conclusions?
A cohort can consist of intents initiated during a given period and tracked to a defined horizon. This approach keeps costs and outcomes tied to their commercial origin, even when a fee or dispute appears later. The cash flow alternative observes movements occurring within the period. Both are useful but answer different questions.
Adyen’s documentation on payouts and financial batches (opens in a new tab ↗) illustrates how sales, transaction costs, refunds, chargebacks, and adjustments make up net amounts. A payout amount is therefore not, by itself, the sum of fees for that day’s sales cohort.
Separate confirmed amounts from estimates that have not yet matured. If future losses are provisioned in the management model, identify the assumption and avoid later counting the provision and actual loss as two expenses. A cohort update must replace or reconcile estimates while preserving revision history.
Use payment reconciliation to reconcile the sources. The provider invoice, transaction report, financial movements, and operational records must explain the numerator. A calendar difference must not become an additional cost merely because the report was closed too early.
How do you evaluate retries, failures, and manual work?
A retry makes economic sense only when technical eligibility and a probability of safely recovering an intent exist. An unknown outcome still requires state control. The promise of lower costs does not authorize another charge while the previous one may have been executed.
Measure additional attempts, unique orders recovered, and incremental costs. The average cost of the whole operation does not alone tell you whether the latest retry policy was worthwhile. The guide to decline codes and technical errors helps distinguish recoverable situations from inappropriate commands.
For manual work, record activities and allocation criteria: investigation, reconciliation, support, or account data correction. Avoid estimating hours from memory and presenting the number as proven cost. When data is missing, show a sensitivity range and identify the measurement gap.
Fixed and incremental costs also deserve a distinction. A team does not immediately disappear because a provider generates fewer support tickets. The reduction may free capacity without lowering cash outlay in the same month. Presenting both perspectives makes the decision more honest and avoids promising cash savings where there is only a capacity gain.
How do you compare routes without confusing association with causation?
Distribute comparable populations by method, market, currency, transaction amount, risk profile, and authentication context. If one route receives only returning customers and another receives all new customers, differences in approval or loss cannot automatically be attributed to the PSP.
A smart routing change needs a hypothesis, eligibility criteria, and an evaluation mechanism. When a controlled experiment is feasible, define the primary outcome, operational limits, and observation window in advance. Also maintain safety metrics: duplication, fraud, chargebacks, latency, and complaints.
Record the version of the rule that made the decision. Payment observability connects intents, attempts, and responses to operational changes. Without that trail, a cost reduction may simply result from no longer accepting a particular segment, rather than processing it better.
Financial outcomes must also account for sale quality. More payments with higher subsequent losses can worsen the scenario; fewer attempts with lower recovery can have the same effect. Assess margin and risk separately when necessary, avoiding adding unrealized revenue to costs as if it were a fee actually paid.
How do you build the conceptual spreadsheet and make a decision?
Create an assumptions tab with the contract, currency, period, charging basis, and exclusions. In another tab, link intents, attempts, authorizations, and paid orders using stable identities. A third breaks down fees and services; another records operations and losses. The executive view calculates indicators from these inputs, without values typed over formulas.
To audit, choose an expense line and find its source. Then choose a paid order and find its attempts and allocated components. Verify that each item is included once and shared costs have an explicit rule. Compare results with and without the least reliable estimates.
Bring total cost, cost per success within the declared scope, commercial outcomes, and data limitations into the decision. A reproducible spreadsheet supports a discussion of trade-offs without reducing an infrastructure purchase to the lowest advertised rate. To assess the intended integration architecture, consult AZPay Dev Central and validate the terms actually documented for your use case.