Imagine you find a bunch of keys on the street. You don’t know which doors they open, or if they open anything at all. What do you do? You probably walk down the street trying each key on small, low-risk doors first — a shed, a mailbox, a gate — before you dare try them on someone’s front door. If a key works on the shed, you now know it’s a “real” key, and you can use it somewhere more valuable.

This is exactly what a criminal does with a stolen credit card number. They don’t know if the card is still active, has money on it, or has already been cancelled. So before using it for a big purchase, they try it on something small and cheap — a one-dollar digital sticker pack, a small donation, a $0.50 subscription — just to see if the “key” (the card) still opens the “door” (a successful charge). This behavior is called card testing, and detecting it in real time, at scale, without blocking real customers, is one of the most important and most interesting problems in payments engineering.

Card testing is not a new idea. It has existed for as long as card payments have existed, but it exploded in scale after two things happened in the industry:

• E-commerce automation. Once checkout could be triggered through simple HTTP requests instead of a person swiping a physical card, attackers could write scripts (called “checkers” or “carding bots”) that submit thousands of card numbers per minute against any website with a payment form.
• Massive card number leaks. Large-scale data breaches over the last two decades have put hundreds of millions of raw or partially masked card numbers into criminal marketplaces. A leaked batch of card numbers is nearly worthless until someone verifies which of those numbers are still “alive.” Card testing is that verification step.

Payment networks like Visa and Mastercard, along with large merchants such as Amazon, Shopify-powered stores, and airlines, have all built dedicated fraud engineering teams and real-time decisioning systems specifically to fight this pattern. Understanding how to design such a system — the topic of this tutorial — is now a standard, high-value system design interview question for e-commerce, fintech, and payments companies.

What Exactly Is Card Testing?

Card testing (sometimes called “carding” when it precedes a bigger fraud, or “BIN attacks” when many cards share the same issuer prefix) is the practice of submitting a large number of stolen or guessed card numbers through small transactions to discover which numbers are valid and currently usable. The attacker’s goal is never really to buy the cheap item being purchased. The transaction itself is just a probe.

Why Does This Matter to a Business?

Why Is This a Hard System Design Problem?

At first glance this sounds simple: “just block anyone submitting too many card numbers.” But building this properly is hard for several real reasons:

• It has to happen in real time. The decision to approve or decline must be made in well under a second, inside the checkout flow, without adding noticeable latency for legitimate shoppers.
• Attackers rotate everything. A smart attacker rotates IP addresses (using proxy networks), device fingerprints, email addresses, and even the exact card numbers used, so no single signal is reliable on its own.
• You cannot block too aggressively. Being overly strict blocks real customers — for example, a family sharing a home Wi-Fi network placing several genuine orders in a short time could look like an “IP based” attack if the rules are too blunt.
• Scale. A large e-commerce platform processes thousands of transactions per second at peak (like a flash sale), and the fraud system must not become the bottleneck.
• The signal keeps evolving. Fraud patterns change constantly as attackers adapt to whatever rules you deploy, so the system has to support fast rule updates and continuous model retraining, not just a fixed set of “if this then that” checks written once.

Before we design anything, let’s build up the vocabulary and building blocks, explained simply, with everyday analogies.

3.1 BIN (Bank Identification Number)

The first six to eight digits of a card number identify which bank (issuer) issued the card, and often which card network (Visa, Mastercard) and card type (debit, credit, prepaid) it is. Attackers often buy stolen cards in “BIN batches” — hundreds of cards that all start with the same six digits, because they were stolen from the same breach.

3.2 Velocity

Velocity means “how many events of a certain kind happened in a certain time window.” For example: “how many transaction attempts came from this IP address in the last 60 seconds” or “how many different cards were tried against this same shipping address in the last hour.” Velocity checks are the single most important tool against card testing because testing, by definition, involves doing something unusually fast and repeatedly.

3.3 Device Fingerprinting

A device fingerprint is a semi-unique identifier built by combining many small signals from the browser or app: screen resolution, installed fonts, timezone, browser plugins, canvas rendering quirks, and more. Even without cookies, two different sessions from the same physical device tend to produce a very similar fingerprint, which helps catch an attacker who is rotating IP addresses but reusing the same laptop or bot farm machine.

3.4 Card Testing versus Card-Not-Present Fraud (general)

Card testing is a specific sub-type of Card-Not-Present (CNP) fraud — fraud that happens in online or phone transactions where the physical card is never swiped or dipped. Not all CNP fraud is card testing (someone directly buying a laptop with a stolen card is CNP fraud but not testing), but almost all card testing is a precursor step to a bigger CNP fraud attempt elsewhere.

3.5 Authorization versus Capture

A key trick used to fight card testing cheaply is understanding the two-step nature of card payments:

• Authorization: The bank confirms the card is valid and has sufficient funds or credit, and places a temporary hold. No money moves yet.
• Capture: The merchant actually claims the funds, usually when the order ships.

Many mature systems avoid ever “capturing” money for suspicious low-value orders, and some avoid sending a full authorization at all for the riskiest score bands, instead using a “zero-dollar” or “one-dollar” account verification request supported by many card networks specifically for this purpose, which is cheaper and less disruptive to the card issuer than a full authorization attempt.

3.6 Rules Engine versus Machine Learning Scoring

Nearly every production fraud system uses both together, not one or the other. This is a very important point to make in an interview.

4.1 Functional Requirements

• Evaluate every checkout/payment attempt and return an Approve, Decline, or Challenge (for example, ask for a CAPTCHA or 3-D Secure step-up) decision.
• Track velocity of transaction attempts across multiple dimensions: card number hash, IP address, device fingerprint, billing address, email domain, and BIN.
• Support configurable, hot-reloadable rules that fraud analysts can change without a code deployment.
• Score every transaction with a machine learning model in real time.
• Automatically block a card, IP, or device once it is confirmed as part of a testing pattern.
• Allow human fraud analysts to review flagged cases and override decisions.
• Feed confirmed fraud patterns back into the model training pipeline.
• Provide an audit trail of every decision and the reasons behind it.

4.2 Non-Functional Requirements

4.3 Scale Estimation (Back of the Envelope)

Let’s do the kind of quick math an interviewer expects to see:

Assume a large e-commerce platform:
- 50 million checkout attempts per day (average)
- Peak traffic is roughly 8x average during flash sales
- Average day: 50,000,000 / 86,400 seconds ~= 580 transactions per second (TPS)
- Peak: 580 x 8 ~= 4,600 TPS sustained, with short bursts up to 10,000+ TPS

During an active card testing attack:
- A single botnet can generate 50 to 200 requests per second against one merchant
- With multiple concurrent attacker campaigns, this can add another 500 to 2,000 TPS
  of pure "noise" traffic on top of legitimate load

Storage estimation for velocity counters:
- Each active card/IP/device key needs a small counter record (~200 bytes)
- With 10 million unique keys active in any given hour window,
  that's 10,000,000 x 200 bytes ~= 2 GB of hot data in the cache layer
  (easily fits in a modern Redis cluster's memory)

Event stream volume:
- Each transaction emits ~2 KB of event data (features + metadata)
- At 5,000 TPS average: 5,000 x 2 KB = 10 MB/sec ~= 864 GB/day into Kafka

Now let’s put the whole system together. The diagram below shows every major component, from the moment a customer clicks “Pay Now” to the moment a fraud analyst reviews a flagged case. Notice how it is organized into clear layers: edge and gateway, core checkout services, the fraud detection platform itself, an asynchronous event pipeline, and the data layer.

Component Responsibilities

5.1 Edge and Gateway Layer

• CDN / Edge Cache: Serves static checkout page assets close to the user and can absorb some volumetric attack traffic before it even reaches your infrastructure.
• WAF (Web Application Firewall): Blocks known malicious request signatures, SQL injection attempts, and can apply coarse IP reputation blocking (known Tor exit nodes, known botnet IP ranges) before requests reach the application layer.
• Load Balancer: Distributes incoming traffic across many API Gateway instances, performs health checks, and can itself apply basic connection-level rate limiting.
• API Gateway: Handles authentication, request validation, coarse-grained rate limiting per API key or session, request routing to the correct backend service, and TLS termination.

5.2 Core Checkout and Payment Services

• Checkout Service: Owns the shopping cart, pricing, and order creation logic.
• Payment Orchestrator Service: Coordinates the payment flow: calls the Fraud Decision Gateway first, and only if approved, forwards the authorization request to the actual Payment Service Provider (PSP) / card network.

5.3 Card Testing Fraud Detection Platform (the core of this tutorial)

• Fraud Decision Gateway: The single synchronous entry point the Payment Orchestrator calls. It fans out to the Rules Engine and ML Scoring Service in parallel, combines their outputs, and returns one final decision within the latency budget.
• Rules Engine: Evaluates deterministic, human-authored rules, most importantly velocity rules, using data from the Velocity Cache and Blocklist Service.
• Velocity Cache: A low-latency, in-memory store (typically Redis) holding sliding-window counters for every dimension being tracked (per card, per IP, per device, per BIN, per shipping address).
• ML Scoring Service: Loads a trained model and produces a real-time risk probability for each transaction, using features pulled from the Feature Store.
• Feature Store: Serves pre-computed features (like “average order value for this customer over 90 days” or “number of distinct cards seen on this device in 30 days”) with low latency for online scoring, while also being consistent with the features used at training time.
• Device Fingerprint Service: Generates and matches device fingerprints from client-side signals.
• IP and BIN Blocklist Service: A fast-lookup service (often backed by the same Redis cluster or a dedicated key-value store) of known-bad IPs, IP ranges, device fingerprints, and BIN ranges.

5.4 Async Event Pipeline

• Event Stream (Kafka): Every transaction outcome is published here so downstream systems can consume it without slowing down the synchronous checkout path.
• Stream Processor (Flink or similar): Computes rolling aggregations (velocity counts, unique card counts per device, and so on) and writes them back into the Velocity Cache and Feature Store, and into the Analytics Warehouse for longer-term analysis.
• Case Management Service: Groups related flagged transactions into a single “case” for a human fraud analyst to review, rather than showing them thousands of disconnected alerts.
• Notification Service: Alerts fraud analysts, on-call engineers, or even automatically notifies the card network of confirmed BIN attack patterns.

5.5 Data Layer

• Transaction Database: The system of record for orders and payment attempts, typically a sharded relational database like Postgres.
• Analytics Warehouse: An OLAP store (like Snowflake, BigQuery, or ClickHouse) for historical fraud analysis, dashboards, and generating training data.
• Model Registry: Stores trained model versions, their metadata, and enables safe rollback if a new model performs worse in production.

6.1 The Synchronous Decision Path, Step by Step

The diagram below shows exactly what happens between the moment a customer submits their card details and the moment they see “Payment Successful” or “Payment Declined.”

6.2 Combining Rules and ML Score into One Decision

A common and effective pattern is a weighted decision matrix. The Rules Engine can produce a hard “must decline” verdict that overrides everything (for example, “this exact card was already declined 10 times in the last 5 minutes”), while for everything else, the ML score is bucketed into risk bands that map to an action:

6.3 Java Example: The Core Decision Combiner

Below is a simplified but realistic version of the decision-combining logic inside the Fraud Decision Gateway.

public class FraudDecisionCombiner {

    private static final double DECLINE_THRESHOLD = 0.7;
    private static final double CHALLENGE_THRESHOLD = 0.3;

    public FraudDecision decide(RulesVerdict rulesVerdict, double mlScore) {

        // Hard blocks always win, regardless of ML score
        if (rulesVerdict.isHardBlock()) {
            return FraudDecision.decline(rulesVerdict.getReasonCode());
        }

        if (mlScore >= DECLINE_THRESHOLD) {
            return FraudDecision.decline("ML_HIGH_RISK_SCORE");
        }

        if (mlScore >= CHALLENGE_THRESHOLD || rulesVerdict.isSoftFlag()) {
            return FraudDecision.challenge("STEP_UP_AUTH_REQUIRED");
        }

        return FraudDecision.approve();
    }
}

6.4 Java Example: Sliding Window Velocity Check with Redis

This uses a Redis sorted set as a sliding time window. Each event is added with its timestamp as the score, old entries are trimmed, and the remaining count tells us the velocity.

public class VelocityChecker {

    private final RedisTemplate<String, String> redis;
    private static final long WINDOW_SECONDS = 60;
    private static final int MAX_ATTEMPTS_PER_CARD_PER_MINUTE = 5;

    public VelocityChecker(RedisTemplate<String, String> redis) {
        this.redis = redis;
    }

    public boolean isCardTestingVelocity(String cardHash) {
        String key = "velocity:card:" + cardHash;
        long now = System.currentTimeMillis();
        long windowStart = now - (WINDOW_SECONDS * 1000);

        // Remove entries older than the window
        redis.opsForZSet().removeRangeByScore(key, 0, windowStart);

        // Add the current attempt
        redis.opsForZSet().add(key, String.valueOf(now), now);

        // Set expiry so unused keys are cleaned up automatically
        redis.expire(key, java.time.Duration.ofSeconds(WINDOW_SECONDS * 2));

        // Count attempts within the window
        Long count = redis.opsForZSet().zCard(key);

        return count != null && count > MAX_ATTEMPTS_PER_CARD_PER_MINUTE;
    }
}

A card testing incident isn’t just one transaction — it’s a pattern that emerges and evolves over time. The state diagram below shows the full lifecycle from the very first suspicious signal to final resolution.

7.1 Multi-Dimensional Velocity Checking

A single card testing burst rarely gets caught by just one signal. The diagram below shows how one incoming transaction is checked against several parallel time windows simultaneously — this is what makes the system resistant to an attacker rotating only some of their signals.

7.2 Why Multiple Windows and Dimensions Matter

Consider an attacker using a residential proxy network that gives them a fresh IP address for every single request. An IP-only velocity check would never catch them, because every request looks like it’s coming from a different, brand-new IP address that has never been seen before. But that same attacker is very likely still using the same device (or same small farm of automation scripts), and is almost certainly working through a batch of stolen cards that share the same BIN, because that’s how stolen card data is usually sold. By checking velocity across device fingerprint and BIN range in addition to IP, the system catches what any single dimension alone would miss.

8.1 Key Trade-off: Precision versus Recall

This is one of the most important trade-offs to discuss explicitly in an interview. Precision asks: “Of all the transactions we blocked, how many were actually fraud?” Recall asks: “Of all the actual fraud attempts, how many did we catch?” Tightening thresholds to catch more fraud (higher recall) almost always increases false positives (lower precision) — you end up declining more real customers. The right balance depends entirely on the business: a luxury goods retailer with high average order values may accept more false positives to avoid large individual losses, while a low-margin, high-volume marketplace may tolerate slightly more fraud leakage to protect conversion rate.

8.2 Key Trade-off: Synchronous Depth versus Latency Budget

The more checks you run synchronously before responding to the customer, the more accurate the decision can be, but the slower checkout becomes. Most production systems solve this by doing the cheapest, highest-signal checks (Redis velocity lookups, blocklist checks) synchronously, and reserving expensive checks (calling a third-party fraud data vendor, running a heavier secondary model) only for transactions that land in the ambiguous “medium risk” band.

9.1 Where the Bottlenecks Are

9.2 Scaling the Fraud Decision Gateway Horizontally

The Fraud Decision Gateway should be stateless so it can scale horizontally behind the Load Balancer just like any other service — all state lives in Redis, the Feature Store, and the databases. This lets you add more instances during a detected attack spike without any coordination overhead between instances.

9.3 Caching Strategy

• Blocklist cache: Cache known-bad IPs, devices, and card hashes in a local in-memory cache (like Caffeine in Java) with a short TTL, refreshed from Redis, to avoid a network round trip for the most common, high-confidence rejections.
• Feature cache: Cache slowly-changing features (like “account age in days”) more aggressively than fast-changing features (like “transactions in the last minute”).
• Negative caching: Even caching “this card was NOT found on any blocklist” for a very short time (a few seconds) can meaningfully cut load during a sustained attack burst.

9.4 Algorithms, Data Structures, and Distributed Systems Concepts

A few core computer science ideas show up repeatedly in a system like this, and being able to name and apply them is exactly what separates a surface-level answer from a strong one in an interview.

Sliding Window Algorithms

We already saw the sorted-set based sliding window in Section 6.4. There are three common variants, each with different trade-offs:

Probabilistic Data Structures for Extreme Scale

When tracking “have I seen this exact card hash before across the last 24 hours” at very high volume, storing every single value exactly can become expensive. A Bloom filter is a space-efficient probabilistic data structure that can answer “definitely not seen” with certainty and “possibly seen” with a small, tunable false-positive rate, using a fraction of the memory an exact set would need. Many large-scale fraud platforms use a Bloom filter as a fast first-pass check before falling back to an exact lookup only when the Bloom filter says “possibly seen.”

CAP Theorem Applied to This System

The CAP theorem says a distributed data store can only guarantee two of three properties during a network partition: Consistency, Availability, and Partition tolerance. This system makes different choices for different data:

• Velocity Cache (Redis): Favors Availability and Partition tolerance over strict Consistency. It’s acceptable if a velocity count is a few milliseconds stale — better to make a fast decision on slightly stale data than to block checkout waiting for perfect consistency.
• Transaction Database (Postgres): Favors Consistency — you cannot have two different services disagreeing about whether an order was actually paid for, so this uses strongly consistent, transactional writes even at some cost to availability during a partition.

This mixed approach, using different consistency models for different pieces of data based on their actual business requirements, is a hallmark of mature distributed system design, and calling it out explicitly is a strong signal in an interview.

Replication and Partitioning

Redis Cluster shards the velocity keyspace across many nodes (partitioning) using hash slots, so no single node needs to hold every key, and each shard is replicated to at least one replica node so a single node failure doesn’t lose data or availability. Kafka similarly partitions each topic (commonly by card hash or merchant ID) so consumer processing scales horizontally, with each partition replicated across brokers for durability.

Consensus and Failure Recovery

Redis Cluster and Kafka both rely on consensus-like mechanisms to agree on cluster state during failures — Redis Sentinel (or Cluster’s built-in gossip protocol) elects a new primary from the surviving replicas when a primary node fails, and Kafka uses a controller (backed by a Raft-based metadata quorum in modern versions) to manage partition leader election. Understanding that these systems automatically detect failure and re-elect leadership, without an engineer manually intervening, is important context for explaining why the platform can stay available through routine node failures.

Concurrency in the Decision Path

Because the Fraud Decision Gateway calls the Rules Engine and ML Scoring Service, ideally these calls happen concurrently rather than one after another, since they don’t depend on each other’s output. Below is a simplified Java example using structured concurrency to fan out both calls in parallel and combine the results, keeping total latency closer to the slower of the two calls rather than the sum of both.

public class ParallelFraudEvaluator {

    private final RulesEngineClient rulesClient;
    private final MlScoringClient mlClient;
    private final ExecutorService executor;

    public FraudDecision evaluate(TransactionContext ctx) throws Exception {
        Future<RulesVerdict> rulesFuture =
                executor.submit(() -> rulesClient.evaluate(ctx));
        Future<Double> mlScoreFuture =
                executor.submit(() -> mlClient.score(ctx));

        // Enforce a strict timeout so one slow dependency can't blow the whole budget
        RulesVerdict rulesVerdict = rulesFuture.get(80, TimeUnit.MILLISECONDS);
        double mlScore = mlScoreFuture.get(80, TimeUnit.MILLISECONDS);

        return new FraudDecisionCombiner().decide(rulesVerdict, mlScore);
    }
}

Notice the explicit per-call timeout. Without it, a single slow downstream dependency could silently consume the entire latency budget for the whole request, or worse, hang indefinitely and exhaust the thread pool under load — this is exactly what the Circuit Breaker and Bulkhead patterns from Section 16 are designed to prevent.

10.1 Redundancy at Every Layer

Referring back to the deployment diagram in Section 13, every stateful component (Redis, Kafka, Postgres) is deployed across multiple availability zones with automatic failover, and the entire fraud platform is deployed across at least two regions, with the secondary region kept warm and ready to take traffic during a regional outage.

10.2 Graceful Degradation

A resilient design defines exactly what happens as each dependency degrades, rather than treating “everything up” as the only supported state:

10.3 Idempotency and Retries

Because network calls can fail and be retried, every fraud decision request must carry an idempotency key (typically the order or payment attempt ID) so that a retried request doesn’t get double-counted in velocity counters or trigger two different decisions for the same attempt.

11.1 Protecting Card Data Itself

The fraud system should never store raw card numbers. Instead, it works with a tokenized reference (provided by the PSP) and a one-way, salted hash of the card number for internal matching and velocity tracking purposes. This keeps the fraud platform outside the strictest scope of PCI DSS (Payment Card Industry Data Security Standard) requirements where possible, while still letting it recognize “have I seen this exact card before.”

11.2 Protecting the Fraud System Itself from Attack

Ironically, the fraud detection system is itself a high-value target. If an attacker can learn exactly what triggers a decline, they can tune their attack to stay just under the thresholds. Key defenses:

• Never expose specific decline reasons to the client. The checkout UI should show a generic “Payment could not be completed” message, never “Declined due to velocity rule VEL-004.”
• Rate limit and monitor access to the fraud analyst dashboard and rules configuration tools with strong authentication (mandatory multi-factor authentication) and full audit logging of every rule change.
• Add randomized “noise” or held-back rules that are not always applied the same way, making it harder for an attacker doing systematic probing to reverse-engineer your exact thresholds.
• Rotate and monitor API keys used by any client-side device fingerprinting SDK to prevent them from being reverse engineered and spoofed.

11.3 Defense in Depth Alongside the Fraud Platform

• CAPTCHA / bot detection at the checkout form level to raise the cost of fully automated scripted attacks.
• 3-D Secure (3DS) step-up authentication shifts liability to the card issuer for authenticated transactions and adds a strong signal that a real cardholder, not a bot, completed the flow.
• TLS everywhere and strict input validation at the API Gateway to prevent injection attacks against the checkout and fraud endpoints themselves.
• Least-privilege access between microservices, using mutual TLS or a service mesh, so that a compromise of one low-privilege service cannot be used to directly query the Velocity Cache or Transaction Database.

12.1 Key Metrics to Track

12.2 Logging and Traceability

Every fraud decision should be logged with a structured record including: a correlation/trace ID shared across all services touched by that transaction, the exact rules that fired, the raw ML score and model version used, and the final decision. This is essential not just for debugging, but for responding to chargeback disputes and regulatory inquiries months later.

12.3 Distributed Tracing

Because a single decision fans out across the Rules Engine, Velocity Cache, ML Scoring Service, and Feature Store, distributed tracing (using something like OpenTelemetry with a trace ID propagated through every hop) is essential for diagnosing which specific call is adding latency when the p99 starts to creep up.

12.4 Alerting Philosophy

• Alert on rate-of-change, not just absolute thresholds — a decline rate suddenly doubling is more actionable than a fixed “decline rate above 5 percent” alert that might be normal for one merchant category.
• Separate alerts for system health (latency, errors, availability) from alerts for fraud pattern anomalies (sudden BIN attack detected) — these go to different teams (engineering on-call versus fraud analysts) with different urgency.
• Build an automatic “attack detected” dashboard that surfaces the top cards, IPs, devices, and BINs by attempt count in the last 5 minutes, so analysts can act within the attack window, not after it’s over.

The deployment diagram below shows a realistic multi-region, multi-availability-zone setup for this platform.

13.1 Containers and Orchestration

Each service (Fraud Decision Gateway, Rules Engine, ML Scoring Service, Case Management Service) is packaged as a container and run on Kubernetes, with Horizontal Pod Autoscaling driven by request rate and CPU/memory utilization. This allows the platform to absorb both predictable peak-hour traffic and unpredictable attack-driven spikes.

13.2 Blue-Green and Canary Deployments

Because a bug in the fraud decision path can either let fraud through or block real customers, deployments to the Fraud Decision Gateway and Rules Engine should always go through canary releases: route a small percentage of traffic (say 5 percent) to the new version, closely compare decline rates and latency against the stable version, and only proceed to full rollout once the metrics match expectations.

13.3 Infrastructure as Code

All infrastructure (Kubernetes manifests, Redis cluster configuration, Kafka topic definitions) should be defined declaratively using tools like Terraform, so that spinning up the secondary region’s infrastructure, or recovering from a full region loss, is a repeatable, tested, automated process rather than manual work under pressure.

13.4 Cost Optimization

• Use cheaper, rule-only evaluation for very low-value transactions, reserving full ML scoring for transactions above a configurable value threshold.
• Tier storage: keep only the most recent, hot velocity data in Redis; move historical transaction data to cheaper storage in the Analytics Warehouse after a retention window.
• Right-size ML model complexity against the real latency and cost budget — a smaller, well-tuned model that runs everywhere often beats a marginally more accurate model that’s too expensive to run on every transaction.

14.1 Choosing the Right Store for Each Job

14.2 Sharding the Transaction Database

At the scale estimated in Section 4.3, a single Postgres instance cannot hold all transaction data. Sharding by a hash of merchant ID or customer ID is a common approach, keeping all of one merchant’s or customer’s transactions on the same shard so most queries (like “get this customer’s order history”) don’t need to fan out across shards.

14.3 Load Balancing Strategy

At the edge, a Layer 7 load balancer (such as an AWS Application Load Balancer or Nginx) distributes traffic using least-outstanding-requests or round-robin algorithms across API Gateway instances. Internally, service-to-service calls (for example, Fraud Decision Gateway calling the ML Scoring Service) typically use client-side load balancing integrated with service discovery (through a service mesh like Istio or Linkerd), which avoids adding an extra network hop through a central load balancer for every internal call.

14.4 Cache Invalidation for the Blocklist

When a fraud analyst manually blocks a card, IP, or device from the dashboard, that update needs to propagate to every Fraud Decision Gateway instance quickly. A common pattern is publishing a small invalidation event to a pub/sub channel (Redis Pub/Sub or a Kafka topic) that every instance subscribes to, so local in-memory caches are invalidated within milliseconds instead of waiting for a TTL to expire.

15.1 The Core Fraud Decision API

The Payment Orchestrator calls a single, well-defined synchronous endpoint. Keeping this contract simple and stable matters, because many internal teams end up depending on it.

POST /v1/fraud/evaluate
Content-Type: application/json
Idempotency-Key: order_8f21c9e0

{
  "transactionId": "order_8f21c9e0",
  "cardHash": "sha256:9f86d081...",
  "binRange": "411111",
  "amount": 499,
  "currency": "USD",
  "ipAddress": "203.0.113.45",
  "deviceFingerprint": "fp_7a1c...",
  "billingCountry": "US",
  "email": "buyer@example.com",
  "customerId": "cust_10293"
}

Response 200 OK:
{
  "transactionId": "order_8f21c9e0",
  "decision": "CHALLENGE",
  "riskScore": 0.42,
  "reasonCodes": ["VEL_IP_SOFT", "NEW_DEVICE"],
  "modelVersion": "fraud-model-v14",
  "decisionLatencyMs": 38
}

15.2 Internal Service Boundaries

Each core fraud component is its own microservice with a narrow, well-defined responsibility, which is what lets different teams (rules/analysts, ML/data science, platform engineering) own and deploy their piece independently:

• Rules Engine service: owns rule evaluation logic and exposes a simple “evaluate rules for this context” API; rule definitions themselves are stored in a versioned configuration store, not hardcoded, so analysts can update them through a UI without a code deploy.
• ML Scoring service: owns model loading, feature retrieval orchestration, and inference; exposes a “score this transaction” API and hides all model-specific complexity from callers.
• Case Management service: owns the lifecycle of flagged cases and exposes APIs for the analyst dashboard to list, claim, and resolve cases.

15.3 Synchronous versus Asynchronous Communication

The Fraud Decision Gateway to Rules Engine and ML Scoring Service calls are synchronous (usually gRPC for low latency and strong typing), because checkout is waiting on the answer. Everything downstream of the decision — analytics, case creation, model feedback — is asynchronous, published as events to Kafka, because none of it needs to block the customer’s checkout experience.

16.1 Useful Design Patterns

16.2 Anti-Patterns to Avoid

17.1 Best Practices

17.2 Common Mistakes

Q: Can card testing be stopped completely?

No system stops it completely — the goal is to raise the cost and lower the success rate of an attack enough that it’s no longer profitable for the attacker, while keeping the experience smooth for genuine customers. Think of it like a lock on a door: it doesn’t make a break-in impossible, it makes it slow and risky enough that most attackers move to an easier target.

Q: Why not just require CAPTCHA on every single checkout?

Because it adds friction for every legitimate customer, hurting conversion rate, and modern bots can often solve simple CAPTCHAs anyway. It’s better used selectively — as a “challenge” step only for medium-risk transactions identified by the rules and ML layers, not as a blanket requirement.

Q: How is this different from general payment fraud detection?

Card testing is specifically about detecting the reconnaissance phase before a bigger fraud attempt, which means the signals that matter most are different — very low transaction amounts, high velocity, and patterns across many cards sharing a BIN, rather than signals more relevant to a single large fraudulent purchase, like shipping-to-billing address mismatches on a high-value item.

Q: Should small merchants build this themselves?

Usually not from scratch. Most small and mid-sized merchants are better served by the fraud tools built into their PSP (like Stripe Radar or Adyen’s RevenueProtect), which benefit from data across many merchants. Building a custom system like the one in this tutorial typically makes sense once a business reaches significant transaction volume and has fraud patterns specific enough that off-the-shelf tools underperform.

Q: What happens to a “test” transaction that gets approved?

If a small test transaction is approved before the pattern is detected, most systems will still flag the surrounding pattern once enough attempts accumulate, block further attempts, and often automatically refund or void the small approved test charge once a human analyst confirms it was part of a testing pattern.

Q: How do you avoid punishing legitimate customers on shared networks, like a university or corporate Wi-Fi?

This is exactly why the system never relies on IP address alone (Section 2 and 7.2). Combining IP velocity with device fingerprint, card diversity, and behavioral signals means that many genuine customers sharing one IP address, each using a different device and a different single card, simply doesn’t match the pattern of one attacker cycling through many stolen cards. Rule thresholds can also be tuned per network type, treating known large corporate or campus IP ranges with a higher tolerance than an unrecognized residential proxy IP.

Q: How long should a card, device, or IP stay blocked?

This varies by confidence level. A soft, automated block based purely on velocity might expire after a few hours, since it could have been triggered by unusual but legitimate behavior. A hard block confirmed by a human analyst as fraud is typically kept much longer, often permanently for the specific card hash, since a confirmed stolen card is not going to become legitimate again. Many systems use a graduated approach: automated blocks are temporary and self-expiring, while analyst-confirmed blocks require an explicit analyst action to remove.

Q: Does this system need to comply with any specific regulations?

Yes. Depending on the region, this touches PCI DSS (for anything related to card data handling), and in some jurisdictions, regulations around automated decision-making that affect consumers may require the ability to explain or contest a decision, which is one more reason the audit trail and reason-code logging described in Section 12.2 is not optional — it’s often a compliance requirement, not just an engineering nicety.

Designing a card testing fraud detection system is a genuinely rich system design problem because it forces you to reason about real-time low-latency decisioning, large-scale stream processing, machine learning in production, human-in-the-loop workflows, and hard business trade-offs, all at once. It’s rarely just “the correct architecture” that interviewers are looking for — it’s whether you can reason clearly about trade-offs and defend your choices.

A strong system design answer doesn’t just present one architecture — it briefly acknowledges other reasonable approaches and explains why the chosen design fits this problem best.