Online Payments
Online payment optimization is not a one-time project. It is an ongoing discipline that directly determines how much revenue you collect from the traffic and customers you have already paid to acquire. Every percentage point of improvement in authorization rates, every basis point removed from your processing cost stack, and every friction reduction in the checkout flow compounds across millions of transactions.
The challenge is that most of the levers are either obscured by your payment provider, misaligned with their commercial interests, or simply never raised unless you ask the right questions. No provider can deliver every optimization you need, and not all optimizations that benefit you will benefit them. That is the starting point for any serious approach to online payment optimization.
This page covers the main domains: payment methods, checkout design, fraud management, authorization rates, payment orchestration, currency management, and compliance. For each one, the goal is to give you enough depth to identify where you are underperforming and to have a more demanding conversation with your PSP, acquirer, or internal team. If you want an independent assessment of where your setup stands today, PSP Upside Calculator is a good place to start.
Payment methods
Choosing which payment methods to offer sounds straightforward. In practice, it is one of the decisions most merchants get wrong, because the inputs they rely on are structurally biased. Specifically, a PSP earns differently on different payment methods. Card transactions processed through their acquiring infrastructure generate interchange and scheme fee revenue on top of their processing margin. Local payment methods such as iDEAL, Bancontact, SOFORT, or Swish are often routed through third-party connections where the PSP’s margin is thinner. That does not mean your PSP will actively mislead you, but it does mean you should validate their recommendations independently.
The correct starting point is your target market, not your provider’s product catalogue. Payment preference data varies dramatically by country. In the Netherlands, iDEAL accounts for the majority of online transactions. In Germany, SEPA Direct Debit and invoice-based payment carry substantial share alongside cards. In the Nordics, local wallets and bank transfers dominate segments that card networks would claim in other markets. Offering only cards in these markets is not a neutral decision. It is a conversion problem, and the cost of fixing it later, in lost revenue already realized by local competitors, is real.
Beyond market coverage, model the cost structure of each payment method carefully. Cards carry interchange (0.2% for consumer debit and 0.3% for consumer credit within the EU under the IFR, but significantly higher for commercial cards and non-EU issuers), scheme fees, and PSP margin. Alternative payment methods often carry a flat fee per transaction that is cheaper than cards above certain average order values and more expensive below them. Both sides of that equation matter. A payment method that improves conversion but costs more per transaction needs to be evaluated on net revenue impact, not conversion rate alone.
Transaction surcharging deserves a specific note here. It is legal in some jurisdictions and prohibited in others. Within the EU, surcharging on consumer cards is generally not permitted under PSD2. On commercial cards and certain alternative payment methods the rules differ by market. If you are considering surcharging to offset expensive payment method costs, get a legal opinion per market before implementing. The compliance and reputational risk of getting this wrong outweighs the cost saving in most scenarios.
One area that is consistently overlooked is payment method selection for cross-border sales. If you are selling into markets without a locally-acquiring acquirer, your authorization rates on card transactions will be lower and your costs higher than for a locally-present competitor. Adding local payment methods that do not depend on card acquiring, such as bank transfers or local wallets, can improve conversion and reduce cost simultaneously. This is not a niche optimization. It is a structural advantage that most merchants leave unaddressed for years. For a detailed view of available payment methods by market, see Payment methods.
Checkout process optimization
The checkout is where the entire upstream investment in product, marketing, and customer experience either converts or evaporates. Yet most merchants assess their checkout through a single metric, overall conversion rate, without understanding which specific elements drive abandonment, at which step, and for which customer segments. That aggregate number tells you almost nothing actionable.
Start with a granular funnel analysis. You need step-level drop-off data: how many customers reach the payment page, how many initiate the payment, how many complete it, and how many encounter an error. Within the payment step itself, separate the customers who abandoned before attempting a transaction from those who attempted and received a decline. These are fundamentally different problems. Treating them as one leads to the wrong interventions and continued revenue loss.
Guest checkout is one of the highest-impact single changes available to any merchant that does not offer it. Requiring account creation before purchase is a conversion killer, particularly for new customers on mobile. The evidence consistently shows that forced registration increases abandonment, and the accounts created under compulsion have poor activation rates regardless. Offer guest checkout as the default path, and introduce account creation as an option after the transaction completes, when the customer is already committed and the friction is no longer a barrier to conversion.
Payment page design affects authorization rates, not just conversion rates. A poorly designed payment form that causes customers to enter card details incorrectly generates technical declines that have nothing to do with the customer’s ability or willingness to pay. A payment page that displays unfamiliar or untrustworthy elements around the payment form generates abandonment before submission. Clear, consistent, and simple payment page design is therefore both a UX consideration and a payment performance consideration. The two are inseparable.
Mobile optimization requires explicit attention. In most European markets, more than 60% of e-commerce sessions now originate on mobile devices. If your checkout has not been designed and tested specifically for mobile, you are almost certainly losing conversion on the majority of your traffic. Pay particular attention to keyboard type on card number and expiry fields, autofill compatibility, and the behavior of 3DS challenge flows on mobile browsers. A 3DS challenge that opens in a new tab on mobile and fails to redirect back to your confirmation page is a material source of lost transactions that rarely surfaces clearly in standard PSP reporting. It is worth a dedicated test.
Saved payment methods and one-click purchasing improve repeat purchase conversion significantly. Implementation requires tokenization, either through your PSP or through network tokenization via Visa Token Service or Mastercard Digital Enablement Service. Network tokens are preferable because they survive card renewals and replacements without requiring the customer to re-enter details. PSP-level tokens, by contrast, are portable only as long as you remain with that PSP. This creates a switching cost that grows with your stored credential base. If your PSP recommends their proprietary token vault as the primary mechanism for card-on-file storage, understand the migration implications before committing at scale. For more on checkout flow optimization, see Checkout flow optimization.
Abandoned cart recovery through email or SMS is well-established, but few merchants integrate payment-specific recovery logic. If you know a customer reached the payment page and abandoned without attempting a transaction, the recovery message should reflect that. If you know they attempted a transaction and received a specific decline, the recovery strategy should address that reason directly, for example by offering an alternative payment method if the decline was issuer-related. Generic basket abandonment messaging applied uniformly to all abandonment types is significantly less effective than segment-specific recovery flows built around what actually happened at the payment step.
Fraud management
Fraud management is one of the areas where merchant interests and PSP interests are most visibly misaligned. Your PSP has an incentive to minimize their own exposure to fraud-related losses and chargebacks. That is not the same as minimizing your fraud rate at an acceptable approval rate. Over-aggressive fraud rules protect the PSP’s chargeback ratio while generating false positives that decline legitimate customers. You absorb the revenue loss. They absorb less risk.
The right calibration is your fraud rate against your false positive rate, evaluated in the context of your business. A 0.05% fraud rate sounds excellent until you realize your false positive rate is 3%, meaning you are declining 60 legitimate transactions for every fraudulent one you block. The revenue destroyed by false positives is almost always larger than the fraud losses they prevent, particularly in markets with strong consumer protection regulation where chargeback liability is already capped.
Understand exactly how your PSP’s fraud tool works. Most PSPs offer a rules-based system, a machine learning model, or a combination. Rules-based systems are transparent and auditable but static. They do not adapt to evolving fraud patterns and they apply blanket logic that does not account for customer-specific context. Machine learning models adapt more dynamically but are often black boxes. Ask your PSP for decline reason breakdowns by fraud rule or model output. If they cannot provide this, you cannot optimize it.
3DS and SCA add a layer of authentication that shifts chargeback liability to the issuer on authenticated transactions. This is valuable, but the implementation has significant nuance. Applying 3DS universally increases friction and reduces conversion. The right strategy uses SCA exemptions, particularly Transaction Risk Analysis (TRA) exemptions, selectively on low-risk transactions where the conversion benefit outweighs the liability shift. TRA exemption eligibility is tied to your fraud rate thresholds (below 0.13% for transactions up to €100, below 0.06% for transactions up to €250, and below 0.01% for transactions up to €500 under PSD2 rules). If your PSP is managing your TRA exemption strategy, verify that they are actually monitoring your fraud rates against these thresholds per acquirer, not just applying a default exemption policy across your entire transaction volume. Misconfiguration here is common and the consequences range from issuer override of your exemptions to regulatory exposure.
Chargeback management is a distinct discipline from fraud prevention. Chargebacks arrive after the transaction has completed, often weeks later, and managing them effectively requires good transaction documentation, rapid response processes, and an understanding of the specific dispute reason codes. Some chargebacks are genuine fraud. Others are friendly fraud, where a customer disputes a legitimate transaction. Others are processing errors. Each category requires a different response. Lumping all chargebacks together and treating them as a single operational problem is expensive. Tracking chargeback reason codes over time also gives you an early warning signal when a fraud vector is emerging before it reaches the threshold that triggers scheme monitoring programs.
One frequently overlooked risk: scheme monitoring programs. Both Visa and Mastercard operate programs that monitor merchants’ chargeback and fraud ratios. Breaching the thresholds, which are lower than most merchants realize, triggers escalating fees and, in severe cases, loss of card acceptance rights. Your PSP should be flagging your status against these programs proactively. If they are not, ask for a monthly report that shows your chargeback and fraud ratios measured against scheme thresholds, per acquirer BIN.
Authorization rate optimization
Authorization rate optimization delivers among the highest returns of any investment available to an online merchant. Yet it is consistently underprioritized, partly because your PSP reports your overall authorization rate without the segmented view needed to identify what is actually driving declines, and partly because some of the most effective levers involve your PSP ceding margin or routing control.
Begin with segmentation. Your aggregate authorization rate is almost meaningless for optimization purposes. You need it broken down by card type (consumer debit, consumer credit, commercial, prepaid), issuing country, decline reason code, and transaction channel (new card-on-file, recurring MIT, customer-initiated). Each combination behaves differently and responds to different interventions. A high decline rate on non-EU commercial cards requires a different response than a high decline rate on domestic consumer debit, and conflating them produces neither diagnosis nor solution. For help benchmarking your current authorization performance, see PSP performance optimization.
Decline reason codes are your primary diagnostic tool. The codes returned by issuers follow a standardized taxonomy across Visa and Mastercard, but the granularity of what you actually receive depends on what your PSP surfaces. Some PSPs normalize or aggregate decline codes in ways that obscure the root cause. Insist on raw reason code data at transaction level, or at minimum a breakdown by code at daily or weekly frequency. Even broad codes like “do not honor” (05) become informative when correlated with specific issuers, card types, or transaction amounts. Patterns in that data point to specific interventions.
Soft declines, where the issuer requests additional authentication rather than refusing the transaction outright, are recoverable. However, the recovery rate depends entirely on your retry configuration. A naive retry, the same transaction resubmitted immediately with no changes, has a poor recovery rate and risks triggering the issuer’s velocity controls. An optimized retry strategy introduces a time delay, uses updated transaction data where available, and where appropriate adds a 3DS challenge step on the retry. That last point matters: for a transaction that soft-declined specifically because the issuer wanted authentication, adding a 3DS challenge on the retry directly addresses the reason for the decline. Merchants without this logic in place are leaving recoverable revenue on the table consistently.
Network tokenization is the single most impactful technical optimization that most merchants have not yet implemented. Visa Token Service (VTS) and Mastercard Digital Enablement Service (MDES) replace the raw PAN in the authorization request with a scheme-issued token bound to your specific merchant relationship. Issuers treat tokenized transactions with higher trust because the token signals that the merchant has been validated and card credentials have not been exposed in transit. The documented result, across multiple large-merchant implementations, is a 1-3 percentage point improvement in authorization rates on eligible transactions. Secondary benefits include automatic token updates when a cardholder receives a replacement card, eliminating a significant source of involuntary churn in subscription and recurring billing models. If your PSP has not proactively recommended network tokenization, ask for a clear explanation. The implementation effort is low. The commercial case is straightforward. The absence of this conversation is itself a signal about where their priorities sit.
Acquirer routing is the layer most merchants have no visibility into at all. When you submit a transaction through your PSP, that PSP routes it to one or more acquiring banks based on their own logic. That logic reflects their commercial relationships, their infrastructure, and their margin optimization. It does not necessarily optimize for your authorization rate. The same card, processed through different acquirers, can produce materially different authorization outcomes because different acquirers have different BIN-level relationships with issuers and different technical infrastructure. If you process exclusively through a single acquirer, you have no benchmark and no fallback. Merchants with significant card volume should understand exactly how transactions are being routed and push their PSP for acquirer-level authorization data that allows proper evaluation. For a structured review of your PSP setup, see Cut your PSP costs.
For merchants with subscription or recurring billing models, merchant-initiated transaction (MIT) flagging is foundational but errors are more common than they should be. An MIT flagged incorrectly as a customer-initiated transaction may fail SCA requirements and decline. An MIT processed without the correct prior agreement reference will be rejected by many issuers. Getting the MIT framework right, including the initial cardholder agreement, the subsequent transaction flagging, and the stored credential framework, is a prerequisite for reliable recurring revenue collection.
Payment orchestration
Payment orchestration is a term that covers a wide range of capabilities, from basic PSP redundancy to sophisticated real-time routing across multiple acquirers, fraud tools, and payment methods on a single API. Understanding what you actually need, and what you are being sold, requires some precision.
At its most fundamental, payment orchestration addresses a single problem: dependency on a single payment provider creates concentration risk and removes your ability to optimize routing. If your PSP experiences downtime, you stop taking payments. If their authorization rates are poor on a specific card type or geography, you have no alternative. If their pricing is uncompetitive, switching costs are high because your entire payment stack is embedded in their infrastructure. Orchestration solves all three by abstracting your payment logic from any single provider.
The practical question is at what stage this investment makes sense. For merchants below roughly €20 million in annual card volume, a well-negotiated single-PSP setup with appropriate redundancy built into the contract is often sufficient. The incremental authorization rate benefit of multi-acquirer routing at low volume does not typically justify the integration and operational overhead of a full orchestration layer. For merchants above that threshold, particularly those operating across multiple markets with different payment method mixes, the calculus changes materially.
Cascading, sometimes called failover routing, is the most basic form of orchestration. When a transaction declines with the primary acquirer, it is automatically retried with a secondary acquirer. This recovers a subset of declines that are acquirer-specific rather than issuer-specific. The recovery rate varies, but for merchants processing in markets where acquirer infrastructure quality varies, or for cross-border transactions where local acquiring is not available, cascade routing can produce meaningful authorization rate improvements at relatively low implementation cost.
Intelligent routing, the more sophisticated version, uses transaction-level data such as card BIN, issuing country, transaction amount, and historical authorization performance to route each transaction to the acquirer most likely to approve it, in real time. This requires either a dedicated orchestration platform or a PSP with genuine multi-acquirer routing capability, which is rarer than the marketing language suggests. Many PSPs describe themselves as orchestration platforms while routing exclusively through their own acquiring infrastructure. Ask specifically: how many independent acquirers does the platform route to, can you see acquirer-level authorization rate data by BIN range, and does the routing logic optimize for your authorization rate or for the platform’s margin?
Cost optimization through orchestration is the second major benefit. Beyond authorization rate improvement, intelligent routing can direct transactions to the lowest-cost acquirer for a given card type, potentially generating significant processing cost reduction on high-volume card types. This requires detailed cost modeling across acquirer fee schedules and scheme fee structures, but for merchants with the volume to justify it, the savings are material.
One commercial reality worth stating plainly: if your current PSP is also your orchestration provider, you should be skeptical about whether their routing is truly neutral. A PSP that earns acquiring margin has an incentive to route through their own acquiring infrastructure rather than a cheaper or better-performing external acquirer. True orchestration independence requires either a dedicated, acquiring-agnostic orchestration layer or a contractual commitment from your PSP to provide genuinely neutral routing with auditable data to prove it.
Local currency support
Selling in multiple currencies looks operationally simple. In practice, currency management is a significant cost and risk area that most merchants understand only after they have lost money on it, often without realizing the leakage was happening.
The first question is whether you present prices to customers in their local currency or in your base currency. Customers consistently show higher conversion rates and lower abandonment when they see prices in their own currency and know exactly what they will be charged. Presenting prices in euros to a Swedish customer who will see a different SEK amount on their bank statement creates a transparency problem that erodes trust, increases post-purchase disputes, and depresses conversion. The fix is to present in local currency, charge in local currency, and settle in a way that gives you predictable and transparent economics.
Dynamic Currency Conversion (DCC) deserves specific attention because it is frequently implemented in ways that benefit the PSP and acquirer at the customer’s expense. DCC allows a foreign cardholder to pay in their home currency at the point of transaction, with the conversion performed by the acquiring bank or PSP rather than the cardholder’s issuer. The conversion rate is typically unfavorable, and the margin generated flows to the acquiring bank or PSP, sometimes with a small share back to the merchant. The regulatory environment around DCC has tightened significantly under PSD2, which requires clear disclosure of the conversion rate and explicit customer consent. Implementations that do not meet this standard create regulatory and reputational risk. If your PSP presents DCC as a revenue opportunity, model the customer experience impact carefully before agreeing. The short-term revenue share rarely justifies the conversion impact and compliance exposure.
Hidden FX fees are one of the most consistent and least visible cost items in payment processing for merchants selling cross-currency. The scenario is straightforward: you sell in GBP to a UK customer, your PSP processes and settles to you in euros, and somewhere in that conversion a spread is applied that is neither disclosed nor itemized on your settlement statement. The spread can range from 0.5% to 2% or more depending on the PSP and currency pair. Across meaningful cross-currency volume, this represents a significant annual cost that many merchants have never explicitly identified. The diagnostic is simple: for any currency where you do not receive like-for-like settlement, compare total revenue at the rate you used to price transactions against the actual settlement amount converted at the same reference rate. The difference is your FX leakage. If your PSP cannot show you a transparent FX rate and settlement reconciliation per currency, assume the leakage exists and quantify it before your next contract renewal. For support with this analysis, see Cut your PSP costs.
Settlement currency optimization follows naturally from that analysis. If you carry operating costs in multiple currencies, settling in those currencies rather than converting everything to a single base currency reduces your FX exposure directly. This requires your PSP or payment infrastructure to support multi-currency settlement, which not all providers do. If yours does not, the alternative is to work with your treasury function to hedge the FX exposure at a lower cost than the spread you are currently paying to your PSP.
Licensing and Compliance
Licensing and compliance in online payments is an area where the consequences of getting it wrong are severe, the rules change regularly, and the advice from payment providers is not always complete or disinterested. Your PSP has an incentive to keep you processing through their infrastructure. If a licensing or compliance issue would require you to change your model or find alternative infrastructure, they may not surface it proactively.
PCI DSS compliance is the baseline. The Payment Card Industry Data Security Standard applies to any business that accepts, processes, stores, or transmits card data. The applicable compliance level depends on your annual card transaction volume and how card data flows through your systems. Most merchants processing through a PSP-hosted payment page or fully outsourced checkout flow qualify for SAQ A, the simplest self-assessment questionnaire, because they never touch card data directly. But if you use a custom payment form where card details are entered on your own domain, even briefly before being submitted to your PSP’s API, your scope widens significantly and your compliance obligations increase. This is a technical architecture question with serious compliance implications, and it should be evaluated explicitly rather than assumed.
Tokenization, both network tokenization and PSP-level tokenization, reduces your PCI scope because card data is replaced by a token before it enters your systems. This is one of the practical compliance benefits of tokenization that sits alongside the authorization rate uplift discussed earlier.
PSD2 and Strong Customer Authentication represent the most significant regulatory change to European online payments in a decade. SCA mandates multi-factor authentication for customer-initiated electronic transactions within the EU and EEA, with specific exemptions that must be correctly configured to apply. The merchant-facing implication is that 3DS2 must be properly implemented, exemptions must be claimed through the correct technical path, and the liability framework that accompanies each exemption must be understood. An exemption claimed incorrectly does not protect you from chargeback liability. An exemption not claimed where it could be leaves unnecessary friction in your checkout.
The marketplace dimension of PSD2 is more complex and more consequential than most merchants operating marketplace or platform models currently recognize. PSD2 introduced restrictions on the “commercial agent” exemption that many marketplaces had historically relied on to avoid needing a payment institution license. If your business model involves collecting payments from customers on behalf of third-party sellers, holding funds before disbursement, or netting payments across multiple parties, you may be operating in a space that requires a payment institution license under PSD2. The thresholds and conditions are specific and fact-dependent, but the consequences of operating without the required license, including regulatory action, fines, and potential suspension of payment processing, make this a question that should be answered with qualified legal advice rather than left to assumption.
GDPR intersects with payment data in ways that are not always obvious. Transaction data is personal data. Payment behavioral data, purchase history, and stored payment credentials all fall within scope. If your PSP is providing analytics, fraud scoring, or behavioral data services that involve processing transaction data across their merchant base, the data sharing arrangements and consent mechanisms require careful scrutiny. This applies particularly when evaluating new payment providers or fraud tools that are built on consortium data models, where your customers’ transaction data contributes to and is informed by a broader pool of data from other merchants’ customers.
Client references
