Compendium

Walkthrough: Design a Card-Acquiring + Processing Platform (PCI-DSS, ISO 8583/20022, Auth-Clear-Settle, Fraud + Ledger)

30 min read

Walkthrough: Design a Card-Acquiring + Processing Platform (PCI-DSS, ISO 8583/20022, Auth-Clear-Settle, Fraud + Ledger)

This walkthrough designs a mid-scale card-acquiring and processing platform end-to-end: target is a Level-1 PCI-DSS acquirer-processor that authorizes, clears, and settles card-present and card-not-present (CNP) transactions for ~50,000 merchants doing 1B annual transactions (40-90M for a greenfield processor; mature unit economics land at 8-25 basis points net take rate on processed volume after interchange + assessments pass through.

Reference processors and recent events shaping the design: Stripe (Treasury + Issuing + Connect + Radar), Adyen (single-stack Tier-1 acquirer, AMS Euronext listed), Block / Square (Cash App + Square POS), Worldpay (FIS spin-off + GTCR/Worldline carve-out 2024), Fiserv Carat + Clover, Global Payments + TSYS, Marqeta (issuer-processor), Checkout.com, Rapyd, dLocal (LatAm acquirer), Nuvei, Shift4, Toast (vertical SaaS + integrated acquirer). Recent reference events: Visa-Plaid antitrust collapse (Jan 2021), Mastercard-Finicity (Nov 2020), CFPB Section 1033 final rule (Oct 2024), Stripe acquisition of Bridge stablecoin (Oct 2024 $1.1B), FedNow GA (Jul 2023), Pix Brazil scale demonstration (40B+ tx/yr by 2024), the BIN-attack waves on Stripe + Authorize.net (2023-2024), and the Synapse-Evolve collapse (Apr-May 2024) reshaping fintech BaaS underwriting.

1. Platform spec

ParameterTargetNotes
Annual transactions1.0B authorizations / yr (~32 TPS avg, ~600 TPS peak)Black Friday ~3× avg; Cyber Monday similar
Annual GPV$75-150BMix CP 35% / CNP 65% by count; CNP 70%+ by value
Merchants50,000 activeLong tail SMB + ~200 enterprise MIDs >$50M GPV each
GeographiesUS + EU + UK first; CA + AU + LatAm Y2-3Per-corridor processor agreements
Authorization p99<500 msIndustry standard; network adds 80-180 ms RTT
Authorization availability99.995% (~26 min/yr)Card-network requirement; lost-uptime SLA penalties
Settlement T+1 / T+2T+1 standard, T+0 for premium tierPer network rules + acquirer funding window
Chargeback rate<0.5% (Visa VAMP / Mastercard Excessive Chargeback Program)Above 1.5% = remediation; above 3% = portfolio shutdown
Fraud loss rate<8 bps on CNPNet of recoveries; SCA cuts EU CNP fraud ~60% post-deploy
PCI-DSS scopeCDE = ~120 hosts in 2 segregated VPCsTokenization shrinks scope dramatically
CompliancePCI-DSS v4.0 Level 1, SOC 2 Type II, ISO 27001, PSD2 RTS, Card-network Annual ROCPlus state money-transmitter licences for funds-flow tier
Build CAPEX$40-90M to Level-1 cert + production cutover24-36 mo from greenfield
Net take rate at scale8-25 bps after interchange pass-throughBelow Visa/MA assessments + interchange ~95% of gross MDR

2. The four-party model and where this platform sits

The classic four-party model maps cleanly to platform components — and the platform owns at least the acquirer-processor role, often spans gateway and issuer-processor as well.

   Cardholder  --(swipe/tap/CNP)-->  Merchant
                                       |
                                       v
                          [ Gateway ] -- tokenize + route
                                       |
                                       v
                          [ Acquirer-Processor ] -- this platform
                                       |
                          ISO 8583 over MPLS / leased line
                                       |
                                       v
                       [ Card Network ] -- Visa / Mastercard / Amex / Discover
                                       |
                                       v
                          [ Issuer-Processor ] -- e.g., FIS, Fiserv, TSYS, Marqeta
                                       |
                                       v
                                   [ Issuer Bank ]

The platform’s revenue surface is the Merchant Discount Rate (MDR) charged to merchants, typically 1.5-3.5% on CNP. Of that, interchange (paid to issuer) is 70-80%, network assessments (Visa Core + Mastercard Standards fees) are 10-15%, and what’s left is the acquirer + processor margin. At scale, the processor keeps 8-25 bps net.

The four flows the platform must operate:

  1. Authorization — real-time, response in <500 ms, holds funds on cardholder account
  2. Clearing — batched (typically nightly), confirms the final amount + currency for settlement
  3. Settlement — funds move issuer → network → acquirer → merchant, T+1 to T+2
  4. Dispute / chargeback — async, governed by network reason codes + lifecycle timers

See fintech-architecture-deep for the broader payments topology and _index for the financial-system foundation.

3. PCI-DSS scope and tokenization boundary

PCI-DSS v4.0 (effective Mar 2024, future-dated requirements effective Mar 2025) governs every system that stores, processes, or transmits cardholder data (CHD) or sensitive authentication data (SAD). The platform’s first architectural decision is where to draw the Cardholder Data Environment (CDE) boundary — every host in scope multiplies audit cost and operational burden.

3.1 The tokenization wedge

The fundamental move is to capture the Primary Account Number (PAN) at the edge — a tokenization vault — and replace it with an opaque token everywhere downstream. The merchant integration, the application services, the analytics warehouse, and most of the application surface never touch a real PAN.

   Merchant browser / POS
        |
        | (PAN, CVV, expiry over TLS 1.2+)
        v
   [ PCI-PROXY / VAULT ]  <-- the only system in CDE scope for PAN at rest
        |
        | Returns: token (format-preserving or random)
        v
   [ Application services ] -- handle token only
        |
        | At authorization time, vault detokenizes inside CDE
        v
   [ Network adapter / HSM ] -- encrypts PIN block, signs message, ISO 8583 out

Token formats:

  • Random tokens — opaque UUID-like strings; no relationship to PAN; preferred for new systems.
  • Format-preserving (FPE) — same shape as PAN (16 digits, valid Luhn) for legacy merchant systems that validate Luhn locally; uses NIST FF1/FF3-1 algorithms.
  • Network tokens — issued by Visa Token Service (VTS) + Mastercard MDES; replace PAN end-to-end including at the network. Reduce CNP fraud ~25% and improve auth approval rates 2-4 pp. Mandatory roadmap for major processors by 2026-2027.

3.2 CDE scoping

Hosts in CDE (PCI requires every one of these to comply with all 12 PCI domains):

  • Tokenization vault servers (the only place PAN-at-rest exists)
  • HSMs and HSM-adjacent control hosts (Thales Luna, Utimaco Atalla, AWS CloudHSM, Entrust nShield)
  • ISO 8583 + ISO 20022 network adapters and SAF (store-and-forward) queues
  • 3-D Secure ACS/DS connector hosts
  • Key management hosts and key-ceremony witness terminals
  • Logging + SIEM ingestion path for CDE log sources (encrypted in transit, segregated retention)

Out of CDE (the bulk of the platform):

  • Merchant onboarding + KYC services
  • Reporting, analytics, dashboarding (operate only on tokens + aggregates)
  • Application APIs receiving tokens from merchants via tokenizing proxy
  • Most of the data warehouse + ML/fraud feature store (only token-keyed features)

Target: ~120 hosts in CDE for the design above. Mature processors run CDEs in the 80-300 host range. Square’s published v4.0 ROC summaries (2023-2024) place CDE at <5% of total fleet.

See cryptography-fundamentals (key management + HSM model) and auth-authz (RBAC for CDE access).

4. ISO 8583 — the legacy lingua franca of card networks

Card-network messaging between acquirer-processor and network remains predominantly ISO 8583 — a 1987-vintage binary message format with fixed and variable-length data elements (DEs). Despite ISO 20022 migration on the wholesale + instant-payment side, every Visa Authorization Service (VAS), Mastercard MDS, and Amex GES integration still speaks 8583 dialects.

4.1 Message structure

    MTI (4 digits) | Bitmaps | Data Elements (DE 2-128, optionally DE 129-192)

    e.g., MTI 0100 = Authorization Request
          MTI 0110 = Authorization Response
          MTI 0200 = Financial Transaction Request
          MTI 0210 = Financial Transaction Response
          MTI 0400 = Reversal Request
          MTI 0420 = Reversal Advice
          MTI 0800 = Network Management (echo, key change, cutover)

Common DEs the platform parses + emits:

DEFieldPurpose
2PAN16-19 digit primary account number (tokenized outside CDE)
3Processing code6-digit code: transaction type + from-account + to-account
4Amount, transactionMinor units in transaction currency
7Transmission date+timeMMDDhhmmss UTC
11STANSystem trace audit number — unique per acquirer
14Expiry dateYYMM
22POS entry modeManual / swipe / contactless / chip / EMV fallback
32Acquiring inst IDAcquirer BIN
35Track 2 dataMag-stripe — increasingly absent post-EMV
37Retrieval reference12-char acquirer-assigned for retrieval
38Authorization code6-char approval code, issuer-assigned
39Response code2-char: 00=approved, 05=do not honor, 51=insufficient funds, 91=issuer unavailable
41Card acceptor terminal8-char POS device
42Card acceptor ID15-char MID
43Card acceptor name/loc40-char “merchant” descriptor — what shows on the statement
48Additional dataNetwork-specific TLV
49Transaction currencyISO 4217 numeric
52PIN dataEncrypted PIN block (DUKPT or 3DES)
55EMV TLVTag-length-value EMV chip data
90Original data elementsFor reversals, references original
95Replacement amountsPartial-auth approvals

4.2 Connectivity

  • Physical: leased MPLS, fiber, or Direct Connect / ExpressRoute into Visa VisaNet, Mastercard MIP, Amex GES, Discover. Dual diverse links per region (East + West POPs) with BGP failover.
  • Session layer: SSL/TLS over TCP; persistent connections with periodic 0800 echoes (typically 30-60 s heartbeat).
  • Store-and-forward (SAF): if network is unreachable for >2-3 s, platform queues authorizations locally and replays. Stand-In Processing (STIP) — Visa and Mastercard auto-approve up to floor limits when issuer is unreachable.
  • Latency budget: 80-180 ms RTT to network; issuer adds 60-200 ms; total typical 250-450 ms; platform internal budget <100 ms p99.

4.3 ISO 20022 — the next generation

ISO 20022 (XML-based, richer data elements, ISO/IEC 20022) is the standard for:

  • SEPA Instant (EU) — pacs.008 credit transfers, mandatory 10-second settlement, SCT Inst 2024 updates
  • FedNow (US, GA Jul 2023) — pacs.008 + camt.054 + camt.029
  • RTP (US, TCH, since 2017) — pacs.008
  • Pix (Brazil) — local profile of ISO 20022
  • TARGET2 + Fedwire (wholesale wire) — full ISO 20022 migration by Mar 2025 (TARGET2) and Mar 2025 (Fedwire CHIPS), ECB-coordinated
  • Card networks (future) — Visa + Mastercard publishing ISO 20022 enrichment paths through 2025-2028; some VisaNet API + Mastercard Send already 20022

The platform owns an adapter layer mapping internal canonical message → ISO 8583 (card) or ISO 20022 (instant). Canonical message is a Protobuf or Avro schema versioned in a schema registry.

See fintech-architecture-deep for wire-format details and distributed-systems-fundamentals for the underlying ordering + replay guarantees.

5. Authorization, clearing, and settlement — the three flows

5.1 Authorization (real-time)

  Merchant
     |    POST /v1/charges { token: tok_..., amount: 5000, currency: "USD" }
     v
  Gateway
     |    -- idempotency key check, rate limit, schema validate
     v
  Auth orchestrator
     |    -- pull merchant config, risk rules, currency, fee schedule
     |    -- run synchronous fraud scoring (target <60 ms)
     |    -- detokenize via vault if PAN required by adapter (in CDE)
     v
  Network adapter
     |    -- build ISO 8583 0100 message, sign + send
     v
  Visa / Mastercard / Amex / Discover
     |
     v
  Issuer
     |    -- 0110 response: 39=00 approved, auth code in 38
     v
  Auth orchestrator
     |    -- record outcome, emit auth_recorded event, return to merchant
     v
  Merchant — total round-trip target <500 ms p99

Idempotency — every merchant POST carries an Idempotency-Key header (Stripe convention since 2015). Platform stores key → response for 24 h. Replay returns the same response. Critical because merchants will retry on timeout; without idempotency, double-charges proliferate. See distributed-systems-fundamentals for the exactly-once-at-the-effects discipline.

Stand-in / STIP — if issuer is unreachable, network can stand-in approve within issuer-configured floor limits (typically $25-100). Platform tracks STIP rate per BIN and alerts at >2%.

Partial authorization — issuer can approve a lower amount via DE 95; gateway returns this to merchant for split-tender or top-up. Standard for prepaid cards on fuel pumps.

5.2 Clearing (presentment)

Clearing finalizes the transaction. The acquirer batches authorized transactions (typically nightly) and submits 0220 financial advice messages or, in modern bilateral systems, settles via Visa Settlement Service (VSS) / Mastercard Clearing System (MCS) files.

   Auth -- holds funds  -->  Clearing -- finalizes amount + currency
                                  |
                                  v
                            Settlement -- funds movement

Key files:

  • Visa BASE II (legacy) — clearing file
  • Visa VSS-110, VSS-115, VSS-120 — settlement service reports (Visa Resolve Online)
  • Mastercard IPM (Integrated Product Messages) — clearing
  • Mastercard SGR (Settlement Detail Report) — settlement

Partial captures, tip adjustments, force-posts, reversals all happen at clearing — the auth-to-clearing delta must be within network tolerance (typically 0-20% for restaurants, 0% for most CP).

5.3 Settlement (funds movement)

Settlement is the actual movement of funds. T+1 standard for Visa/Mastercard; T+0 same-day premium tier (Same Day ACH + FedNow now make true T+0 feasible).

   Issuer Bank
      |  ACH / Fedwire / TARGET2
      v
   Settlement Bank (Card Network's)
      |
      v
   Acquirer's Settlement Account
      |
      v
   Merchant's Bank Account

Acquirer holds the merchant reserve — a percentage of GPV held back to cover chargebacks + refunds (typically 0-10% depending on risk). For high-risk MCCs (travel, ticketing, digital goods), reserves can be 5-25%.

Cross-currency settlement: dynamic currency conversion (DCC) and multi-currency pricing (MCP) handled at clearing via Visa Currency Conversion or Mastercard Currency Conversion service; FX margin is a revenue line (50-300 bps typical).

See fintech-architecture-deep and accounting-foundations for the journal-entry side.

6. 3-D Secure 2 and Strong Customer Authentication (SCA)

3-D Secure (3DS) is the protocol that authenticates the cardholder out-of-band during a CNP transaction. The platform integrates with 3DS 2.x (2.1, 2.2, 2.3) — the modern frictionless version. 3DS 1 is end-of-life as of Oct 2022.

6.1 The three domains

   Acquirer Domain                Interop Domain              Issuer Domain
   (Merchant)                     (Card Network)              (Issuer Bank)
   3DS Server (3DSS) <----------> Directory Server (DS) <---> Access Control Server (ACS)
  • 3DS Server (3DSS) — platform owns this (or licenses from a vendor like Cardinal Commerce / Visa, Netcetera, GPayments, Modirum, Mastercard Identity Check). Handles version discovery, message orchestration, browser fingerprint device data.
  • Directory Server (DS) — operated by the network (Visa 3-D Secure DS, Mastercard Identity Check DS). Routes ARES/RREQ to the correct ACS.
  • Access Control Server (ACS) — operated by issuer. Decides frictionless (no challenge) or challenge (OTP, biometric, app push). Returns CAVV (Cardholder Authentication Verification Value) → liability shift to issuer on fraud.

6.2 SCA under PSD2

In the EU + UK, Strong Customer Authentication (SCA) is mandatory for most CNP transactions per PSD2 Regulatory Technical Standards (RTS, EBA, Sep 2019, enforced fully Mar 2022). Two of three factors required:

  • Knowledge — password, PIN
  • Possession — phone, hardware token
  • Inherence — biometric

Exemptions the platform must implement to avoid challenge fatigue:

  • Low-value transactions (LVT) — under €30 (5 consecutive or €100 cumulative since last SCA)
  • Transaction Risk Analysis (TRA) — acquirer + issuer fraud rates below reference thresholds (0.13% / 0.06% / 0.01% for €100/€250/€500 bands)
  • Trusted Beneficiary (TBL) — issuer-managed whitelist
  • Merchant-Initiated Transactions (MIT) — subscriptions, recurring; initial MIT requires SCA
  • Corporate cards — out of scope where dedicated secure protocols apply

PSD3 / PSR1 (proposed 2023, expected late 2025 / 2026 in force) refines exemptions, mandates clearer liability for APP fraud (authorized push payment), strengthens TPP access. Platform must track legislative path closely.

6.3 Frictionless rates

A well-tuned 3DS implementation achieves >90% frictionless rate — the cardholder is authenticated silently using ACS risk score + device data + behavioral. Bad implementations stay at 40-60% frictionless, killing conversion. The platform measures + tunes: device data quality, browser DDC (Device Data Collector) coverage, exemption flagging rate, message-version selection. See Stripe and Adyen public 2023-2024 engineering blogs on 3DS optimization.

7. Real-time fraud — velocity rules + ML scoring

Fraud detection in card-not-present has two layers operating in parallel within the <60 ms fraud-decision budget:

7.1 Velocity rules layer (deterministic)

A rules engine evaluates ~100-400 hand-crafted rules per transaction. Examples:

   rule: same_card_5_attempts_5_min
   if  count(authorizations) WHERE card_hash = $card_hash
       AND ts > now() - 5 min > 5
   then decline reason=velocity_card

   rule: bin_attack_pattern
   if  count(declines) WHERE bin = $bin
       AND ts > now() - 60 sec > 50
   then block bin for 10 min

   rule: cross_merchant_card_spray
   if  distinct_count(merchant_id) WHERE card_hash = $card_hash
       AND ts > now() - 1 hr > 10
       AND avg_amount < $5
   then decline reason=card_testing

Velocity state held in Redis or DynamoDB with TTL; counters use HyperLogLog or count-min sketch for cardinality at scale. Rules expressed in domain-specific language (Falcon DSL legacy; modern stacks use Cloudflare Workers Rules-style, Sift Workflows, or in-house Rego/CEL).

7.2 ML scoring layer (probabilistic)

A gradient-boosted-trees model (XGBoost, LightGBM) and/or a small neural network scores each transaction in <30 ms. Features:

  • Card features — BIN risk, country, brand, prepaid flag, card-age, prior approval rate
  • Merchant features — MCC, country, prior dispute rate, average amount, ticket distribution
  • Cardholder features (where available) — email-age, IP geolocation, device fingerprint (FingerprintJS, ThreatMetrix), behavioral biometrics (BehavioSec, BioCatch)
  • Velocity features — counts + sums across (card, merchant, ip, device, email) over (1 min, 5 min, 1 hr, 24 hr, 30 d)
  • Network features — graph-distance from known-fraud nodes (Sift, Stripe Radar networks, Forter)
  • Sequence features — RNN/Transformer on transaction history (Stripe’s Radar v3 2023+)

Model training: offline on labeled dispute outcomes (chargeback feedback closes the loop with 60-120 day lag). Production inference via low-latency feature store (Tecton, Feast, in-house Redis-backed) + ONNX-runtime / Triton.

See rag-embeddings-vector-search for related similarity-search patterns and probability-fundamentals for the underlying distributional reasoning.

7.3 Decision fusion + governance

Final decision = rules outcome (hard block/decline/allow) + ML score band. ML alone never declines — auditability requires a rule-level reason code on every decline.

Governance: model card per deployed model (Mitchell et al. 2019), challenger-champion shadow scoring, monthly fairness audit (no protected-class proxy correlation), explainability via SHAP for any declined transaction the merchant queries. Required for CFPB ECOA + ECOA Reg B compliance.

8. Idempotency + replay safety

The single most-cited reliability lesson in modern payments engineering (Stripe Engineering blog 2017, 2020, 2023; Adyen Tech 2022): make every state-changing operation idempotent and observable across retries.

8.1 Idempotency key model

   client → POST /v1/charges
            Idempotency-Key: a7f3b8c2-merchant-side-uuid

   server → if key seen in last 24h: return cached response (same status, body, side-effects)
            else: acquire write-lock on key, execute, persist (key → response), release lock, return

Storage: Postgres table idempotency_keys (key, merchant_id, request_hash, response, status, created_at, locked_until) with a partial index. Or Redis Sorted Set for ephemeral keys.

Pitfalls:

  • Locking — two concurrent requests with same key must serialize. Use Postgres SELECT ... FOR UPDATE or Redis SETNX with TTL fallback. Lock timeout 30-60 s.
  • Request shape — if the same key arrives with different body, return 422 conflict, not the cached response. Use SHA-256 of the canonicalized body.
  • Network adapter side-effects — sending an ISO 8583 0100 a second time is dangerous. Adapter must check: has this STAN already been sent? Reuse STAN + retain prior network response.
  • Reversals — if response is uncertain (timeout), platform must auto-issue a 0400 reversal to release the issuer hold. Hanging auths are the worst customer-experience failure mode.

8.2 Saga / outbox pattern

Authorization touches Postgres (ledger), Redis (velocity), Kafka (events), network adapter (ISO 8583) — all in one logical operation. The platform uses transactional outbox (Kleppmann 2017 + Microservices Patterns Richardson 2018):

  1. Single Postgres transaction: write authorization row + write outbox row.
  2. Outbox publisher tails Postgres WAL via Debezium + emits to Kafka.
  3. Downstream services (fraud, ledger, notifications) consume from Kafka idempotently.

Avoids the dual-write problem; gives exactly-once-at-the-effects across boundaries.

See distributed-systems-fundamentals and microservices-patterns.

9. Double-entry ledger

Every transaction the platform processes must be recorded in an immutable, balanced ledger — the source of truth for settlement, reporting, dispute, and audit.

9.1 The model

Double-entry accounting (Pacioli 1494; rediscovered every decade): every transaction is two equal entries on opposite sides. For a $100 card payment:

   Tx 12345 (2026-05-25T14:32:01Z)
     DR  Merchant Receivable           $100.00
     CR  Cardholder Liability          $100.00

   On settlement (T+1):
     DR  Cardholder Liability          $100.00
     CR  Merchant Receivable           $100.00
     DR  Acquirer Settlement Account   $97.50    (after fees)
     CR  Merchant Payable              $97.50
     DR  Fee Revenue                   $2.50
     CR  Acquirer Settlement Account   $2.50

Always balanced; never amended; corrections via compensating entries.

9.2 Implementation patterns

  • Append-only Postgres table with (account_id, amount_minor, currency, direction, tx_id, ts). Trigger or check constraint enforces per transaction.
  • Account hierarchy — chart of accounts (Asset / Liability / Equity / Revenue / Expense) with per-merchant sub-accounts. Tens of millions of accounts at scale; partitioned by merchant_id.
  • Currency precision — store amounts as integer minor units (cents, satoshis). Never floats. For currencies with sub-cent precision (some crypto, some commodity), use Postgres numeric(38,18) or dedicated decimal types. Currency exposure carried in separate FX accounts.
  • Balance calculation — SELECT SUM(amount * direction) WHERE account_id = ? AND ts <= ? — materialized at end-of-day for fast lookups; live for current-period.
  • Versioned schema — chart of accounts versioned with migration scripts; never delete account, only flag inactive.

Reference implementations: Square’s ledger talks (Reibel 2020), Modern Treasury’s Compliant SaaS Ledger product, TigerBeetle (purpose-built financial DB, GA 2024), Stripe’s internal ledger (rumored Vitess-on-Postgres custom), Block’s published ledger paper (Klein et al. 2021).

See accounting-foundations for the double-entry foundation and database-internals for the storage engine details.

9.3 Reconciliation

Every day, platform reconciles:

  • Internal authorizations table ↔ network settlement files (BASE II, IPM, SGR)
  • Settlement-bank cash deposits ↔ expected merchant payables
  • Fees collected ↔ fee revenue ledger
  • Chargebacks adjusted ↔ chargeback reserve account

Discrepancies (mismatched amounts, missing transactions, orphan settlements) escalate to finance ops within 1 hr. The “ledger reconciliation queue” is the single most important operational dashboard in the platform — a 4-cent rounding bug at 100M tx/yr is $4M/yr in real money.

10. Disputes + chargebacks

The dispute lifecycle is governed by network rules — Visa Dispute Rules (Sep 2024), Mastercard Dispute Resolution Initiative (MDRI), Amex Dispute Resolution. Reason codes are network-specific; the platform abstracts to a unified taxonomy.

10.1 Lifecycle

   Cardholder calls issuer → "I didn't make this charge"
        |
        v
   Issuer initiates retrieval (informational, no funds move) OR chargeback
        |
        v
   Network sends 0420 / TC15 / chargeback advice
        |
        v
   Acquirer (this platform) receives — funds debit immediately
        |
        v
   Platform forwards to merchant — merchant has 7-14 days to represent
        |
        | If merchant accepts → done, funds stay with cardholder
        | If merchant represents → submit compelling evidence
        v
   Network adjudicates (or sends to issuer for final decision)
        |
        | If issuer accepts representment → second chargeback
        | If platform accepts → pre-arbitration
        v
   Visa Resolve Online (VROL) / Mastercom adjudication
        |
        v
   Outcome final — funds final

Timelines:

  • Initial chargeback window: 60-120 days from transaction date (varies by reason)
  • Representment window: 7-30 days
  • Pre-arbitration: 30 days
  • Arbitration: 30-60 days, $500-1000 case fee

10.2 Chargeback monitoring programs

  • Visa Acquirer Monitoring Program (VAMP) — replaced VFMP + VDMP in 2025; thresholds for fraud rate (>0.65% or $50K fraud-volume / month) and dispute rate (>0.9%)
  • Mastercard Excessive Chargeback Merchant (ECM) — >1.5% chargeback ratio = excessive
  • Mastercard Excessive Fraud Merchant (EFM) — >0.5% fraud-tx-ratio + >$50K fraud volume

Above threshold = fines ($1K-25K/mo escalating) + remediation plan. Persistently above = portfolio termination — Visa and Mastercard can de-list a merchant network-wide (MATCH list / Mastercard Alert to Control High-risk merchants).

10.3 Compelling evidence

For represented disputes, platform automates evidence collection:

  • AVS + CVV match codes from auth
  • 3DS authentication + CAVV
  • Device fingerprint + IP geolocation match with shipping
  • Delivery confirmation (UPS, FedEx, electronic-delivery logs)
  • Prior successful transactions from same cardholder
  • Customer support transcripts

Compelling Evidence 3.0 (Visa, Apr 2023) standardized representment for “card-not-recognized” disputes; well-instrumented merchants now win 50-70% of these.

11. Currency precision and FX

Multi-currency operations introduce two distinct risks: precision loss and FX exposure.

11.1 Precision

  • Store all amounts as integer minor units (USD cents, EUR cents, JPY yen — JPY has zero minor units, BHD has three).
  • Use a strongly-typed Money value object in code with currency tag; arithmetic only between same-currency Money. Reject coercion.
  • Currency table sourced from ISO 4217; updated annually.
  • Sub-cent rounding (interchange + assessment fees can compute to fractional cents): bank’s rounding rules — typically half-even (banker’s rounding) per IEEE 754 or per network spec.

11.2 FX exposure

When merchant settles in currency X but transaction is in currency Y, platform either:

  • Pass-through FX — merchant accepts FX risk; settle at issuer-side rate (DCC); merchant receives in cardholder’s currency converted at platform’s rate at settlement time.
  • Multi-currency pricing (MCP) — merchant prices in cardholder’s currency; settles in merchant’s currency at a daily lock-in rate.
  • Acquirer settles native — merchant has a USD + EUR + GBP account; no FX.

The FX margin (50-300 bps) is acquirer revenue. The platform holds FX positions during the auth-to-settlement window (T+0 to T+5) — must hedge or accept the carry risk. Typical hedge: same-currency cash held in each major-currency settlement account; weekly net-flat trade with a tier-1 FX bank (HSBC, Citi, Deutsche Bank).

12. Real-time payment rails (FedNow, RTP, SEPA Instant, Pix)

A modern payment platform must integrate beyond cards into real-time account-to-account rails:

RailGeographySettlementFormatOperator
FedNowUSInstant 24×7×365ISO 20022 pacs.008Federal Reserve, GA Jul 2023
RTPUSInstant 24×7×365ISO 20022 pacs.008The Clearing House (since Nov 2017)
Same-Day ACHUSSame-day batch (3 windows)NACHA ACHNACHA Operating Rules, latest 2026 release
SEPA SCT InstEU<10 s, 24×7ISO 20022 pacs.008EBA Clearing, EU Instant Payment Regulation Mar 2024
FPSUKNear-instant 24×7CustomPay.UK, 25+ years operating
PixBrazilInstant 24×7ISO 20022 profileBanco Central do Brasil, GA Nov 2020
UPIIndiaInstant 24×7NPCI proprietaryNPCI, GA Apr 2016
PromptPayThailandInstantISO 20022Thai banks consortium

Integration model: the platform’s network adapter layer adds a rail-specific module per rail. Same canonical message in; rail-specific format out. Authorization model differs sharply from cards — funds move immediately on success, no separate clearing or settlement phase, no chargeback (most rails are final-and-irrevocable; fraud recovery is bilateral and slow).

EU Instant Payment Regulation (Mar 2024, effective in phases through Oct 2025): all EU banks must offer SEPA Inst at no extra fee, with payee verification (IBAN-name check). Drives massive shift from SEPA-SCT to SEPA-Inst.

See fintech-architecture-deep for the rail-comparison detail.

13. Regulatory regime

13.1 PCI-DSS v4.0

Effective March 2024 (most requirements), March 2025 (future-dated requirements like targeted risk analysis, enhanced authentication, MFA on all CDE access). Annual Report on Compliance (ROC) by a QSA (Qualified Security Assessor) for Level 1 (>6M tx/yr). 12 requirements, 300+ controls.

Notable v4.0 additions:

  • Customized approach (control objectives + organization-defined methods) alongside defined approach
  • Targeted risk analyses required for many controls
  • MFA for all access into CDE, not just remote
  • Enhanced authentication for any CDE account (no shared accounts)
  • E-commerce payment-page integrity (req 6.4.3, 11.6.1) — script integrity monitoring on payment page
  • Encryption of stored PAN — strong cryptography, key strength minimums

QSAs: Coalfire, NCC Group, A-LIGN, Schellman, Trustwave, Foregenix. Audit cost $150-400K for Level 1.

13.2 PSD2 + PSD3

PSD2 (Directive 2015/2366, in force 2018) requires:

  • SCA (Article 97 + RTS) — covered above
  • Open Banking — third-party providers (PISPs, AISPs) get access to PSU accounts via standardized APIs; UK Open Banking + EU NextGenPSD2 specs (Berlin Group, STET)
  • Authorization for payment institutions + e-money institutions per home-state regulator (BaFin DE, FCA UK, ACPR FR, etc.)

PSD3 + PSR1 (proposed Jun 2023, expected late 2025): refines exemptions, mandates explicit fraud-liability for APP fraud (sender-reimbursement), strengthens TPP access, IBAN-name verification.

13.3 US framework

No single federal regulator; layered:

  • OCC + FRB + FDIC — banks
  • FinCEN — money services businesses (BSA, AML, KYC), 31 USC 5311
  • CFPB — Reg E (electronic funds transfer), Reg Z (truth in lending), Reg P (privacy), Section 1033 (Oct 2024 — data access rule)
  • State money transmitter licences — required in 49 states + DC + PR for funds transmission; license-by-license cost $0.5-3M to acquire all (Stripe, Square, Adyen have full multi-state)
  • NACHA — ACH operating rules
  • OFAC — sanctions screening on every transaction
  • State AG + FTC — UDAP enforcement

13.4 Card-network rules

Visa Core Rules (~800-page document, semi-annual update April + October), Mastercard Standards (similar), Amex Merchant Reference Guide, Discover Operating Regulations. These are private contracts — but binding for any party touching the network.

Notable annual compliance:

  • Annual ROC submission (PCI)
  • Self-Assessment Questionnaire (lower-tier merchants)
  • Penetration testing per network rules + PCI
  • Network-fee schedule updates April + October
  • Visa + Mastercard product launches (Click to Pay / SRC, click-and-collect, BNPL acquiring categories)

14. Trade-off matrix — key build decisions

DecisionOption AOption BTrade-off
TokenizationIn-house vaultVendor (Spreedly, Basis Theory, VGS)In-house: control + cost at scale, ~12-18 mo build; vendor: speed but per-token cost (0.2-1¢) accumulates at scale
Network adapterBuild ISO 8583 stackBuy (ACI Postilion, OpenWay WAY4, NCR Authentic)Build: 2-8M licence + faster path, vendor lock-in
LedgerPostgres append-onlyTigerBeetle / dedicatedPostgres: familiar, scales to ~10K TPS journals; TigerBeetle: 100K+ TPS, purpose-built, smaller ecosystem
FraudIn-house rules + MLSift / Forter / Riskified / Stripe RadarIn-house: more control + cheaper at scale (>$1B GPV); vendor: faster start, less data network effect
SIEM in CDESplunk ESSentinelSplunk: deeper PCI templates; Sentinel: cheaper if Azure already + AAD integration
HSMAWS CloudHSMThales Luna on-premCloud: lower opex, harder for some regulators; on-prem: tighter control + audit
Settlement modelSingle-currency per merchantMulti-currency MCPSingle: simpler ops, narrower TAM; MCP: 50-300 bps FX margin, more complexity
3DS serverIn-houseCardinal / Visa / Mastercard / NetceteraIn-house: optimize frictionless rate; vendor: faster cert, less optimization control

15. Failure modes

  • Issuer outage — STIP partially mitigates, but persistent issuer-side downtime = declined authorizations. Monitor STIP rate per BIN; switch to alternative auth path (recurring billing safe-list, batch-resubmit).
  • Network outage — Visa or Mastercard outages happen (Visa Jun 2018 4-hour outage; Mastercard outages quarterly, brief). SAF queues + retry; merchant-side soft fallback to alternative network.
  • Tokenization vault outage — entire authorization path stops. Active-active multi-region vault deployment with synchronous replication of token-to-PAN mapping (key wrapping ensures encrypted-at-rest even in transit).
  • Reconciliation drift — silent ledger discrepancies are the existential risk. End-of-day automated recon catches typical drift within 24 h; daily limit alerts on net unreconciled position.
  • Fraud-model drift — feature distribution shifts (e.g., new cardholder demographic, holiday-season buying patterns). Shadow scoring + monthly retraining; champion-challenger comparison required.
  • Network rule change — Visa or Mastercard quarterly rule updates can require code changes in <90 days. Dedicated network-compliance team monitors + ticketizes.
  • Card BIN reissuance — issuer reissues card with new BIN; merchant-stored credentials become stale. Account Updater (Visa VAU + Mastercard ABU) services keep stored credentials current — platform must integrate.
  • Sanctions / OFAC false positives — over-zealous screening blocks legitimate transactions; calibrate against transaction-level risk; allow merchant-side manual review queue with SLA.
  • PCI scope creep — every “let’s add this small feature” can pull a host into CDE; rigorous architecture review for any CDE-adjacent change. Failure: CDE host count drifts from 120 to 400 over 2 years and audit cost triples.
  • Capital reserves — chargeback-fraud waves require liquidity; processor must hold reserves at sponsor bank (typically 1-4% of monthly GPV). Synapse-Evolve (Apr-May 2024) showed failure mode when reserves are commingled or mismanaged.

16. Observability + SLOs

16.1 SLOs

MetricTargetWindow
Authorization p99 latency<500 ms7 d rolling
Authorization availability99.995%30 d rolling
Issuer auth approval rate>85% (mature merchants)7 d
Token resolution latency<10 ms p997 d
Settlement file deliveryT+1 by 06:00 localMonthly
Recon discrepancy resolved<24 hr for >$100 itemsMonthly
Chargeback win rate>40% on representments90 d
Fraud loss rate<8 bps on CNP90 d
3DS frictionless rate>85% on EU CNP30 d

16.2 Instrumentation

  • OpenTelemetry for traces + metrics + logs across the gateway, orchestrator, network adapter, ledger writes. Trace ID propagation includes the merchant idempotency key for cross-team debugging.
  • Network adapter instrumented with per-DE timing (parse, sign, send, receive, decode); STAN-level traceability into network operator’s portal.
  • Ledger — every entry tagged with tx_id, merchant_id, account_id, currency; daily compute on per-account drift.
  • Fraud model — feature distribution monitoring (PSI — Population Stability Index), score-distribution shift, top-feature drift alerts.
  • Synthetic monitoring — synthetic auth from canary merchant every 30 s through every issuer route; alert on regression.

16.3 Incident response

  • Tiered severity SEV1 (authorization down, network outage) — exec page, 5-min triage, customer comms within 15 min.
  • Public status page (statuspage.io or Atlassian Statuspage) with per-network + per-region indicators.
  • Annual incident retro reviewed at board level; PCI requires documented IR plan + annual test.
  • Card-network incident reporting: Visa requires SAR (Suspected Account Report) within 24 h for any actual or suspected account compromise; Mastercard ADC (Account Data Compromise) similar.

See observability-stack for the broader stack.

17. Cost build

17.1 Build CAPEX (24-36 mo greenfield to Level-1)

ItemCost
Core engineering (50 FTE × 30 mo × $20-25K loaded)$30-37M
Network adapter (ISO 8583) build or licence$4-12M
Tokenization vault + HSM infrastructure$3-6M
Cloud + datacenter buildout (dual region)$4-8M
PCI-DSS Level 1 cert (ROC + remediation + first audit)$0.4-0.8M
Card-network certifications (Visa VIP, Mastercard MTF, Amex GES)$1.5-3M
State money-transmitter licences (49 states)$2-4M (filings + bonds + legal)
Sponsor bank setup + reserves$5-15M (locked reserve)
Legal + compliance buildout$3-6M
Pen testing + security (annual through build)$1-2M
Build CAPEX total$54-94M

17.2 Annual OPEX (steady-state, 1B tx/yr)

ItemAnnual cost
Headcount (engineering 80 + ops 60 + compliance 30 + risk 25 + fraud 30 + GTM 50 = 275 FTE blended $230K)$63M
Cloud + datacenter (dual-region active-active)$14M
Network connectivity (Visa + MC + Amex + Discover dual links)$3M
PCI-DSS audit + pen test + security tooling$2.5M
Insurance (cyber + E&O + crime + bond)$6M
Sponsor bank fees + interchange + assessments (pass-through, separate accounting line)excluded
Card-network annual fees$4M
Vendor stack (Datadog, Splunk, vendor fraud feeds, BIN data)$5M
Legal + state licence renewals$3M
Reserves carry cost$2M
Annual OPEX (excluding interchange pass-through)~$103M

17.3 Revenue at scale

At 2.0B gross merchant fees. Of that:

  • Interchange pass-through ~$1.4B (70%)
  • Network assessments + fees ~$0.18B (9%)
  • Net acquirer-processor revenue ~$0.42B (21%)
  • Minus opex above 320M operating margin (~16 bps of GPV)

These ratios match published 2023-2024 numbers from Adyen, Block, and FIS Merchant Solutions. Stripe operates a richer mix (Connect, Issuing, Treasury) that lifts net take rate to ~50 bps.

18. Risk register

  • Sponsor-bank exit — if sponsor bank pulls out (Evolve 2024 lesson), platform must have backup sponsor + 18-mo runway.
  • Network sanction — if processor’s fraud or dispute portfolio degrades, network can terminate. Maintain remediation reserve + capacity to shed worst merchants.
  • PCI cert lapse — non-compliance = immediate stop-card-network — existential. Continuous compliance discipline, never wait until annual audit.
  • OFAC / sanctions screening failure — fines up to $1M per violation; criminal exposure. Real-time screening on every counterparty, daily list updates.
  • AML / BSA — failures can carry 7.7M, Robinhood Crypto 2023 3B for BSA). Designated BSA officer, transaction monitoring, SAR filing within 30 days.
  • CFPB action — Section 1033 access rule (Oct 2024) + Section 1071 small-business reporting compound. Compliance roadmap through 2026-2028.
  • Foreign-corruption — FCPA + UK Bribery Act 2010 — emerging markets onboarding requires deep KYC + ABC controls.
  • State regulator divergence — NY DFS (BitLicense + virtual currency), CA DFPI (consumer financial law), TX (state-specific MTL).
  • Stablecoin + crypto integration — emerging rule sets (MiCA EU Jun 2024 in force, FIT21 US House 2024 passed, GENIUS / STABLE Acts pending). Bridge acquisition (Stripe Oct 2024) signals stablecoin rails enter mainstream by 2026-2027.
  • Quantum-cryptographic transition — PCI v5 (anticipated 2027-2028) likely mandates post-quantum cryptography migration paths (NIST FIPS 203/204/205 ML-KEM / ML-DSA / SLH-DSA). Begin crypto-agility audit now.

19. Adjacent

20. Glossary

  • 3DS — 3-D Secure; cardholder authentication protocol
  • ACS — Access Control Server; issuer-side 3DS component
  • AVS — Address Verification Service
  • BAU — Business as Usual
  • BIN — Bank Identification Number; first 6-8 digits of PAN
  • CAVV — Cardholder Authentication Verification Value; 3DS auth token
  • CDE — Cardholder Data Environment (PCI scope)
  • CHD — Cardholder Data
  • CNP — Card Not Present
  • CP — Card Present
  • CVV / CVV2 / CVC — Card Verification Value
  • DCC — Dynamic Currency Conversion
  • DE — Data Element (ISO 8583)
  • DS — Directory Server (3DS)
  • EMV — Europay-Mastercard-Visa chip standard
  • FPS — Faster Payments Service (UK)
  • GPV — Gross Processing Volume
  • HSM — Hardware Security Module
  • MCC — Merchant Category Code
  • MDR — Merchant Discount Rate
  • MIT — Merchant-Initiated Transaction
  • MID — Merchant Identifier
  • MTI — Message Type Indicator (ISO 8583)
  • PAN — Primary Account Number (card number)
  • PCI-DSS — Payment Card Industry Data Security Standard
  • PSD2 / PSD3 — Payment Services Directive 2/3 (EU)
  • QSA — Qualified Security Assessor (PCI)
  • ROC — Report on Compliance (PCI)
  • RTP — Real-Time Payments (US TCH)
  • SAD — Sensitive Authentication Data
  • SAF — Store-and-Forward
  • SCA — Strong Customer Authentication
  • STAN — System Trace Audit Number
  • STIP — Stand-In Processing
  • T+1 — Settlement next business day
  • TCH — The Clearing House
  • VAMP — Visa Acquirer Monitoring Program
  • VAU / ABU — Visa Account Updater / Mastercard Automatic Billing Updater

Graph View

Backlinks