# Card Acquiring Payments Design: [Acquirer, PSP or merchant platform name]

> Solution design for accepting card payments as an acquirer, payment
> service provider or large merchant: gateway, authorisation, 3-D Secure
> authentication, strong customer authentication and exemptions,
> tokenisation, fraud screening, capture, clearing and settlement, fees,
> chargebacks and PCI DSS scope. It references EMV 3-D Secure (EMVCo,
> versions 2.2.0 to 2.3.1.1 in use, version 2.4 in draft as of June
> 2026), PCI DSS v4.0.1 (PCI Security Standards Council), and, for the
> European Economic Area, the PSD2 strong customer authentication rules
> in Commission Delegated Regulation (EU) 2018/389. Card network rules
> are proprietary and are named, not reproduced. Replace every
> `[bracketed]` value and every row marked *Example*. Legal and scheme
> obligations are summarised for planning only: check the current
> official texts, network rules and a qualified professional. This is a
> documentation format, not legal or financial advice.

<!--
Guidance: How to use this template
- Write one design per acquiring platform or per merchant payments
  stack. Network-specific rules (each card scheme) go into rows of the
  registers, not separate documents.
- Fill the party register (section 2) and the PCI DSS scope (section 9)
  first. They decide which components hold card data and which do not.
- Keep cardholder data out of every component that does not need it.
  Every system that stores, processes or transmits the primary account
  number (PAN) joins the PCI DSS scope.
- Related documents: PCI DSS scoping and segmentation
  (`compliance/pci-dss-scoping-segmentation`), Fraud detection design
  (`system-design/design-fraud-detection`), Payment ledger design
  (`system-design/design-payment-ledger`), ISO 20022 payments design
  (`industry/iso20022-payments-design`), Open banking API design
  (`industry/open-banking-api-design`), Composable commerce architecture
  (`industry/composable-commerce-architecture`).
-->

## Document control

<!-- Guidance: Record the networks, regions and specification versions the design targets. A new network or region is a major version; a new 3-D Secure protocol version is a minor version. -->

| Field | Value |
|---|---|
| Document ID | [CAD-001] |
| Platform | [Acquirer host / Payment gateway / Merchant checkout] |
| Card networks | [International schemes, domestic schemes, wallets] |
| Regions | [EEA, UK, US, other] |
| Channels | [E-commerce, in-app, card-present, unattended, mail and telephone order] |
| Specifications targeted | [*Example:* EMV 3DS 2.2.0 and 2.3.1.1; PCI DSS v4.0.1] |
| Version | [0.1] |
| Status | [Draft / In review / Approved / Superseded] |
| Owner | [@payments-architect] |
| Approvers/reviewers | [@head-of-acquiring], [@fraud-lead], [@ciso], [@pci-qsa-liaison], [@compliance-lead] |
| Classification | [Confidential] |
| Last updated | YYYY-MM-DD |

### Approvals

| Role | Name | Decision | Date |
|---|---|---|---|
| Head of acquiring or payments | [@name] | [Approve / Approve with conditions / Reject] | YYYY-MM-DD |
| Fraud and risk | [@name] | [Decision] | YYYY-MM-DD |
| Information security | [@name] | [Decision] | YYYY-MM-DD |
| Compliance | [@name] | [Decision] | YYYY-MM-DD |

### Revision history

| Version | Date | Author | Change summary |
|---|---|---|---|
| 0.1 | YYYY-MM-DD | [@name] | First draft |
| 0.2 | YYYY-MM-DD | [@name] | *Example:* Added network tokens for stored credentials |
| 1.0 | YYYY-MM-DD | [@name] | *Example:* Approved for build and certification |

## Contents

<!-- Guidance: Keep this list aligned with the headings below. -->

1. [Scope and drivers](#1-scope-and-drivers)
2. [Parties and roles](#2-parties-and-roles)
3. [Payment flows](#3-payment-flows)
4. [3-D Secure authentication](#4-3-d-secure-authentication)
5. [Strong customer authentication and exemptions](#5-strong-customer-authentication-and-exemptions)
6. [Tokenisation and stored credentials](#6-tokenisation-and-stored-credentials)
7. [Fraud and risk controls](#7-fraud-and-risk-controls)
8. [Disputes and chargebacks](#8-disputes-and-chargebacks)
9. [PCI DSS scope and security](#9-pci-dss-scope-and-security)
10. [Clearing, settlement, fees and reconciliation](#10-clearing-settlement-fees-and-reconciliation)
11. [Non-functional design and operations](#11-non-functional-design-and-operations)
12. [Testing and certification](#12-testing-and-certification)
13. [Obligations and deadline register](#13-obligations-and-deadline-register)
14. [Traceability matrix](#14-traceability-matrix)
15. [Glossary and references](#15-glossary-and-references)

## 1. Scope and drivers

<!-- Guidance: State channels, networks, regions and merchant types in scope, and why the design is changing now. Name the business measures that will show the design works: approval rate, fraud rate, dispute rate, cost per transaction. -->

### 1.1 Scope

| ID | Channel | Merchant segment | Networks | Regions | In scope |
|---|---|---|---|---|---|
| SCP-001 *(Example)* | E-commerce web and in-app | Retail and travel merchants | International schemes | EEA, UK | Yes |
| SCP-002 *(Example)* | Stored credential and subscriptions | Digital services | International schemes | EEA, UK, US | Yes |
| SCP-003 *(Example)* | Card-present terminals | Retail stores | International and domestic schemes | EEA | Yes |
| SCP-004 *(Example)* | Mail and telephone order | Travel agents | International schemes | EEA | No (later phase) |

### 1.2 Drivers

| ID | Driver | Consequence for the design |
|---|---|---|
| DRV-001 *(Example)* | Low approval rate on authenticated e-commerce payments in the EEA | Exemption engine and data-rich 3-D Secure requests to raise frictionless rate |
| DRV-002 *(Example)* | PCI DSS v4.0.1 requirements now in force, including the formerly future-dated ones | Payment page script controls, targeted risk analyses, stronger authentication for admin access |
| DRV-003 *(Example)* | Card-on-file updates fail when cards are reissued | Network tokens with automatic lifecycle updates |
| DRV-004 *(Example)* | Rising dispute costs in the travel segment | Dispute evidence automation and pre-dispute alerts |

## 2. Parties and roles

<!-- Guidance: Name each party in the four-party model and who plays it in your design, including any third party you outsource to. A clear role table prevents gaps in responsibility for authentication, liability and PCI DSS compliance. -->

| ID | Role | Responsibility | Played by |
|---|---|---|---|
| PTY-001 | Cardholder | Pays with a card or wallet | Customers of the merchant |
| PTY-002 | Merchant | Sells goods or services, starts the payment | [*Example:* Kestrelmoor Outdoor (fictional)] |
| PTY-003 | Payment gateway | Accepts payment requests from merchant channels, routes them | [In-house / Vendor] |
| PTY-004 | Acquirer | Holds the merchant agreement, sends transactions to the networks, settles funds to the merchant | [*Example:* Brindlemoor Payments (fictional)] |
| PTY-005 | Acquirer processor | Runs authorisation and clearing for the acquirer | [In-house / Vendor] |
| PTY-006 | Card network | Routes messages between acquirers and issuers, sets network rules and fees | [Scheme names] |
| PTY-007 | Issuer | Issues the card, approves or declines, authenticates the cardholder | Cardholder's bank |
| PTY-008 | 3DS Server | Sends authentication requests for the merchant | [Vendor] |
| PTY-009 | Directory Server | Network component that routes 3-D Secure messages | Card network |
| PTY-010 | Access Control Server (ACS) | Issuer component that decides frictionless or challenge | Issuer or its vendor |
| PTY-011 | Token service provider | Issues network tokens in place of PANs | Card network |

## 3. Payment flows

<!-- Guidance: Draw each flow with the message on each arrow and the system that decides. Keep the same participants as the role table. Add one row per flow to the inventory. -->

### 3.1 E-commerce purchase with 3-D Secure

*Example:* a customer pays on the merchant's checkout; authentication
runs before authorisation; capture follows shipment.

```mermaid
sequenceDiagram
  participant CH as Cardholder browser or app
  participant M as Merchant checkout
  participant G as Payment gateway
  participant TDS as 3DS Server
  participant DS as Directory Server
  participant ACS as Issuer ACS
  participant ACQ as Acquirer processor
  participant N as Card network
  participant ISS as Issuer host
  CH->>M: enter card or choose stored token
  M->>G: payment request with order data
  G->>TDS: authentication request data
  TDS->>DS: AReq
  DS->>ACS: AReq
  ACS-->>DS: ARes frictionless or challenge required
  DS-->>TDS: ARes
  TDS-->>G: result
  G-->>CH: challenge window if required
  CH->>ACS: CReq and cardholder response
  ACS->>DS: RReq with final result
  DS->>TDS: RReq
  G->>ACQ: authorisation request with authentication value
  ACQ->>N: authorisation request
  N->>ISS: authorisation request
  ISS-->>N: approve or decline
  N-->>ACQ: response
  ACQ-->>G: response
  G-->>M: approved, order confirmed
  M->>G: capture after shipment
```

### 3.2 Transaction states

```mermaid
stateDiagram-v2
  [*] --> Authenticated
  [*] --> Authorised: exemption or out of scope
  Authenticated --> Authorised
  Authenticated --> Declined
  Authorised --> Captured
  Authorised --> Voided: cancelled before capture
  Captured --> Cleared
  Cleared --> Settled
  Settled --> Refunded
  Settled --> Disputed
  Disputed --> Settled: dispute won
  Disputed --> ChargedBack: dispute lost
  Declined --> [*]
  Voided --> [*]
  Refunded --> [*]
  ChargedBack --> [*]
```

The state machine above is the contract for every channel. A
transaction can be authorised without 3-D Secure only where an exemption
applies or the transaction is out of scope of strong customer
authentication (section 5).

### 3.3 Flow inventory

| ID | Flow | Trigger | Authentication | Capture |
|---|---|---|---|---|
| FLW-001 *(Example)* | Customer-initiated e-commerce purchase | Checkout | 3-D Secure or exemption | At shipment |
| FLW-002 *(Example)* | Card-on-file setup | Account creation or first purchase | 3-D Secure with challenge preference | Zero-value verification or first purchase |
| FLW-003 *(Example)* | Merchant-initiated recurring payment | Billing schedule | Out of scope after the authenticated setup | Immediate |
| FLW-004 *(Example)* | Card-present chip and PIN or contactless | Terminal | Chip with PIN or contactless limits | Immediate |
| FLW-005 *(Example)* | Refund | Merchant request | None | Credit to the card |

## 4. 3-D Secure authentication

<!-- Guidance: State the protocol versions supported, the data the merchant sends to the issuer, and how the result is passed into authorisation. More and better data in the authentication request is the main lever for a higher frictionless rate. -->

### 4.1 Versions and components

| ID | Item | Decision |
|---|---|---|
| TDS-001 *(Example)* | Protocol versions supported | EMV 3DS 2.2.0 and 2.3.1.1; plan a review when version 2.4 is final (draft published by EMVCo on 3 June 2026) |
| TDS-002 *(Example)* | 3DS Server | Vendor with EMVCo letter of approval, checked yearly |
| TDS-003 *(Example)* | SDK for in-app | Vendor SDK with EMVCo approval, native challenge screens |
| TDS-004 *(Example)* | Version fallback | Use the highest version the card range supports, from the Directory Server card range data |

### 4.2 Authentication request data

| ID | Data group | Examples of content | Source |
|---|---|---|---|
| ARD-001 *(Example)* | Cardholder account | Account age, last password change, number of purchases in 6 months | Merchant customer profile |
| ARD-002 *(Example)* | Device and browser | Browser data or SDK device data | Checkout page or SDK |
| ARD-003 *(Example)* | Purchase | Amount, currency, merchant category, delivery timeframe, gift card flag | Order |
| ARD-004 *(Example)* | Addresses | Billing and shipping, match indicator | Order |
| ARD-005 *(Example)* | Requestor preference | Challenge preference, exemption requested by acquirer | Exemption engine |

### 4.3 Measures

*Example:* in one month the platform sent 480,000 authentication
requests; 408,000 completed frictionless. The frictionless rate is
408,000 / 480,000 = 85.0 percent. Report it by issuer, network and
merchant segment; a low rate for one issuer usually points to missing
data in ARD-001 to ARD-004.

## 5. Strong customer authentication and exemptions

<!-- Guidance: Map each flow to the SCA rule that applies in each region and to the party that decides. In the EEA the payer's PSP (the issuer) applies SCA; the acquirer may request certain exemptions, and the liability follows the party that applied the exemption under network rules. Outside the EEA and UK, SCA is not a legal requirement in most markets, but networks may still use 3-D Secure. -->

### 5.1 Legal basis by region

| ID | Region | Basis | Notes to check |
|---|---|---|---|
| REG-001 | EEA | Directive (EU) 2015/2366 (PSD2) Article 97 and Commission Delegated Regulation (EU) 2018/389 (RTS on SCA and common secure communication) | The Payment Services Regulation and PSD3 were politically agreed on 27 November 2025 and the texts approved in Parliament committee on 5 May 2026, but were not in the Official Journal as of October 2026; check the current status |
| REG-002 | UK | Payment Services Regulations 2017 and the FCA's SCA rules | Check the FCA's current rules, which may differ from the EU RTS |
| REG-003 | US | No general SCA mandate | Network rules and fraud liability rules apply |

### 5.2 Exemption register (EEA)

| ID | Exemption or case | RTS article | Conditions in brief | Who may apply |
|---|---|---|---|---|
| EXM-001 | Contactless at point of sale | Article 11 | Single payment up to EUR 50, with cumulative limits since the last SCA (EUR 150 or 5 consecutive payments) | Issuer |
| EXM-002 | Trusted beneficiaries | Article 13 | Payer has added the merchant to a list held by the issuer | Issuer |
| EXM-003 | Recurring transactions | Article 14 | Same amount and same payee, SCA at setup | Issuer |
| EXM-004 | Low-value remote payment | Article 16 | Up to EUR 30, with cumulative limits since the last SCA (EUR 100 or 5 consecutive payments) | Issuer |
| EXM-005 | Secure corporate payment processes | Article 17 | Dedicated corporate processes approved by the authority | Issuer |
| EXM-006 | Transaction risk analysis | Article 18 | Low-risk transaction, with amount bands tied to the PSP's reported fraud rate | Issuer or acquirer, each against its own fraud rate |
| EXM-007 *(case, not an exemption)* | Merchant-initiated transaction | Outside SCA scope by the payer's initiation test | Valid mandate and authenticated setup | Merchant flags, issuer accepts |

Check the consolidated RTS text, the EBA Q&A and the network rules for
the exact conditions, including the fraud-rate reference values in the
RTS annex, before implementing the exemption engine. Applying an
exemption moves fraud liability under network rules: record the rule
reference for each row.

## 6. Tokenisation and stored credentials

<!-- Guidance: Describe where PANs are replaced by tokens, which token types are used, and how stored credentials stay valid when cards are reissued. Every component that sees only tokens can be designed outside the PCI DSS cardholder data environment if the token cannot be turned back into a PAN there. -->

| ID | Token type | Issued by | Used for | Detokenised by |
|---|---|---|---|---|
| TOK-001 *(Example)* | Network token with cryptogram | Network token service | Card-on-file e-commerce and wallets | Network, for the issuer |
| TOK-002 *(Example)* | Gateway token (PAN vault reference) | Gateway vault | Merchant systems, refunds, reporting | Gateway vault only |
| TOK-003 *(Example)* | Device token | Wallet provider and network | In-store and in-app wallet payments | Network |

Rules:

1. Merchant systems hold gateway tokens only; the PAN vault sits in the
   smallest possible segment of the cardholder data environment.
2. Stored credentials carry the stored-credential indicators required by
   the networks, with the first authenticated transaction identifier
   kept for later merchant-initiated payments.
3. Network token lifecycle events (card reissued, card closed) update
   the stored credential automatically.
4. Truncated PANs, when shown, follow the PCI DSS masking rule for
   display.

## 7. Fraud and risk controls

<!-- Guidance: List the checks before authentication, after authentication and after authorisation, with time budgets. Fraud scoring feeds both the exemption engine and the decision to request a challenge. Link to the fraud design for model details. -->

| ID | Control | Position | Inputs | Time budget | Outcome |
|---|---|---|---|---|---|
| FRD-001 *(Example)* | Velocity and device checks | Before authentication | Device, IP, card, account | 50 ms | Allow, step-up, block |
| FRD-002 *(Example)* | Fraud score for exemption decision | Before authentication | Order, customer history, device | 100 ms | Request exemption or SCA |
| FRD-003 *(Example)* | Merchant risk monitoring | Daily | Fraud and dispute rates per merchant | Batch | Review, reserve, terminate |
| FRD-004 *(Example)* | Post-authorisation review | Before capture | High-risk orders | Minutes to hours | Capture or void |

Model features, governance and evaluation: fraud detection design
(`system-design/design-fraud-detection`).

## 8. Disputes and chargebacks

<!-- Guidance: Describe the dispute lifecycle, evidence sources and deadlines. Network rules set the reason codes, stages and time limits and differ by network; record them as references, not copies. Report the dispute ratio per merchant, because networks run monitoring programmes on it. -->

### 8.1 Lifecycle

| ID | Stage | Trigger | Acquirer action | Evidence |
|---|---|---|---|---|
| DSP-001 *(Example)* | Pre-dispute or inquiry | Issuer or alert service | Offer refund or provide information | Order, delivery, authentication data |
| DSP-002 *(Example)* | First chargeback | Issuer files under a reason code | Debit merchant, notify, collect evidence | Per reason code |
| DSP-003 *(Example)* | Representment | Merchant contests within the network time limit | Submit evidence | Proof of delivery, 3-D Secure result, usage logs |
| DSP-004 *(Example)* | Pre-arbitration and arbitration | Issuer does not accept | Decide whether to escalate | Full case file |

### 8.2 Measures

*Example:* a merchant had 1,140 disputes on 1,200,000 transactions in a
month. The dispute ratio is 1,140 / 1,200,000 = 0.095 percent. Compare
it with the thresholds in each network's monitoring programme, which
change and are set in network rules.

Design rules: keep authentication results, device data and delivery
evidence with the transaction for the full dispute period of the
network; route each dispute automatically to the merchant portal with
its deadline.

## 9. PCI DSS scope and security

<!-- Guidance: Show which systems store, process or transmit cardholder data or could affect its security, and how the scope is reduced. PCI DSS v4.0.1 has 12 principal requirements; map your controls to their numbers and keep the wording your own. -->

### 9.1 Scope

| ID | System | Cardholder data | Scope | Reduction measure |
|---|---|---|---|---|
| PCI-001 *(Example)* | PAN vault and tokenisation service | Stores PAN | Cardholder data environment | Dedicated segment, HSM-backed keys |
| PCI-002 *(Example)* | Payment gateway | Processes and transmits PAN | Cardholder data environment | Minimal services, hardened images |
| PCI-003 *(Example)* | Merchant checkout page | Hosts payment fields | Connected or security-impacting | Payment fields in a gateway-hosted iframe, script inventory and change detection |
| PCI-004 *(Example)* | Order management | Gateway tokens only | Out of scope if segmentation is validated | Segmentation tests |

### 9.2 Requirement mapping

| PCI DSS requirement | Topic in brief | Design element |
|---|---|---|
| 1 | Network security controls | Segments and firewall rules for PCI-001, PCI-002 |
| 2 | Secure configurations | Hardened images, no vendor defaults |
| 3 | Protect stored account data | TOK-002 vault, encryption, key management |
| 4 | Protect data in transit over open networks | TLS on every external link |
| 5 | Protect against malicious software | Endpoint protection on in-scope hosts |
| 6 | Secure systems and software | Secure development, payment page script controls |
| 7 | Restrict access by business need | Role-based access |
| 8 | Identify users and authenticate access | MFA for all access into the cardholder data environment |
| 9 | Restrict physical access | Data centre and terminal controls |
| 10 | Log and monitor access | Central logging and review |
| 11 | Test security regularly | Scans, penetration tests, change detection on payment pages |
| 12 | Policies and programmes | Security policy, targeted risk analyses, third-party management |

Official text: PCI Security Standards Council, free download after
accepting the licence: https://www.pcisecuritystandards.org/document_library/.
Scoping method: PCI DSS scoping and segmentation
(`compliance/pci-dss-scoping-segmentation`).

## 10. Clearing, settlement, fees and reconciliation

<!-- Guidance: Describe how captured transactions are cleared, how funds reach the merchant, and how fees are calculated and reconciled. Fee errors are hard to find later; reconcile at transaction level. -->

### 10.1 Fees

In the EEA, Regulation (EU) 2015/751 caps interchange for consumer
debit cards at 0.2 percent and consumer credit cards at 0.3 percent of
the transaction value, with exceptions; check the consolidated text and
national rules.

*Example:* a merchant processes 1,200,000 transactions a month with an
average value of EUR 42.50, so EUR 51,000,000 in volume. Assume
60 percent of value is consumer debit and 40 percent consumer credit,
illustrative network fees of 0.10 percent and an acquirer margin of
0.25 percent.

| Component | Calculation | Amount (EUR) |
|---|---|---|
| Interchange, debit | 51,000,000 x 0.60 x 0.2% | 61,200 |
| Interchange, credit | 51,000,000 x 0.40 x 0.3% | 61,200 |
| Network fees *(Example)* | 51,000,000 x 0.10% | 51,000 |
| Acquirer margin *(Example)* | 51,000,000 x 0.25% | 127,500 |
| Merchant service charge | Sum | 300,900 |
| Blended rate | 300,900 / 51,000,000 | 0.59% |

### 10.2 Reconciliation

| ID | Match | Keys | Frequency | Owner |
|---|---|---|---|---|
| RCN-001 *(Example)* | Captures to network clearing files | Transaction identifier, amount | Daily | Acquiring operations |
| RCN-002 *(Example)* | Network settlement to bank account | Settlement date, total | Daily | Treasury |
| RCN-003 *(Example)* | Merchant payouts to merchant statements | Merchant, batch, fees | Daily | Merchant finance |
| RCN-004 *(Example)* | Interchange and network fees billed to expected | Transaction, fee programme | Monthly | Finance |
| RCN-005 *(Example)* | Chargebacks debited to dispute cases | Case identifier | Daily | Disputes team |

Ledger design: payment ledger design
(`system-design/design-payment-ledger`).

## 11. Non-functional design and operations

<!-- Guidance: Give measurable targets for latency, availability and recovery, and the operational controls for keys, certificates and network releases. Networks publish rule and message changes on a fixed calendar; plan for them. -->

| ID | Area | Requirement | Target | Evidence |
|---|---|---|---|---|
| NFR-001 *(Example)* | Authorisation latency inside the platform | Gateway in to network out | 95th percentile under 300 ms | Performance test |
| NFR-002 *(Example)* | Availability | Authorisation path | 99.99 percent | SLO report |
| NFR-003 *(Example)* | Peak | Authorisations per second | 3 times the busiest hour of the last year | Load test |
| NFR-004 *(Example)* | Recovery | Region failover without lost captures | Under 15 minutes, RPO zero | DR test |
| NFR-005 *(Example)* | Key management | Keys in HSMs, rotation per policy | All keys inventoried | Key ceremony records |

Operational controls: track network release bulletins as recurring work
items; renew certificates for 3-D Secure and network links before
expiry with alerts; and run a stand-in policy for issuer outages agreed
with the networks.

## 12. Testing and certification

<!-- Guidance: List internal tests and the external certifications each network and EMVCo require. Certification slots are limited; book them early. -->

| ID | Test | Scope | Exit criterion |
|---|---|---|---|
| TST-001 *(Example)* | 3-D Secure compliance testing | 3DS Server and SDK versions | EMVCo approvals valid; network testing passed |
| TST-002 *(Example)* | Network certification | Authorisation and clearing messages | Certification letters from each network |
| TST-003 *(Example)* | Exemption engine | EXM-001 to EXM-007 scenarios | Correct flags and outcomes in every scenario |
| TST-004 *(Example)* | Token lifecycle | Reissue, closure, expiry | Stored credentials updated without failed payments |
| TST-005 *(Example)* | PCI DSS assessment | PCI-001 to PCI-004 | Report on compliance or self-assessment accepted |
| TST-006 *(Example)* | Dispute workflow | DSP-001 to DSP-004 | Evidence submitted before deadlines in all test cases |

## 13. Obligations and deadline register

<!-- Guidance: Keep every external version and date that drives the design, with the source and the date you last checked it. -->

| ID | Date or version | Item | Source to check | Last checked |
|---|---|---|---|---|
| DLN-001 | v4.0.1 (June 2024) | PCI DSS version in force; future-dated requirements effective since 31 March 2025 | PCI SSC document library | YYYY-MM-DD |
| DLN-002 | 2.3.1.1 (bulletins of 11 August 2025) | Latest final EMV 3DS version | EMVCo 3-D Secure page | YYYY-MM-DD |
| DLN-003 | 2.4 draft (3 June 2026) | Next EMV 3DS version, comment period closed 1 July 2026 | EMVCo | YYYY-MM-DD |
| DLN-004 | 2019-09-14 | Application of Delegated Regulation (EU) 2018/389 | EUR-Lex, consolidated | YYYY-MM-DD |
| DLN-005 | [Date] | Payment Services Regulation and PSD3 publication and application | EUR-Lex | YYYY-MM-DD |
| DLN-006 | [Date] | Next network rule changes | Network bulletins | YYYY-MM-DD |

## 14. Traceability matrix

<!-- Guidance: Link each driver to design elements and tests. -->

| Driver | Design elements | Tests | Status |
|---|---|---|---|
| DRV-001 | TDS-001 to TDS-004, ARD-001 to ARD-005, EXM-001 to EXM-007, FRD-002 | TST-001, TST-003 | [Open / Passed] |
| DRV-002 | PCI-001 to PCI-004, section 9.2 | TST-005 | [Open / Passed] |
| DRV-003 | TOK-001, TOK-002, section 6 rules | TST-004 | [Open / Passed] |
| DRV-004 | DSP-001 to DSP-004, section 8.2 | TST-006 | [Open / Passed] |

## 15. Glossary and references

<!-- Guidance: Define terms for non-specialist reviewers and list the exact versions used. -->

### 15.1 Glossary

| Term | Meaning |
|---|---|
| Acquirer | Licensed institution that contracts with merchants to accept card payments |
| Interchange | Fee paid by the acquirer to the issuer for each transaction |
| SCA | Strong customer authentication with two independent factors |
| Frictionless | 3-D Secure authentication completed without a cardholder challenge |
| MIT | Merchant-initiated transaction under a prior agreement with the cardholder |
| Network token | Card-network-issued replacement for a PAN, bound to a merchant or device |
| Chargeback | Reversal of a transaction initiated by the issuer under network rules |
| CDE | Cardholder data environment in PCI DSS |

### 15.2 References

| Reference | Version or date | Use |
|---|---|---|
| EMV 3-D Secure Protocol and Core Functions Specification, EMVCo, emvco.com | 2.2.0 to 2.3.1.1; 2.4 draft June 2026 | Section 4 |
| PCI DSS, PCI Security Standards Council | v4.0.1 | Section 9 |
| Directive (EU) 2015/2366 and Commission Delegated Regulation (EU) 2018/389 | Consolidated text, checked YYYY-MM-DD | Section 5 |
| Regulation (EU) 2015/751 on interchange fees | Consolidated text, checked YYYY-MM-DD | Section 10 |
| Network operating rules | [Edition per network] | Sections 6, 8 |

## Standard and licence note

Based on public legal texts (PSD2, Delegated Regulation (EU) 2018/389,
Regulation (EU) 2015/751) and structure aligned with EMV 3-D Secure
(EMVCo) and PCI DSS v4.0.1 (PCI Security Standards Council). Message
names, requirement numbers and article numbers are cited for reference
only; no specification, network rule or legal text is reproduced, and
all descriptions are original text written for this collection.
Official texts: EMVCo specifications at https://www.emvco.com/specifications/
(free download, some documents for subscribers) and PCI DSS at
https://www.pcisecuritystandards.org/document_library/ (free download
under the PCI SSC licence). Card network rules are available from each
network to its licensees. Check the current versions before use. This
is a documentation format, not legal or financial advice; consult a
qualified professional. EMV, 3-D Secure and the network names are
trademarks of their owners; this template is not affiliated with or
endorsed by them. Template licence: MIT.