A founder in Dublin once asked her development team a question mid-scoping call that had nothing to do with color schemes or checkout button placement: "If a customer's card gets charged twice because our server hiccuped, whose problem is that?" It's not the question most people expect from a first product conversation. But for anyone building a shopping app, it's usually one of the first things that comes up, right after "how much will this cost" and right before "how long will it take."
Payment gateway security isn't a feature you bolt on later. It shapes the architecture, the compliance paperwork, and the checkout experience from day one. Founders building their first shopping app tend to ask the same handful of e-commerce app development questions about security and compliance, usually in the first discovery call. This roundup answers the ones that come up most often, with practical implementation guidance rather than vague reassurance.
At Axire Infotech, these questions surface constantly during our Discovery & Planning phase, well before any wireframe gets touched. Below, we've grouped the most common ones founders across the UK, Ireland, the Netherlands, and the wider European market ask about payment security, and answered each with the kind of detail you can actually act on.
Most first-time e-commerce founders assume security is something a developer "handles in the background." It isn't. Payment security decisions affect which gateway you can use, how much of your checkout flow you're legally responsible for, and how fast you can launch in different European markets. Get it wrong early, and you're rebuilding checkout six months post-launch instead of adding features.
That's why this list leans heavily on PSD2, Strong Customer Authentication (SCA), and PCI DSS, the three frameworks that shape almost every payment decision for apps selling into the UK and EU. None of these require a law degree to understand. They do require a development partner who has actually implemented them, not just read about them.
Yes, if you're processing card payments from customers in the UK or European Economic Area. The revised Payment Services Directive (PSD2) requires Strong Customer Authentication on most electronic payments, meaning the customer must confirm the transaction using at least two of three factors: something they know (a PIN or password), something they have (a phone or card), or something they are (a fingerprint or face scan).
In practice, this shows up as 3D Secure 2 (3DS2) authentication during checkout, the step where a customer confirms a payment through their banking app or a one-time code. Not every transaction needs it. SCA has built-in exemptions:
The practical implementation step: your payment gateway (Stripe, Adyen, Mollie, and similar providers) handles most of the 3DS2 flow for you through their SDKs. Your development team's job is to integrate that SDK correctly, handle the authentication redirect or in-app prompt gracefully, and build fallback logic for when a bank's authentication step times out or fails. Skip this, and you'll see abandoned carts from customers stuck on a blank authentication screen.
For the overwhelming majority of founders reading this, the answer is: use a hosted or tokenized checkout, not a custom-built payment flow. Here's why this isn't a compromise, it's the standard approach even for well-funded companies.
When a customer enters card details directly into fields your app controls and your server touches that raw card data, you take on full PCI DSS compliance scope. That means quarterly network scans, annual audits, and a level of security overhead that most early-stage teams simply can't justify. When you use a gateway's hosted fields, embedded iframe, or mobile SDK instead, the card data never touches your servers. It goes straight from the customer's device to the gateway's PCI-certified infrastructure.
The goal isn't to avoid payment security work entirely, it's to let a specialized provider absorb the parts of compliance that don't need to be reinvented, so your team can focus on the shopping experience itself.
This is the same principle behind most of our API integration work for European e-commerce clients: connect to proven infrastructure rather than rebuilding it. Our web development team typically recommends tokenized SDKs from day one, even for MVPs, because retrofitting proper tokenization after launch means re-architecting your checkout and re-testing every payment path.
This is the question that causes the most anxiety, and it's usually based on a misunderstanding of scope. Most founders picture PCI DSS as a massive undertaking involving dedicated security staff and expensive audits. For apps using a hosted or tokenized checkout, the reality is far simpler.
The Payment Card Industry Data Security Standard (PCI DSS) has different compliance levels depending on how your app handles card data. If you never store, process, or transmit raw card numbers because your gateway's SDK handles that entirely, you typically qualify for the simplest self-assessment tier (commonly referred to as SAQ A). That means:
This is why gateway selection matters so much early on. Providers like Stripe, Adyen, and Mollie each publish clear integration guides for staying within the lowest compliance tier. A development partner who has implemented these integrations before, not one working from documentation for the first time, will save you months of back-and-forth with compliance reviewers.
Founders often ask us to lay out the tradeoffs side by side, since gateway choice affects development timeline, compliance scope, and how much control you have over the checkout experience. Here's how the three most common approaches compare:
Approach
PCI DSS Scope
SCA/3DS2 Handling
Development Effort
Checkout Control
Hosted/Redirect Checkout
Minimal (SAQ A) — customer leaves your app briefly
Fully managed by gateway
Low — fastest to launch
Limited branding and UX control
Embedded/Tokenized SDK
Minimal to moderate (SAQ A or A-EP)
Managed by gateway SDK, triggered in-app
Moderate, requires SDK integration and testing
Full visual control, native in-app feel
Custom Card Processing
Full (SAQ D), highest audit burden
Must be built and maintained in-house
High, significant security engineering
Complete control, rarely worth the risk
For nearly every founder we talk to, the embedded/tokenized SDK route offers the best balance: it keeps compliance scope manageable while letting the checkout feel native to your app rather than a jarring redirect to an external page. Custom card processing is rarely justified outside of large payment companies with dedicated security teams.
This is the double-charge question from the opening of this article, and it deserves a direct answer. When a payment fails partway through, whether due to a network timeout, a declined card, or a server error on your end, the risk isn't just a bad customer experience. It's the possibility of charging someone twice, or worse, taking their money without creating an order.
The practical fix is idempotency keys. Every payment request your app sends to the gateway should include a unique key tied to that specific checkout attempt. If the request gets retried, whether by a flaky connection or a customer double-tapping "pay now," the gateway recognizes the duplicate key and won't process a second charge. Most major gateways, including Stripe and Adyen, support idempotency keys natively.
Beyond that, your system needs webhook reconciliation: a background process that listens for payment confirmation events from the gateway and matches them against your internal order records. If a payment succeeds but your order database never got the message (say, your server crashed at the wrong moment), the webhook catches it and corrects the order status automatically. Without this, you get the support tickets nobody wants: "I was charged but never got a confirmation email."
European shoppers don't all pay the same way. iDEAL dominates in the Netherlands, Bancontact is standard in Belgium, Swish is common in Sweden, and Klarna's buy-now-pay-later options show up across several markets. If your app only supports card payments, you're leaving conversions on the table in exactly the regions Axire's clients tend to serve.
The good news: you don't need to rebuild your checkout flow for every payment method. Modern gateway SDKs bundle wallet APIs (Apple Pay, Google Pay) and local rails (iDEAL, Bancontact, Swish) into the same integration you already use for card processing. Your development team enables the payment methods relevant to your target markets through the gateway's dashboard and SDK configuration, rather than writing separate integrations for each one.
This modularity matters for founders planning to expand across borders. A store launching in the UK first but eyeing the Netherlands or Ireland next shouldn't need a checkout rebuild to add iDEAL support later. Our development planning process accounts for this from the start, so adding a payment method later is a configuration change, not a re-architecture.
Payment security and data privacy overlap more than most founders expect. Under the General Data Protection Regulation (GDPR), you're responsible for how customer data connected to a transaction gets collected, stored, and processed, even if the actual card data is tokenized and held by your gateway.
The practical approach here is data minimization: store only what your business genuinely needs. Order history, shipping addresses, and payment tokens for recurring billing are typically justified. Full card numbers, CVV codes, and unnecessary personal identifiers are not, and shouldn't be anywhere in your database. Separating personally identifiable information from transaction metadata also makes it far easier to honor data deletion requests without breaking your order history or accounting records.
If you want the fuller picture on data handling obligations for web and app projects, our API Integration FAQ covers how this plays out across CRM, ERP, and payment connections specifically.
A checkout flow that passes a quick manual test isn't the same as one that's ready for real customers. Before launch, a properly scoped e-commerce build should go through:
This kind of testing is built into our Development & Testing phase for every project, not treated as an optional add-on. It's one reason founders comparing quotes are sometimes surprised by timeline differences between agencies: a build that skips structured security testing will always look faster on paper, right up until launch week.
This question comes up constantly, and not just from founders worried about cost. Payment integration work involves enough moving parts (gateway SDKs, SCA flows, webhook reconciliation, PCI scope) that the real question isn't "can we build this ourselves," it's "does our team have done-before experience with this specific stack of problems."
For founders who choose to outsource React development, the value isn't just filling a skills gap. It's working with a team that's already handled the edge cases: what happens when a 3DS2 redirect fails on an older Android browser, how to structure webhook retries so a slow gateway response doesn't corrupt an order record, which SDK version actually supports the local payment method you need in a specific market. That experience is hard to build from scratch under a launch deadline.
Axire's development team works primarily in React, Next.js, and Node.js, with overlap into CET afternoons that keeps communication tight for teams across the UK, Ireland, the Netherlands, and the Nordics. If you're weighing whether to hire in-house or work with an outsourced partner for your first shopping app, our guide on freelancer vs. agency decisions for your first digital product lays out the tradeoffs in more depth, and our red flags checklist is worth reviewing before you sign with any partner touching payment infrastructure.
No. With a tokenized checkout, your app stores a reference token from the gateway instead of the actual card number. This is the recommended approach for nearly every e-commerce app and keeps your PCI DSS scope minimal.
Your payment gateway typically manages the dispute process and notifies you when a chargeback is filed. Your app's job is to make sure order and transaction records are complete enough to respond to a dispute quickly, another reason for clean webhook reconciliation.
Yes. Most major gateways support multi-currency processing natively, converting and settling based on your configuration. The security model doesn't change; the same tokenization and SCA rules apply regardless of currency.
Every reputable gateway provides a sandbox environment with test card numbers, simulated 3DS2 challenges, and mock webhook events. A proper build tests every payment method in sandbox before switching to live credentials.
The underlying gateway integration is similar, but PWAs have some browser-specific considerations around wallet APIs and redirect flows. Our PWA development guide covers how these builds handle payments and offline states.
The founders who ask these questions early are the ones who avoid rebuilding checkout six months after launch. Payment gateway security isn't a checkbox you tick before submitting to the app store, it's a set of decisions baked into your architecture from the discovery call onward: which gateway, which compliance tier, which payment methods, and which team actually understands the difference between SAQ A and SAQ D before your investors ask.
If you're scoping a shopping app and want a development partner who treats PSD2, SCA, and PCI DSS as part of the build rather than an afterthought, Axire Infotech's team works through exactly this process for clients across the UK, Ireland, the Netherlands, and the wider European market. Our app development and UI/UX design services are built around secure, conversion-focused checkout flows from day one, not retrofitted after a security review flags a problem.
Take a look at our recent projects to see how these principles play out in real builds, browse our full service list for e-commerce and API integration work, or read more on our blog for deeper dives into related topics. When you're ready to talk through your specific payment security requirements, contact our team to start the conversation.
Let's discuss your project and create something amazing together.
