How to Design Secure VPCs and Connectivity for Issuer and Acquirer Payment Systems on AWS
The Card Payment Flow — What Issuer and Acquirer Infrastructure Actually Does
The issuer and acquirer sides of a card payment transaction have fundamentally different security requirements, different compliance obligations, and different connectivity patterns. Most VPC architectures for payment systems treat them the same. That's the mistake.
An issuer processes transactions against their own cardholder accounts. They hold the card credentials, the account balances, and the authorisation decision. Their primary security concern is protecting cardholder data and ensuring authorisation decisions are accurate, fast, and auditable.
An acquirer processes transactions on behalf of merchants. They don't hold card credentials, they route authorisation requests to card networks and manage settlement with merchants. Their primary security concern is the integrity of the routing path, the security of merchant connectivity, and the prevention of transaction manipulation between merchant and card network.
Same card payment. Completely different attack surface. Completely different VPC design.
This guide covers how to architect secure VPCs and connectivity for both issuer and acquirer payment systems on AWS — including the network segmentation patterns, connectivity requirements, cryptographic infrastructure, and PCI DSS compliance considerations that determine whether your architecture survives both an attack and an audit.
→ Find out what your current payment infrastructure security gaps are costing you — free, 60 seconds Run the free Payment Risk Estimator →
The Card Payment Flow — What Issuer and Acquirer Infrastructure Actually Does
Before VPC design, understand the flow your infrastructure needs to support.
Cardholder
↓
Merchant Terminal / Payment Gateway
↓
Acquirer Processor (your infrastructure if you're an acquirer)
↓
Card Network (Visa / Mastercard / Amex)
↓
Issuer Processor (your infrastructure if you're an issuer)
↓
Authorisation Decision (Approve / Decline)
↑
Same path in reverse — response back to merchant terminal
Timing requirement: The entire round trip, merchant terminal to card network to issuer and back needs to complete in under 2 seconds for a good customer experience. Your VPC architecture needs to be designed for latency, not just security.
What this means for AWS architecture:
The authorisation request is transferred to an Auth Payment Processor VPC for further processing. Authorisation containers handle fraud, risk, velocity, account checks and card type policies. The business validation response is streamed to Kafka, processed, and stored in DynamoDB. The authorisation response then travels back through the card network to the acquiring processor before reaching the merchant terminal.
Every hop in that flow adds latency. Every security control adds latency. The VPC design needs to minimise hops while maximising security which is a harder problem than most teams realise.
The Issuer VPC Architecture
The issuer's infrastructure is the most sensitive in the payment chain. It holds cardholder account data, card credentials, and the logic that decides whether a transaction is approved or declined. A breach of issuer infrastructure is a breach of every cardholder account on that issuer's books.
The Four-Zone VPC Model for Issuers
Zone 1 — Card Network Connectivity (DMZ)
↓
Zone 2 — Authorisation Processing (Private)
↓
Zone 3 — Cardholder Data Store (Isolated)
↓
Zone 4 — Management and Audit (Restricted)
Zone 1 — Card Network Connectivity:
This is your DMZ — the zone that faces the card networks. Traffic arrives here from Visa, Mastercard, Amex via dedicated network connections. Nothing from the public internet should ever reach this zone.
Subnet: 10.0.1.0/24 (Card Network DMZ)
Inbound: Card network dedicated connections only
AWS Direct Connect — dedicated, not shared
No internet gateway
No NAT Gateway inbound
Outbound: Zone 2 only — strict security group rules
Services: API Gateway (private), NLB for card network traffic
The card network connection is not a VPN over the internet. It is a dedicated physical or logical circuit — AWS Direct Connect — between your infrastructure and the card network's processing centre. This is a hard requirement from Visa and Mastercard for issuer connectivity.
Zone 2 — Authorisation Processing:
This is where authorisation decisions are made. It's private no direct internet access — and it has strict controls on what can enter and exit.
Subnet: 10.0.2.0/24 (Auth Processing)
Inbound: Zone 1 only (card network requests)
No direct access from any other zone
Outbound: Zone 3 (cardholder data lookup)
Zone 4 (audit logging)
Card network response path via Zone 1
Services: ECS Fargate (authorisation containers)
Lambda (fraud and velocity checks)
MSK (Kafka for business validation streaming)
Step Functions (authorisation workflow orchestration)
The authorisation decision needs to complete in under 500ms to leave headroom for the full round trip. Lambda for fraud checks (sub-100ms), ECS Fargate for authorisation logic (predictable latency), MSK for streaming validation — this combination hits the latency target reliably.
Zone 3 — Cardholder Data Store:
This is the most sensitive zone. It holds card credentials, account balances, and transaction history. It has no direct connectivity to any external network it can only be accessed from Zone 2, and only via specific service-level calls.
Subnet: 10.0.3.0/24 (Cardholder Data — Isolated)
Inbound: Zone 2 only — specific Lambda function ARNs
No other inbound access under any circumstances
Outbound: No outbound internet access
VPC endpoints for AWS services only
Services: DynamoDB (transaction state, authorisation results)
RDS Aurora (cardholder account data, encrypted)
AWS Payment Cryptography (PIN validation, cryptographic ops)
KMS (encryption key management)
Secrets Manager (credentials)
The four core services supporting PCI DSS Requirement 1 are VPCs, security groups, VPC network access control lists, and IAM. In Zone 3, all four need to be configured with explicit deny-by-default — no implicit allow anywhere.
Zone 4 — Management and Audit:
All infrastructure management, monitoring, and audit log collection happens here. It's completely separate from the payment processing path — an operator managing infrastructure should never be on the same network path as a live authorisation request.
Subnet: 10.0.4.0/24 (Management — Restricted)
Access: Bastion host with MFA — no direct SSH to payment instances
AWS Systems Manager Session Manager — preferred over bastion
Jump from corporate network via Direct Connect
Outbound: CloudWatch Logs (operational logs — 30 days)
S3 (audit logs — 7 years)
CloudTrail (all API activity)
Services: CloudWatch, X-Ray, Config, CloudTrail
Security Hub (unified security findings)
GuardDuty (threat detection)
→ Assess your VPC zone architecture against PCI DSS Requirement 1 controls Run the free Infrastructure Readiness Score →
The Acquirer VPC Architecture
The acquirer's security challenge is different from the issuer's. The acquirer doesn't hold cardholder credentials but they sit between thousands of merchants and the card networks. The attack surface is the merchant connectivity layer, and the primary risk is transaction manipulation between merchant and card network.
The Acquirer's Three-Zone Model
Zone 1 — Merchant Connectivity (DMZ)
↓
Zone 2 — Transaction Routing (Private)
↓
Zone 3 — Settlement and Reconciliation (Isolated)
Plus a shared management zone equivalent to the issuer's Zone 4.
Zone 1 — Merchant Connectivity:
This zone faces your merchants. Unlike the card network DMZ on the issuer side, this zone has a much larger and more variable attack surface hundreds or thousands of merchants connecting via APIs, payment gateways, and terminals.
Subnet: 10.1.1.0/24 (Merchant DMZ)
Inbound: Internet Gateway for merchant API connections
WAF (mandatory — not optional)
API Gateway with request validation
TLS 1.3 termination
Rate limiting: 1,000 requests/minute per merchant ID
Outbound: Zone 2 only — validated and sanitised requests
Services: API Gateway (public-facing merchant API)
WAF (SQL injection, XSS, custom payment rules)
Cognito or OAuth2 (merchant authentication)
Certificate Manager (TLS certificate management)
WAF rules specifically for acquirer merchant connectivity:
Custom rules (mandatory):
Block requests with PAN patterns in URL parameters
Block requests with CVV patterns in any field
Rate limit per merchant ID (not just per IP)
Geo-restriction if your acquiring licence is jurisdiction-specific
Bot detection for automated fraud attacks
Zone 2 — Transaction Routing:
This is where authorisation requests are formatted, validated, and routed to the appropriate card network. The routing logic is business-critical and security-sensitive, a routing error that sends transactions to the wrong network or a manipulation of routing logic is a direct financial attack vector.
Subnet: 10.1.2.0/24 (Transaction Routing — Private)
Inbound: Zone 1 only — validated merchant requests
Outbound: Card network connectivity (Direct Connect)
Zone 3 (settlement data)
Zone 4 (audit logging)
Services: Lambda (transaction validation and formatting)
Step Functions (routing workflow orchestration)
EventBridge (routing rules and event distribution)
SQS FIFO (ordered transaction queuing)
MSK (high-volume transaction streaming)
The routing logic needs to be versioned, tested, and deployed through a proper change management process. PCI DSS Requirement 6 covers secure development and a change to routing logic that bypasses change management is both a security risk and a compliance finding.
Zone 3 — Settlement and Reconciliation:
Settlement data, what was authorised, what needs to be paid to merchants, what came back from card networks lives here. It's financial data rather than cardholder data, but it's highly sensitive and subject to its own regulatory requirements.
Subnet: 10.1.3.0/24 (Settlement — Isolated)
Inbound: Zone 2 only — settlement records from routing
Card network settlement files (via Direct Connect)
Outbound: No outbound internet
Merchant bank connectivity (Direct Connect or SFTP via VPN)
Services: RDS Aurora (settlement ledger)
S3 (settlement file storage — encrypted)
Athena (reconciliation queries)
Step Functions (reconciliation workflow)
Cryptographic Infrastructure — The Layer Both Issuers and Acquirers Need
Both issuer and acquirer architectures require cryptographic infrastructure for payment operations — PIN validation, card verification, transaction authentication. This is where most self-built solutions either over-engineer (expensive HSM clusters) or under-engineer (software-based crypto that doesn't meet PCI requirements).
AWS Payment Cryptography is a fully managed service that eliminates the complexity of handling payment credentials and cryptographic operations, addressing key pain points for financial institutions and removing the overhead of managing cryptographic infrastructure.
For issuers, AWS Payment Cryptography handles:
PIN validation and PIN block translation
Card verification value (CVV/CVV2) generation and validation
EMV cryptogram verification
Issuer master key management
For acquirers, it handles:
PIN block translation between networks
MAC generation and verification
Working key exchange with card networks
AWS Payment Cryptography VPC endpoint:
Private connectivity — no internet transit
HSM-backed key storage — FIPS 140-2 Level 3
PCI PIN and PCI DSS compliant
No key material ever leaves AWS HSM boundary
The critical configuration: AWS Payment Cryptography VPC endpoints must be configured for private connectivity. Considerations for VPC endpoint configuration are detailed in the user guide. Every cryptographic operation should traverse a VPC endpoint — never the public internet.
→ Check your cryptographic infrastructure and key management architecture Run the free Agentic Readiness Assessment →
Card Network Connectivity — Direct Connect Architecture
Both issuers and acquirers need dedicated, private connectivity to card networks. This is not optional and it is not achievable over the public internet.
The Direct Connect architecture:
Card Network (Visa/Mastercard/Amex)
↓
AWS Direct Connect Location
↓
AWS Direct Connect Gateway
↓
Virtual Private Gateway
↓
Your Payment VPC (Zone 1 — DMZ)
Configuration requirements:
Connection type: Dedicated (not hosted) for PCI compliance
Bandwidth: Size for peak + 50% headroom
(authorisation: typically 1-10 Gbps for scale)
Redundancy: Two Direct Connect connections
Different physical locations
Active-active, not active-passive
Encryption: MACsec for Direct Connect (Layer 2 encryption)
TLS 1.3 at application layer regardless
BGP authentication: MD5 authentication on all BGP sessions
The redundancy requirement:
A single Direct Connect connection is a single point of failure for your entire payment operation. If it goes down, you cannot process card transactions. Two connections from different physical locations , AWS Direct Connect Locations — with active-active routing is the minimum for production issuer or acquirer infrastructure.
Cost reality: Two dedicated 1Gbps Direct Connect connections costs approximately £1,500-3,000/month in AWS charges plus colocation costs at the Direct Connect location. This is not optional cost. It's the price of operating in the card payment ecosystem.
Security Group Architecture — Explicit Deny at Every Layer
Security groups are your primary network-level access control mechanism. The default stance must be explicit deny — no implicit allow anywhere in the payment VPC.
Security group hierarchy for issuer architecture:
sg-card-network-inbound:
Inbound: TCP 443 from card network IP ranges only
TCP 8443 from card network IP ranges only
Outbound: sg-auth-processing (TCP 8080)
sg-auth-processing:
Inbound: sg-card-network-inbound (TCP 8080)
Outbound: sg-cardholder-data (TCP 5432, 8000)
sg-audit-logging (TCP 443)
sg-cardholder-data:
Inbound: sg-auth-processing (TCP 5432, 8000)
Outbound: VPC endpoints only (no security group — endpoint policy)
sg-management:
Inbound: Corporate IP range via Direct Connect (TCP 443, 22)
Outbound: All zones for management operations (TCP 443)
The rule you must never have:
# This is a PCI DSS finding
Inbound: 0.0.0.0/0 (all traffic)
Any security group with 0.0.0.0/0 inbound in a PCI CDE is an immediate audit finding. AWS Config rule restricted-common-ports catches this — but you need that Config rule active and alerting continuously, not just checked at audit time.
VPC Flow Logs — The Audit Trail for Network Traffic
VPC Flow Logs are mandatory for PCI DSS Requirement 10. They provide the network-level audit trail that tells you what traffic actually traversed your VPC — not just what was permitted by your security groups.
Flow log configuration:
Enable on all VPCs — not just the CDE VPC
Enable on all subnets — not just sensitive ones
Log format: custom (include all fields)
Destination: S3 with lifecycle policy
30 days: S3 Standard (active investigation)
1 year: S3 Infrequent Access
7 years: S3 Glacier (PCI retention requirement)
Aggregation: 1-minute intervals (not 10-minute default)
The query you need to be able to answer:
"Show me all traffic that accessed the cardholder data subnet on March 15th between 14:00 and 16:00."
With properly configured VPC Flow Logs in Athena:
SELECT sourceaddress, destinationaddress,
sourceport, destinationport, action, bytes
FROM vpc_flow_logs
WHERE destinationaddress LIKE '10.0.3.%'
AND start BETWEEN 1742040000 AND 1742047200
ORDER BY start;
If you can't answer that query in under 60 seconds, your audit trail isn't fit for purpose.
The Common VPC Design Mistakes in Payment Systems
Mistake 1: Shared VPCs for issuer and acquirer functions
Running issuer and acquirer workloads in the same VPC creates a compliance scope problem — the controls required for issuer cardholder data storage apply to the entire VPC, including acquirer functions that don't need them. Separate VPCs, separate accounts.
Mistake 2: Internet Gateway in the CDE VPC
An Internet Gateway attached to a VPC that contains cardholder data means internet-routable paths potentially exist to that data. Even if your security groups prevent actual access, the presence of an IGW expands your PCI scope and creates audit findings. Use VPC endpoints for AWS service access and Direct Connect for card network connectivity. No IGW in the CDE VPC.
Mistake 3: Shared security groups across payment zones
A security group shared between Zone 2 (auth processing) and Zone 3 (cardholder data) means a compromise of Zone 2 has direct network access to Zone 3. Each zone needs its own security groups with explicit rules permitting only the specific traffic that zone requires.
Mistake 4: VPN over internet for card network connectivity
A site-to-site VPN over the public internet for card network connectivity fails the dedicated connectivity requirement for PCI-compliant issuer and acquirer infrastructure. Direct Connect only.
Mistake 5: Insufficient flow log retention
Keeping VPC Flow Logs for 30 days in CloudWatch and then deleting them fails the PCI DSS 1-year online retention requirement. Archive to S3 after 30 days. Keep for 7 years minimum.
The Infrastructure Readiness Checklist for Issuer and Acquirer VPCs
Before going live with issuer or acquirer payment processing on AWS:
Network segmentation:
[ ] Issuer CDE in separate VPC from all non-CDE workloads
[ ] Acquirer CDE in separate AWS account from issuer functions
[ ] No internet gateway attached to any CDE VPC
[ ] All inter-zone traffic controlled by explicit security group rules
[ ] VPC endpoints for all AWS service access from CDE subnets
Card network connectivity:
[ ] Dedicated Direct Connect connections — minimum two, different locations
[ ] Active-active routing — no single point of failure
[ ] MACsec encryption on Direct Connect connections
[ ] BGP MD5 authentication on all BGP sessions
[ ] Card network IP ranges explicitly defined in security groups
Cryptographic infrastructure:
[ ] AWS Payment Cryptography via VPC endpoint — no public internet
[ ] HSM-backed key storage for all payment cryptographic operations
[ ] Key rotation schedule documented and automated
[ ] No software-based cryptography for PIN or card verification operations
Audit and monitoring:
[ ] VPC Flow Logs enabled on all subnets — 1-minute aggregation
[ ] Flow logs archived to S3 with 7-year lifecycle policy
[ ] CloudTrail enabled in all regions — including regions with no active workloads
[ ] AWS Config rules continuously monitoring for security group violations
[ ] GuardDuty enabled for threat detection across all payment accounts
PCI DSS compliance:
[ ] All 63 PCI DSS v4.0.1 controls mapped to your specific VPC architecture
[ ] Continuous drift detection — not point-in-time assessment
[ ] Segmentation testing scheduled every six months
[ ] Architecture Decision Records documenting all connectivity and security decisions
Check Your Architecture Before It Goes Live
The VPC design decisions you make before your first live transaction determine your PCI DSS compliance posture, your security resilience, and your ability to answer a regulator's questions with confidence.
Free — no login required:
Run the free Infrastructure Readiness Score → Assess your VPC and network architecture against PCI DSS 4.0 requirements. Find your gaps before your QSA does.
Run the free Agentic Readiness Assessment → 21 questions across security, compliance, connectivity, and observability. Scored gap analysis in 15 minutes.
Calculate Your Payment Infrastructure Risk → 60 seconds. Quantifies your monthly risk exposure based on your payment service count.
Need architecture support for issuer or acquirer infrastructure?
Sync Your Cloud gives engineering teams access to 26 purpose-built tools for AWS payment infrastructure — including the full PCI DSS v4.0.1 Gap Analysis with all 63 controls mapped to your specific architecture, the Controls Matrix for issuer and acquirer compliance requirements, the Cardholder Data Flow tool for documenting data movement for auditors and acquirers, and the ADR Manager for connectivity and security decisions.
Connect your AWS account directly for AI-powered analysis of your actual VPC architecture against PCI DSS and payment industry requirements.
Plans from £999/month.
Sync Your Cloud is the infrastructure readiness platform for engineering teams deploying payment systems on AWS. Built on AWS. Validated for payment infrastructure.
