Introduction

Checkout conversion is one of the few areas in commerce where engineering quality is directly visible in revenue. A form that takes 4 seconds to load, a payment error state that does not explain what failed, a 3DS2 challenge screen that appears for every transaction regardless of risk level: each reduces conversion, and each is an engineering problem, not a UX one.

The patterns that cause conversion loss accumulate quietly. Payment providers get integrated at launch and then left untouched as transaction volumes grow and new markets are added. SCA requirements introduced by PSD2 get addressed reactively, after launch, when friction is already visible in the funnel. Checkout pages that were fast enough at build time drift as third-party scripts accumulate. The instrumentation to detect these problems often does not exist until someone notices the revenue numbers.

Gradion approaches checkout as a full-stack engineering problem: payment provider selection and integration, PCI DSS scoping, SCA implementation, checkout performance, OMS connectivity, and funnel observability built in from the start.

Payment Provider Integration

Payment method coverage is determined by the markets served and the transaction volumes expected. Stripe covers most card-based flows with clean API design. Adyen is the enterprise standard for high-volume, multi-market operations with strong acquiring relationships. Mollie serves the European mid-market well, particularly for iDEAL and SEPA flows in the Netherlands and DACH. Klarna drives conversion in product categories where Buy Now Pay Later is a meaningful decision factor. For Southeast Asia, coverage requires different providers: PayNow for Singapore, PromptPay for Thailand, market-specific wallets that a single European PSP will not handle.

Integration work extends beyond connecting an API. Webhook handling for asynchronous payment events, idempotency keys to prevent duplicate charges on retried requests, failed payment retry logic with appropriate backoff, and reconciliation feeds that pipe transaction data into finance systems: these are the engineering tasks that determine whether a payment integration is actually reliable. roadsurfer's booking platform, supporting 7 currencies across European markets, is one example of this kind of multi-currency payment architecture running in production.

PCI DSS Compliance Architecture

The scope of PCI DSS compliance depends on how cardholder data flows through the system. A poorly scoped implementation pulls the full commerce platform into the compliance perimeter, multiplying the audit surface and the ongoing maintenance burden. Correctly scoped, tokenization ensures that card data never touches Gradion-built infrastructure: the PSP handles card capture, returns a token, and the merchant system works only with that token from that point forward. This limits the blast radius of any future incident and reduces the recurring cost of maintaining certification.

SCA and 3DS2 Implementation

Strong Customer Authentication, as required by PSD2 for European payment flows, adds a verification step to card transactions. Implemented without thought for transaction risk levels, it adds friction to every purchase. Implemented correctly, it uses the 3DS2 exemption framework to apply authentication challenges only where risk levels or transaction amounts require them, leaving low-risk transactions to proceed without interruption. The exemption logic sits at the PSP configuration layer and requires coordination between the acquiring bank, the PSP, and the checkout implementation.

Checkout Flow Engineering

Checkout performance on mobile is the standard that matters. A checkout page loading in under 2 seconds on a mid-range Android device in a 4G environment is a meaningful engineering constraint. Address validation, shipping method selection, and real-time tax calculation each add latency if implemented carelessly. A/B testable checkout flows require a feature flag layer that allows variants to be served without deploying code, enabling experiments on step count, field ordering, error messaging, and payment method presentation to run with statistical rigour.

Order Management and BNPL Integration

Checkout is not complete when payment is authorised. Inventory reservation, fraud screening, and the handoff to the OMS (Shopware, Spryker, or a custom fulfillment layer) need to be engineered as a connected sequence, not assembled from integrations that communicate loosely. Buy Now Pay Later providers (Klarna, Afterpay/Clearpay, Scalapay) require return and refund handling that flows correctly back to the BNPL provider and reconciles into the finance system; the conversion impact is product-category-dependent and worth measuring before committing to the integration overhead.

Observability

Checkout funnel instrumentation means tracking step completion rates, payment failure rates by provider and error code, and cart abandonment timing. A payment failure rate increase of more than a few percentage points typically indicates a PSP configuration issue, an SCA misconfiguration, or a downstream OMS problem. Without real-time visibility into these signals, issues accumulate before they surface in revenue reporting.

Proof in production

One of Europe’s largest digital payments companies had built its Shopware integration for on-premise environments. As merchants migrated to Shopware Cloud, the client was locked out of that growing segment: the existing plugin architecture relied on backend access that Shopware Cloud restricts. Gradion designed and built a cloud-native Shopware App from scratch, working within a backend-less, API-first environment with limited documentation and no existing precedent in the ecosystem. The app was delivered in three months and published on the Shopware Store, enabling non-technical merchants to install and configure the payment integration without development support. This is what PSP cloud migration looks like in practice - not a configuration change, but an architecture rethink under platform constraints.

Switzerland’s leading mobile payment app is Switzerland’s dominant digital payment method, covering 64% of Swiss digital payment transactions. Gradion built a reusable SDK framework around the Swiss payment app integration, reducing the time and engineering effort required to bring new merchants onto the platform. For commerce operators targeting the Swiss market, Switzerland’s leading mobile payment app integration is not optional coverage - it is the primary payment method for a large share of the buyer population.

A leading DACH payment infrastructure provider processing billions in transaction volume, worked with Gradion on engineering that contributed to a €1.4 valuation uplift at PE exit. Payment infrastructure that is reliable, well-instrumented, and correctly scoped for compliance is not a cost centre. It is a business asset with a measurable multiple.

roadsurfer: full rebuild of the booking and payment flow, launched in 20 days, with bookings and revenue doubling within the first year. The platform supports 8 languages and 7 currencies across European markets.

A leading German designer furniture retailer: supplier and order management platform delivered in 8 weeks, eliminating 70% of manual processing work and connecting procurement, warehouse, and finance on a unified system.

Next Step

Describe the checkout flow and the conversion or compliance constraint you are working with. We will scope the engineering.