Meet us at conferences around the world
SBC Summit Lisbon
SiGMA Europe
DDoS doesn't just take down websites — it can break checkout, 3-D Secure redirects and payment notifications. When you choose a payment provider, availability under attack is a contract-level question, not a marketing claim. Any merchant with a revenue peak is a target: a ticket on-sale draws the same unwanted attention as any other predictable high-traffic window.
Technically reviewed by the Payneteasy infrastructure team lead.
DDoS payment availability — whether payments keep flowing while an attack is under way — is the one thing a payment provider cannot improvise. Once an attack starts, either checkout, the 3-D Secure redirect and the payment notifications keep working, or the revenue stops. The questions below are the ones worth asking before a contract is signed — each one with the answer a serious provider should be able to give, and the artifact that backs that answer up.
Most conversations about DDoS start and end with the corporate website. That is the visible failure — a slow homepage, an error page, a headline someone screenshots. It is rarely the expensive one.
The costlier target is narrower: the hosted payment page, the checkout flow, and the webhook or callback endpoints that carry 3-D Secure redirects and payment notifications. These can break even while the main website stays up and shows green. A slow checkout page raises cart abandonment. A stalled 3-D Secure redirect leaves a transaction stuck mid-authentication. A flooded notification webhook can mean an order is paid for but never marked as paid — a reconciliation problem that surfaces days later, not an alert that fires in real time.
That is why "is your website resilient" is the wrong opening question for a payment provider. The better one is narrower: is the part of the stack that actually touches money protected the same way — and does it fail the same way — as the marketing site? The ten questions below are how you find out.
The ten questions below do not require you to be a network engineer, but the answers come back in a particular vocabulary — the attack vectors and the mitigation strategies that answer them — worth knowing in advance. A DDoS — distributed denial of service — is a malicious attempt to make online services unavailable to legitimate users by directing traffic at them from multiple systems at once. The sources are usually botnets: thousands of hijacked devices — servers, routers, phones — each flooding traffic from its own IP address. Financial institutions and payment systems are attractive targets because downtime means lost revenue, and because attacks can be timed: gaming companies see them at launches, ticketing during on-sales, online banking around paydays.
| Attack family | What it does | What mitigation looks like |
|---|---|---|
| Volumetric attacks UDP floods, ICMP floods, amplification attacks | Saturate bandwidth capacity with malicious traffic; the classic sign is a sudden surge of incoming traffic out of nowhere. | Traffic filtering upstream of the platform, and content delivery networks that absorb large-scale attacks before they reach core systems. |
| Protocol attacks SYN floods are the textbook case | Work at the network layer: exhaust the connection state of a targeted server or the network devices in front of it, rather than raw bandwidth. | Rate limiting, and load balancing across multiple servers so no single point holds all the state. |
| Application layer attacks the most relevant to payments | Mimic legitimate users loading pages, submitting forms, hitting checkout or login portals — which is exactly what makes them expensive to filter. | Web application firewalls plus behavioral analysis and anomaly detection — separating abnormal traffic patterns from real buyers by shape, not volume. |
Not all DDoS attacks arrive alone, either. Volumetric DDoS attacks can be cover for a quieter attempt to exploit vulnerabilities elsewhere, which is why serious DDoS defense treats availability as a security discipline, not just a bandwidth problem. Competent DDoS mitigation is layered. It starts with early detection: real-time monitoring and threat intelligence. Behind that sit security teams with a rehearsed incident response, and redundant infrastructure that keeps critical services degraded rather than fully unavailable until normal operations are restored.
For the financial sector, this is not optional. In the EU it now has a name: the Digital Operational Resilience Act (DORA) requires financial entities and their critical ICT providers to test operational resilience against cyber threats, DDoS included, and to show continuity plans that name availability explicitly. For a merchant the translation is narrower: website availability is not the metric that matters; whether payment gateways, mobile apps and the APIs behind them keep processing is. The questions below are how to find that out, and how to tell a provider that can actually mitigate damage from one that can only describe protection in the abstract.
Why it matters: A Layer 7 (application-layer) DDoS attack is expensive to filter because it mimics real browser traffic — page loads, form submissions, checkout attempts — instead of just flooding bandwidth. If checkout, the transactional API and the marketing site share the same protection tier, an attack tuned for one can degrade the others: mitigation calibrated for the noisy public site can throttle real buyers on the payment page, and a flood on a blog post can starve the API of resources. Separation is not a security nicety — it is what keeps a bad day on the website from becoming a bad day on revenue.
What a good answer sounds like:
a plain description of real separation — different infrastructure, not just a different subdomain on the same box — covering both the hosted payment page and the transactional API, tuned for transactional traffic and independent from the corporate website. A generic "we use a CDN" or "everything runs in the cloud, so it's fine" does not answer this. Ask to see how a hosted payment page and the API are set apart from the rest of the site.
Why it matters: The WAF, CDN or DNS layer that protects checkout is itself infrastructure, supplied by a vendor, and that vendor is a single point of failure like any other dependency. A mitigation-vendor outage looks, from the merchant's side, identical to a platform outage — the payment page is unreachable either way, and the cause is invisible to you.
What a good answer sounds like:
a provider that can describe, in general terms, how it plans for that case — regional failover, DNS resilience, what degraded (rather than fully down) looks like — without needing to name specific vendors or disclose its own configuration. A considered account of what happens when the protection layer itself has a bad day is a more useful answer than a blanket assurance that it will not.
Why it matters: An acquirer outage, or an attack aimed at one processing path, does not have to become your outage. If a provider can only send transactions down a single route, one bank's bad day is your bad day. If it can reroute automatically, one path degrading is a blip instead of an incident.
What a good answer sounds like:
multi-acquirer routing with cascading — a declined or unreachable attempt retried automatically through another configured route, with no manual step. This is publicly describable architecture; ask a provider to walk you through how its orchestration and cascading actually behaves when one path goes down, not just whether it exists.
Why it matters: Webhooks, callbacks, and 3-D Secure redirect endpoints are often the least protected part of a payment integration, built for machine-to-machine traffic that gets less attention than checkout. A flood here doesn't need to take down a website to cause damage — it can desynchronize a merchant's order state from the provider's. There's also a subtler failure: anti-bot protection meant to guard checkout can itself block machine-to-machine traffic it was never designed to handle. A callback or 3-D Secure (ACS) return call can't solve a CAPTCHA, so if those paths aren't excluded from bot-challenge rules, the protection ends up blocking the very notifications it should let through.
What a good answer sounds like:
rate limiting, retry-safe design so a dropped notification gets redelivered instead of lost, and monitoring on notification and 3-D Secure redirect traffic specifically, not just on the main site. Ask, specifically, whether callback and 3-D Secure (ACS) return paths are excluded from bot-challenge rules, whether scheme and acquirer IP ranges are allowlisted, and what happens to transactions already in flight at the moment mitigation switches on.
Why it matters: A ticket on-sale or a flash promotion can look like an attack to a defence system that is not tuned for payments — a burst of real buyers hitting checkout in the same second. If mitigation treats that burst as hostile, you lose real revenue to false positives: legitimate customers get challenged, rate-limited, or blocked exactly when you need them to convert.
What a good answer sounds like:
a description of how the provider distinguishes traffic shape from raw volume, plus candor that mitigation can add friction — extra checks, slower responses — and how that friction is minimized during an active event. "You'll never notice" is not a credible claim; a considered tradeoff is.
Why it matters: A general uptime SLA for "the platform" can be technically true while checkout is degraded, if it is written around infrastructure uptime rather than transaction success. Ask what the SLA actually covers, and whether it distinguishes a full outage from degraded performance under load.
What a good answer sounds like:
a document you can read, not a verbal assurance, naming checkout and API availability specifically.
Why it matters: An attack does not have to cause a full outage to cost money. Added latency, timeouts, or friction can quietly depress approval rates by pushing marginal transactions into decline. Ask what exists and in what form: does the provider track approval-rate impact specifically, as distinct from simple uptime, and can it show you that data.
What a good answer sounds like:
an incident-history summary with approval-rate context — "here is what that looked like the last time it happened" — which is a stronger signal than a general capacity claim, because it shows the provider measures the thing that matters to you, not just the thing that is easy to report.
Why it matters: How a provider talks about its bad days says more than how it talks about its good ones. Ask what exists and in what form: is there a status page you can check in the moment, and is there an incident-history summary or written account afterward describing what happened and what was affected.
What a good answer sounds like:
a public or customer-facing status page, plus a commitment to a post-incident writeup describing what happened, what was affected, and what changes as a result. A specific process, even a modest one, tells you more than a general assurance. As one example, Payneteasy publishes a public status page at status.payneteasy.eu: availability is measured and reported there by an independent monitoring service, which the SLA names as the agreed source of availability data, and processing is reported as a separate check from the user interface — so the transactional path can be read on its own.
Why it matters: What matters isn't whether a provider has "worked with your industry" in the abstract, but whether it has handled your specific peak-load profile: the ratio of normal to peak traffic, how long the surge lasts, and what breaks first — connection limits, queueing, database contention, or the mitigation layer itself. A provider that has only run steady, low-variance traffic hasn't been tested the way your peak will test it.
What a good answer sounds like:
specifics about the traffic pattern and peak-load profile the provider has supported — the shape of the surge and what it stressed first — not a generic "we work with a range of industries."
Why it matters: Availability under attack isn't entirely the provider's job. An integration that times out too aggressively, retries in a way that risks duplicate charges, or can't handle a slow-but-not-failed response gracefully can turn a well-mitigated attack on the provider's side into a broken checkout on yours. There's a subtler version of the same problem: mitigation adds latency, and that latency can trip the acquirer's timeout before it trips yours — leaving a transaction in an indeterminate state that turns into a reversal, a void, or manual reconciliation instead of a clean approval or decline. Ask the provider how it handles transactions caught in that gap, not just how fast its mitigation reacts.
What a good answer sounds like:
specific, written integration guidance — recommended timeout values, idempotent retry behaviour, and how to handle a delayed webhook — not "just call the API and it works." Ideally, it also includes guidance on transactions left in a latency-driven indeterminate state: automatic reconciliation, or a documented manual process.
Treat the ten questions as a DDoS payment availability checklist and score every provider against the same sheet. Vague answers — "enterprise-grade protection," "we take this very seriously," "our uptime is excellent" — are a red flag no matter how confident they sound, because they don't say what happens to your checkout specifically. Specific answers — a named SLA covering checkout and API availability, a plain description of the separation between the marketing site and the transactional contour, real approval-rate data from an incident — are the green flags.
| Step | What to do |
|---|---|
| 1. Ask the ten questions | Put all ten to the provider before you sign, not after an incident — a provider that takes availability seriously should be able to answer every one of them in plain language. |
| 2. Sort the answers into red and green flags | Vague reassurance — "enterprise-grade protection," "we take this very seriously" — is a red flag. A named SLA, a plain description of separation, and real approval-rate data are the green flags. |
| 3. Ask for the paperwork, not the assurance | A document you can read beats a verbal promise — an SLA naming checkout and API availability specifically, plus a status page and a post-incident writeup practice. |
| 4. Close the loop before you sign | These are contract-level questions, not a marketing claim — get the specific answers committed before you sign, not after the first incident. |
One principle is worth stating plainly — it's public, marketing-level architecture, not anything proprietary: a multi-acquirer setup with automatic cascading keeps payments flowing when a single path degrades, whatever the cause — a declined card, a bank outage, or an attack on one route. That's why orchestration and multi-acquirer routing come up so often on this checklist.
Ask us these 10 questions — we would rather answer them before you sign than after an incident.
Yes. An attack aimed at a hosted payment page, a checkout API, or a webhook/callback endpoint can disrupt transactions and payment notifications without ever taking the main website offline. The website staying up is not proof that payments are unaffected.
A Layer 7 DDoS attack mimics real user behaviour — page requests, form submissions, API calls — rather than simply flooding bandwidth. Against a checkout flow, that can look like a burst of fake purchase attempts that overwhelm the payment page or API, which makes it harder to filter than a purely volumetric attack because it resembles a genuine traffic spike.
It depends on how the SLA is written. Some SLAs cover general platform uptime and may not directly address a checkout that is degraded but not fully down during an attack. Ask specifically whether the SLA names checkout and API availability, and whether attack-driven degradation counts toward it — a serious provider should have a documented answer, not a verbal one.
Sensible timeouts, retry logic that will not duplicate a charge, and integration handling for delayed webhooks are the main items. None of these are exotic — they are standard resilient-integration practice — but they matter more during an attack, when a payment provider's mitigation can add latency that a poorly configured integration will misread as a failure. That same latency can also trip the acquirer's timeout before yours, leaving a transaction in an indeterminate state that needs reconciliation rather than a simple retry.
Thank you for reaching us. Your request has been sent successfully. We will get back to you as soon as possible.
Message was not sent
