Guide

Checkout decisions shape the whole build

Your payment setup affects conversion, operational cost and how easily you can expand to new markets. This guide helps you make the right decision based on your platform and business context.

Related platforms

Why payment deserves more attention

In most ecommerce projects, payment planning comes late. Platform, design and product data get the bulk of attention, while the checkout flow is added toward the end. That works — until it doesn't. The payment setup sits at the intersection of customer experience, order management and finance. A decision made too quickly can create constraints that surface only when launching in a new country, during a high-traffic campaign, or when the finance team needs to reconcile against the ERP.

This guide approaches payment from that perspective: as part of a delivery project, not as an isolated technology choice.

What a payment provider actually does in the stack

A PSP (Payment Service Provider) handles the transaction between customer and merchant. But in practice, it does more: it determines which payment methods are available at checkout, how order statuses are communicated back to the platform, how returns and partial payments work, and what reporting the finance team gets access to.

When evaluating providers, look beyond the list of payment methods. Ask instead: How does the connection to our ecommerce platform work? Is there a maintained integration, or does it require custom development? How are stuck orders handled — for instance, timeouts or reserved amounts that aren't captured? What about reporting — are manual reconciliations needed against the ERP, or can it be automated?

Those are the questions where the real differences between providers become clear.

Checkout experience: where conversion meets payment

Checkout is where the payment choice becomes visible to the customer. How it's built affects drop-off rates directly. Three factors matter most:

Number of steps. A single-step checkout doesn't necessarily convert better than a multi-step one — but it must be clear. The customer should understand where they are in the flow and what happens next.

Local payment methods. In Sweden, consumers expect to pay with Swish, cards, invoice and partial payments. The right combination depends on your target audience and average order value — and your PSP determines which methods you can offer and how easily you can add new ones when expanding.

Embedded vs. redirect. Some providers offer an embedded checkout that stays within your store. Others redirect the customer to an external page. The choice affects both conversion and how much design control you retain. If your PSP provides its own checkout view, evaluate how well it can be customised to match your brand — colours, typography, payment method ordering and the mobile experience. A checkout that looks generic or breaks with the rest of the site creates friction and reduces trust.

Platform and integration: what drives complexity

The integration between payment provider and ecommerce platform is rarely a problem for standard setups. But as soon as you have specific needs — B2B pricing, multi-currency handling, partial payments, or a headless architecture — requirements increase.

On Shopify, Shopify Payments is the built-in option, with the advantage of sitting close to the platform's order flow. Third-party providers work via Shopify's Payments API but with some limitations in reporting and order management.

On Magento/Hyvä, Shopware and Norce, there are more options. Providers like Svea, Walley, Kustom, Mollie and Adyen have ready-made modules for most platforms, but integration quality varies. Always ask: Who maintains the module — the provider or a third party? How quickly is it updated when the platform releases new versions?

In headless setups — where frontend and backend are separated — the payment flow needs to be handled via API. This gives full control but places higher demands on development resources and testing. See our headless commerce guide for more on that approach.

Multiple markets, multiple payment methods

Expanding to new countries means new payment expectations. In Sweden, Swish, cards, invoice and partial payments dominate. In Denmark MobilePay is widespread, in Germany PayPal and Sofort, and in the Netherlands iDEAL.

Your PSP determines how easy it is to activate new methods per market. Some providers, like Adyen and Mollie, offer broad coverage through a single integration. Others require separate agreements per country or method.

Beyond payment methods, currency handling and tax calculation come into play. That's rarely the PSP's responsibility — but it's part of the same delivery scope. Read more in our internationalisation guide.

B2B: different rules for payment

Business customers rarely pay by card at checkout. Invoice, partial payment and real-time credit checks are more common. Providers like Briqpay, Avarda and Svea specialise in handling B2B checkout with credit assessment and invoice flows.

In B2B projects, the payment integration is often more tightly coupled to the ERP — order status, credit limits and customer terms need to flow between systems. See our B2B guide for a broader view of what a B2B build involves.

How to evaluate a payment provider

Don't choose a PSP based on a pricing sheet or a list of payment methods. Instead, start from seven areas that together determine how well the provider works in your project:

1. Transaction cost. Pricing models vary: fixed fee per transaction, percentage-based, or a combination. Some providers use “blended pricing” where everything is bundled into one figure, others “interchange++” where the bank's cost is shown separately. A lower percentage doesn't always mean lower total cost — also check setup fees, monthly charges, refund fees and currency conversion costs. Calculate based on your actual order mix, not a single scenario.

2. Checkout experience. If the PSP offers its own checkout view — a “hosted checkout” — it directly affects how the customer experiences the purchase. Evaluate how well the checkout can be visually customised, how it performs on mobile, and whether the payment method ordering can be controlled. A checkout that loads fast, feels familiar and shows the right options first reduces drop-off. Always request a demo or test environment before committing.

3. Platform support. Is there a maintained integration for your platform? Who is responsible for updates? How quickly does the module keep pace with platform releases?

4. Market reach. Does the provider support the countries and payment methods you need today and within 12–18 months? Also check whether local methods can be activated directly or require separate agreements.

5. Order flow. How does it handle interrupted payments, partial returns, reservations? Does it require manual intervention, or does the PSP resolve it automatically against the platform?

6. Approval rate and fraud protection. Not all PSPs have the same approval rate — the share of transactions that go through without being declined. Ask whether the provider offers smart routing, retry logic and customisable fraud rules. Strong security must not come at the cost of legitimate purchases being blocked unnecessarily.

7. Reporting, reconciliation and settlement. Can transaction data be connected to the ERP without manual work? How often does payout occur — daily, weekly, or with a longer delay? Settlement terms directly affect your cash flow.

The evaluation should happen early in the project — not as an add-on after the platform decision is made.

FAQ

Can we use multiple payment providers at the same time?

Yes, it's common to combine providers — for example one PSP for card payments and a separate provider for Klarna or invoice purchases. It requires that your platform supports multiple payment modules in parallel, which most do.

How does PSP choice affect checkout speed?

A PSP with an embedded checkout avoids redirects and reduces load time. But the biggest impact on speed comes from the platform's frontend performance, not the PSP itself.

What should we consider when switching payment providers on an existing site?

Migrate active subscriptions and saved cards first. Test the new flow in a staging environment with real test orders. Plan a transition period where both providers are active in parallel.

How does payment integration differ in a headless setup?

In a headless architecture, the payment flow is handled via the PSP's API rather than a ready-made platform module. This gives full control over checkout design but requires more development effort and thorough testing of error handling, returns and reservations.

Do we need PCI DSS certification if we use a PSP?

In most cases no — the PSP handles card data and holds the certification. You do need to follow SAQ A or SAQ A-EP depending on how the checkout is integrated. Your PSP can specify which level applies.