Your PSP tracks performance. So does your finance director. They are not looking at the same numbers.
When your PSP talks about performance, they typically mean uptime, processing speed, and settlement reliability. These are operational metrics. They matter, but they are not the performance figures that move your P&L.
The numbers that matter commercially are your authorisation rate by market and card type, your 3DS conversion rate, your chargeback ratio, the decline reasons your PSP is not surfacing to you, and the gap between what your contract says you should pay and what you are actually paying per transaction once interchange, scheme fees, and your PSP’s acquiring margin are included across your full payment method mix.
PSP performance optimisation, done properly, is the discipline of closing those gaps. It is not a product your PSP sells you. It is an independent audit of how your payment setup is performing against what it should be capable of, followed by structured changes to configuration, routing, and contract terms.
Why your PSP’s performance dashboard is not enough
Every major PSP provides merchants with a reporting portal. Authorisation rates are shown. Declines are categorised. Settlement timelines are tracked. On the surface, this looks like performance management.
The problem is that these dashboards are built to show you what your PSP wants you to see. Decline reason codes are often aggregated in ways that obscure root causes. Authorisation rates are presented as overall averages, which masks significant variation by issuer, country, card type, and time of day. Retry logic, if it exists, is rarely explained. And the benchmark your PSP uses to tell you whether your performance is good or bad is their own portfolio average, not the market.
You are being compared to other merchants on the same PSP, not to what your authorisation rate should be given your business model, card mix, and markets.
Authorisation rate: the metric with the most leverage
Authorisation rate is the percentage of payment attempts that result in a successful transaction. For most European online retailers, this sits somewhere between 90% and 97% depending on channel, market, and product category. The spread between the bottom and top of that range represents real revenue.
A one percentage point improvement in authorisation rate on a business processing €50 million annually in card volume recovers approximately €500,000 in revenue that was otherwise declined. That is before any change to your cost structure. Pure volume recovery.
The headline rate, however, is where most merchants stop looking. A blended authorisation rate of 94% looks healthy. Your PSP will present it as such. But that figure is a weighted average across every payment method you offer, every market you operate in, and every card type that passes through your checkout. Drill one level down and the picture changes.
Take a typical Dutch retailer with iDEAL at 70% of volume and cards at 30%. iDEAL authorisation rates are consistently above 99%, which pulls the overall average up significantly. If your Visa credit card authorisation rate is sitting at 81% and your Mastercard authorisation rate for non-Dutch issuers is 74%, those figures are masked entirely by the iDEAL volume. The blended 94% tells you nothing is wrong. The method-level breakdown tells you exactly where revenue is leaking.
The euro value of that leakage is often material. A retailer processing €5 million annually in non-domestic card volume at a 74% authorisation rate, against a realistic benchmark of 88% for that card mix and market profile, is leaving roughly €700,000 in transactions on the floor every year. Not because of fraud. Not because of insufficient funds. Because of routing, configuration, or 3DS calibration that has never been reviewed.
This is the analysis PSPs do not volunteer. The data exists in your transaction logs. The question is whether anyone has asked for it and run the numbers against a credible benchmark.
The levers are more controllable than most merchants realise. Issuer-acquirer routing, the path a transaction takes from your PSP through to the cardholder’s bank, has a measurable impact on approval rates. Some PSPs offer intelligent routing across multiple acquirers. Others route through a single acquirer and present that as standard. Whether your contract gives you access to multi-acquirer routing, and whether your PSP has actually activated it, is worth checking.
3DS implementation is another lever that most merchants set once and never revisit. The SCA exemption strategy embedded in your 3DS flow, which transactions are submitted for frictionless authentication versus full challenge, directly affects both authorisation rate and checkout conversion. Getting this calibration wrong is common. The cost is usually invisible because declined transactions disappear from your analytics rather than flagging as configuration problems.
Network tokenisation, through Visa Token Service or Mastercard Digital Enablement Service, consistently shows authorisation rate uplifts of two to four percentage points on eligible card types in markets where it is supported. It is not universally active by default. Ask your PSP whether it is enabled on your account and whether the uplift data for your specific transaction mix is available.
Decline management: what your PSP is not telling you
When a card transaction is declined, your PSP receives a response code from the issuing bank. These codes are specific. “Insufficient funds” is different from “do not honour” which is different from “card blocked for online transactions” which is different from “suspected fraud.” Each requires a different response, if any.
Most merchant-facing dashboards collapse these into three or four categories. “Soft decline” and “hard decline” are common labels. They are operationally convenient for your PSP and analytically useless for you.
Soft declines, responses where a retry or a different routing path may succeed, are recoverable. The recovery rate depends on your retry logic, the timing of the retry, and whether the retry goes through the same acquirer or a different one. PSPs vary significantly in how aggressively they pursue soft decline recovery on your behalf, and the commercial incentive for them to do so is weaker than you might expect. A declined transaction costs them nothing. A recovered transaction requires processing resource.
Reviewing your raw decline reason distribution, not the dashboard summary, and mapping it against your retry configuration is one of the fastest ways to identify recoverable revenue. This is analysis your PSP can provide. Most merchants have never asked for it. Which is understandable, as it sits so far from their core business.
Free check: fraud and risk fees by payment method
While you have your invoice in front of you, do this. Go through every payment method you offer and identify which ones carry a fraud check or risk assessment fee. Then ask whether that fee makes any commercial sense for that specific method.
iDEAL is a common example. It is a bank-initiated push payment with no chargeback mechanism and near-zero fraud exposure for the merchant. There is no meaningful fraud risk for the PSP to assess. Yet some PSPs apply a fraud or risk fee to iDEAL transactions as a line item. The same applies to other guaranteed payment methods such as Bancontact, Klarna Pay Now, or direct debit where the risk profile is structurally different from card payments.
Fraud tooling on card transactions can be justified. The risk is real, chargebacks cost money, and a well-configured fraud engine protects margin. But applying the same fee logic to payment methods where fraud risk is either absent or borne entirely by the issuing bank is, in practice, free margin for your PSP. There is no service being rendered that justifies the charge.
The fix is straightforward: request a breakdown of all risk and fraud fees by payment method, cross-reference it against the actual fraud exposure for each method, and challenge every line that cannot be substantiated. This is a conversation most PSPs would rather not have, which is usually a reliable indicator that the fees in question are worth having it.
Acquiring margin and the hidden cost in performance data
PSP performance and PSP cost are not separate conversations. They are the same conversation.
Your effective cost per card transaction is not the rate on your contract. It is interchange, paid to the issuing bank, plus scheme fees, paid to Visa or Mastercard, plus your PSP’s acquiring margin, which is the part they actually control and the part where the real negotiation lives.
Where your PSP is also your acquiring bank, as is the case with most large processors today, interchange and scheme fees are pure pass-through. They are set by the issuer and the schemes, and your PSP cannot change them. Everything above that line is theirs. Under interchange-plus pricing, that margin is explicit and visible. Under blended or bundled pricing, it is folded into a single rate and you cannot see it at all. Merchants on blended pricing almost always pay more, and the gap widens as volume grows, because the pass-through costs stay flat while the margin scales with you.
Free check: look at your statement and confirm that interchange and scheme fees are shown as separate, identifiable line items. If they are not, you are on blended pricing, and the margin you are paying is invisible by design. You cannot manage what you cannot see. The first step toward bringing that cost down is making your PSP show you the components, which is a request they are obliged to honour and one that often changes the conversation on its own.
Look closely at how that margin is applied across card types. Many PSPs charge the same rate on debit transactions as they do on credit, despite the two carrying entirely different cost and risk profiles. Credit card transactions involve a line of credit extended by the issuer, deferred settlement, and a genuine risk position. Debit transactions draw on funds that already exist in the cardholder’s account and settle against them directly. There is little to underwrite and the regulated interchange cap is lower for debit in the first place. Charging an identical margin on both is margin without justification. If your contract applies a flat rate across debit and credit without distinction, that is a line worth challenging.
The connection to performance is this: when your PSP presents you with an authorisation rate, they are not showing you the cost of the transactions that were authorised. A high authorisation rate achieved through a routing or processing path that carries a higher margin may be improving one metric while quietly degrading another. Independent analysis looks at both simultaneously.
What a PSP performance audit actually covers
A proper performance audit starts with data you may need to request specifically: raw transaction logs with decline codes, settlement reports at the scheme and acquirer level, 3DS authentication outcomes by flow type, and chargeback data by reason code and product category.
From that data, the analysis identifies the gap between actual performance and achievable performance given your specific business model and markets. The output is not a report full of recommendations. It is a set of specific configuration changes, contract amendments, and routing adjustments, ranked by commercial impact, that you can take back to your PSP with evidence.
PSPs respond to this kind of structured, evidenced challenge differently than they respond to a merchant saying performance feels low. Evidence-based requests, framed in the PSP’s own data, are harder to dismiss and easier to escalate internally on your behalf.
The performance conversation your PSP is not starting
If your authorisation rate has been flat for two years, that is not evidence that your performance is optimised. It may be evidence that no one has pushed on it. PSPs do not proactively surface improvement opportunities that require them to do more work for the same fee. Account managers are measured on retention and upsell, not on the commercial outcome of your payment setup.
The merchants who consistently outperform on authorisation rates and keep their effective payment cost below benchmark have one thing in common: they treat the PSP relationship as a commercial negotiation, not an operational dependency. They know their numbers, they know the benchmark, and they know what to ask for.
That is precisely the gap EcomStream was built to close.
If your payment setup has not been independently reviewed, the work starts with seeing what your authorisation rate by method, your decline distribution, and your effective cost per transaction actually look like against the market. That is a full independent assessment, and it is the only thing that produces numbers you can act on. Get in touch and Ramon will take a look personally.
If you want a rough first indication before that conversation, the PSP Upside Calculator gives you a directional read in a few minutes. It is a starting point, not the analysis itself.
