###### Common Problems

# Payment System

By [Evan King](https://www.linkedin.com/in/evan-king-40072280/)·Updated Jul 10, 2025·

## Understanding the Problem

**📸 What is [Stripe](https://www.stripe.com/)?**
Payment processing systems like Stripe allow business (referred to throughout this breakdown as merchants) to accept payment from customers, without having to build their own payment processing infrastructure. Customer input their payment details on the merchant's website, and the merchant sends the payment details to Stripe. Stripe then processes the payment and returns the result to the merchant.

### [Functional Requirements](/content/learn/system-design/in-a-hurry/delivery#1-functional-requirements/index.html)

**Core Requirements**

1. Merchants should be able to initiate payment requests (charge a customer for a specific amount).
2. Users should be able to pay for products with credit/debit cards.
3. Merchants should be able to view status updates for payments (e.g., pending, success, failed).

**Below the line (out of scope):**
- Customers should be able to save payment methods for future use.
- Merchants should be able to issue full or partial refunds.
- Merchants should be able to view transaction history and reports.
- Support for alternative payment methods (e.g., bank transfers, digital wallets).
- Handling recurring payments (subscriptions).
- Payouts to merchants.

FIRST QUESTION

What are the non-functional requirements?

### [Non-Functional Requirements](/content/learn/system-design/in-a-hurry/delivery#2-non-functional-requirements/index.html)

Before defining your non-functional requirements in an interview, it's wise to inquire about the scale of the system as this will have a meaningful impact on your design. In this case, we'll be looking at a system handling about 10,000 transactions per second (TPS) at peak load.

## The Set Up

### [Defining the Core Entities](/content/learn/system-design/in-a-hurry/delivery#core-entities-2-minutes/index.html)

### [API or System Interface](/content/learn/system-design/in-a-hurry/delivery#api-or-system-interface-5-minutes/index.html)

## [High-Level Design](/content/learn/system-design/in-a-hurry/delivery#high-level-design-10-15-minutes/index.html)

### 1) Merchants should be able to initiate payment requests

### 2) Users should be able to pay for products with credit/debit cards.

### 3) The system should provide status updates for payments

## [Potential Deep Dives](/content/learn/system-design/in-a-hurry/delivery#deep-dives-10-minutes/index.html)

### 1) The system should be highly secure

### 2) The system should guarantee durability and auditability with no transaction data ever being lost, even in case of failures.

### 3) The system should guarantee transaction safety and financial integrity despite the inherently asynchronous nature of external payment networks

### 4) The system should be scalable to handle high transaction volume (10,000+ TPS)

#### Servers

#### Kafka

#### Database

## Bonus Deep Dives

### 1) How can we expand the design to support Webhooks?

### Final Design

## [What is Expected at Each Level?](/content/blog/the-system-design-interview-what-is-expected-at-each-level/index.html)

### Mid-level

### Senior

### Staff+