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.
Document control
| 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
1. Scope and drivers
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
| 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
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.
3.2 Transaction states
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
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
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
| 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 |
- Merchant systems hold gateway tokens only; the PAN vault sits in the
smallest possible segment of the cardholder data environment.
- Stored credentials carry the stored-credential indicators required by
the networks, with the first authenticated transaction identifier
kept for later merchant-initiated payments.
- Network token lifecycle events (card reissued, card closed) update
the stored credential automatically.
- Truncated PANs, when shown, follow the PCI DSS masking rule for
display.
7. Fraud and risk controls
| 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
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
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 |
10. Clearing, settlement, fees and reconciliation
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
| 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
| 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
| 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
| 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
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.