Payment Gateway Architecture: System Design Questions from Stripe and PayPal

Problem Statement

Payment gateway system design questions have become prevalent in FinTech engineering interviews at companies like Stripe, PayPal, Razorpay, and Square. Engineers often struggle with handling the complex interplay between synchronous user experience and asynchronous processing requirements while maintaining PCI compliance and addressing specific technical challenges that come up in real interviews.

Solution Overview

A robust payment gateway architecture balances immediate user feedback with reliable transaction processing through separation of concerns. The optimal approach uses a request-response pattern for customer-facing operations coupled with asynchronous event-driven processing for settlement, reconciliation, and notification workflows.

This architecture handles both synchronous card authorization and asynchronous settlement processes. The tokenization service (highlighted in orange) ensures sensitive card data never touches your servers, while the message queue (blue) decouples core payment processing from auxiliary services like notifications and analytics. The payment processor API (purple) represents external services like Stripe or PayPal.

Real Interview Questions & Solutions

Below are actual payment gateway architecture questions asked in Stripe, PayPal, and Razorpay interviews, along with solution approaches that have been successful for candidates.

Stripe Interview Question: "Design a payment gateway that can handle 10,000 transactions per second during peak times"

This is a common question in Stripe's senior engineering interviews. The interviewer typically expects discussion around:

Solution approach:

1. Horizontal scaling with stateless payment services behind a load balancer
2. Database sharding strategy for transaction storage (typically by merchant ID)
3. Read replicas for analytics and reporting queries
4. Caching layer for merchant configurations and payment method tokens
5. Rate limiting design to prevent abuse

One candidate who successfully passed Stripe's interview described implementing an adaptive rate limiting system that would dynamically adjust based on merchant history and traffic patterns, coupled with regional deployment to reduce latency [[1]].

PayPal Interview Question: "How would you design a system to detect and prevent duplicate payment submissions?"

This question tests understanding of idempotency in payment systems:

Solution approach:

1. Implement unique idempotency keys for each payment request
2. Design a fast lookup mechanism (Redis or similar) to check for recent duplicate submissions
3. Include de-duplication at multiple levels:
   • API gateway level for exact duplicates
   • Application level using transaction IDs
   • Database level with unique constraints

A successful implementation mentioned by a PayPal engineer involved using bloom filters for initial fast-path rejection of duplicates, followed by precise checking in a distributed cache [[2]].

Razorpay Interview Question: "Design a reconciliation system that can handle settlement discrepancies across multiple payment processors"

This question explores understanding of payment flows beyond the initial authorization:

Solution approach:

1. Implement daily batch reconciliation jobs for each payment processor
2. Design a normalized data model to compare transactions across different processor formats
3. Create alerting thresholds for discrepancy percentages (typically >0.1% triggers investigation)
4. Implement manual resolution workflows for exceptions
5. Build dashboards showing reconciliation health

A senior engineer who passed this interview described using Kafka streams for continuous reconciliation, allowing for near real-time discrepancy detection instead of traditional batch processing [[3]].

Implementation Details

1. Payment Service Design

The payment service handles the initial payment request and orchestrates the flow:

1interface PaymentRequest {
2  amount: number;
3  currency: string;
4  paymentMethod: {
5    type: 'card' | 'bank_transfer' | 'digital_wallet';
6    data: CardDetails | BankDetails | WalletDetails;
7  };
8  metadata: Record<string, string>;
9}
10
Show full code (37 lines)

Key implementation considerations:

• Validate all inputs with strong typing and schema validation
• Handle currency calculations using a library like big.js to avoid floating-point errors
• Implement proper error handling with specific error codes and messages
• Use distributed tracing for request tracking across services

2. Tokenization Implementation

The most common interview question about payment gateways concerns PCI compliance. Proper tokenization is critical:

1class TokenizationService {
2  async tokenize(cardDetails: CardDetails): Promise<string> {
3    // Direct integration with processor's tokenization API
4    // Example with Stripe:
5    const token = await this.stripeClient.tokens.create({
6      card: {
7        number: cardDetails.number,
8        exp_month: cardDetails.expiryMonth,
9        exp_year: cardDetails.expiryYear,
10        cvc: cardDetails.cvc
Show full code (16 lines)

Security considerations:

• Never log complete card numbers, even in error logs
• Encrypt data in transit and at rest
• Implement proper key management and rotation
• Set up network segmentation for PCI compliance

3. Idempotency Implementation

Payment processing must be idempotent to handle retry scenarios:

1class PaymentProcessor {
2  async process(req: PaymentRequest, idempotencyKey: string): Promise<ProcessorResult> {
3    // Check if request with this idempotency key exists
4    const existingTransaction = await this.transactionRepository.findByIdempotencyKey(idempotencyKey);
5    
6    if (existingTransaction) {
7      return this.mapToResult(existingTransaction);
8    }
9    
10    // Process new transaction
Show full code (21 lines)

Implementation considerations:

• Generate idempotency keys on the client side
• Store keys with transaction records
• Set appropriate TTL for idempotency keys
• Handle edge cases like partial failures

4. Reconciliation System

Reconciliation is a crucial part of payment gateway architecture:

1interface TransactionRecord {
2  id: string;
3  amount: number;
4  currency: string;
5  status: 'pending' | 'completed' | 'failed';
6  processorTransactionId: string;
7  createdAt: Date;
8}
9
10class ReconciliationService {
Show full code (32 lines)

Implementation considerations:

• Run reconciliation jobs on a scheduled basis
• Implement alerting for significant discrepancies
• Build dashboard for reconciliation monitoring
• Design efficient query patterns for large transaction volumes

Results & Validation

A well-designed payment gateway architecture delivers significant benefits:

Major financial institutions have implemented similar designs. For example, a leading European banking platform reduced payment processing time by 74% after implementing the decoupled architecture described above, while simultaneously improving fraud detection capabilities [[1]].

This architecture also scales horizontally. During benchmarking tests at a major payment processor, this design maintained sub-500ms response times up to 5,000 transactions per second [[3]].

Architecture Trade-offs

1. Complexity vs. Reliability: The event-driven architecture increases system complexity but significantly improves reliability through decoupling.

2. Operational Overhead: Maintaining multiple specialized services requires more operational resources than a monolithic approach.

3. Latency vs. Consistency: Decoupled processing introduces eventual consistency, which must be properly managed.

Key Takeaways

• Separate synchronous from asynchronous flows: Authorize payments synchronously for immediate user feedback, while handling settlement, notification, and analytics asynchronously.

• Never compromise on security: Implement proper tokenization and ensure PCI compliance by keeping sensitive data out of your systems entirely.

• Design for failure: Payment systems must handle network issues, processor outages, and retry scenarios with proper idempotency guarantees.

• Reconciliation is critical: Build automated reconciliation systems that compare internal records with processor reports to catch discrepancies.

• Consider regional requirements: Payment gateway architectures must adapt to different regulatory environments and payment methods across regions.

Additional Interview Questions to Practice

Technical Implementation Questions

1. "How would you implement 3D Secure authentication while minimizing cart abandonment?" (Square)

   • Implement dynamic risk scoring to selectively apply 3DS
   • Use 3DS v2 with biometric options for smoother verification
   • Implement smart retries with alternate payment methods

2. "Design a payment system that can gracefully handle processor outages." (Stripe)

   • Implement cascading failover between payment processors
   • Design circuit breakers with exponential backoff
   • Create asynchronous retry queues with configurable policies

3. "How would you handle payment authorization and settlement across different timezones?" (PayPal)

   • Always store and process timestamps in UTC
   • Implement timezone-aware settlement windows
   • Design batch processing schedules accounting for banking hours in target regions

System Design Questions

1. "Design a subscription billing system with support for complex pricing models." (Razorpay)

   • Separate pricing engine from payment processing
   • Implement temporal database patterns for historical pricing
   • Design a rule-based engine for complex discounting logic

2. "How would you architect a payment system for an e-commerce platform that operates globally?" (Stripe)

   • Region-specific payment method routing
   • Distributed transaction processing with local acquiring
   • Implement currency conversion with configurable exchange rate sources

3. "Design a chargeback and dispute management system for a payment gateway." (PayPal)

   • Evidence collection and document management system
   • Workflow engine with SLA tracking
   • Case management system with representment templates

References

1. Hughes, D., "Scaling Payment Systems at Stripe," Engineering Blog, 2023. https://stripe.com/blog/scaling-payment-systems

2. Sharma, R., "Building Idempotent Payment Processing at PayPal," Engineering Blog, 2022. https://medium.com/paypal-tech/idempotent-payment-processing

3. Kumar, A., "Real-time Reconciliation Systems at Razorpay," Engineering Blog, 2023. https://engineering.razorpay.com/real-time-reconciliation

4. Martin Fowler, "Idempotency Patterns," 2021. https://martinfowler.com/articles/patterns-of-distributed-systems/idempotent-receiver.html

5. PCI Security Standards Council, "Tokenization Product Security Guidelines," 2022. https://www.pcisecuritystandards.org/document_library

Payment Gateway Architecture Decision Framework

Download our comprehensive framework for designing payment gateway architectures that meet both technical and compliance requirements.

The framework includes:

• Architecture decision templates
• PCI compliance checklists
• Performance benchmarking tools
• Reconciliation system patterns
• Security implementation guidelines

Download Framework →