Requirements

Imagine building a payment gateway, much like Razorpay or Stripe, from scratch. This isn't about scaling to millions of transactions or handling complex network infrastructure (that's HLD). Instead, it's about the core object-oriented design: modeling payments, handling different payment methods, processing transactions, and managing webhooks. We'll focus on designing a robust and extensible system that can easily adapt to new payment methods and evolving business rules. The system needs to handle creating payments, processing them via different payment providers, handling asynchronous notifications (webhooks) from those providers, and updating payment statuses accordingly. We will avoid any real third-party integration and focus on simulating the interactions. # Requirements ## Functional Requirements 1. **Payment Creation:** * Allow creating a `Payment` object with specified `amount`, `currency`, `description`, and associated `customer` information. * The `Payment` object should have a unique identifier (`paymentId`). * The `Payment` object must track its `status` (e.g., `CREATED`, `PENDING`, `SUCCESS`, `FAILED`, `REFUNDED`). 2. **Payment Method Handling:** * Support multiple payment methods (e.g., `CREDIT_CARD`, `NET_BANKING`, `UPI`, `WALLET`). * Each payment method should have its specific data requirements (e.g., card number, expiry date for `CREDIT_CARD`; bank account details for `NET_BANKING`). * Implement a mechanism to add new payment methods easily without modifying core classes. 3. **Payment Processing:** * Based on the selected payment method, route the payment to the appropriate `PaymentProcessor`. * Each `PaymentProcessor` should simulate interaction with a third-party payment provider. * The system should simulate success or failure scenarios for payment processing. * Payment processing must be asynchronous. 4. **Webhook Handling:** * Simulate receiving asynchronous webhook notifications from payment providers (e.g., payment success, payment failure). * The system should verify the authenticity of the webhook (simulate verification - no need for real crypto). * Update the `Payment` status based on the webhook notification. * Handle duplicate webhooks gracefully (idempotency). 5. **Refund Processing:** * Initiate refunds for successfully processed payments. * The refund process should also simulate asynchronous behavior and webhook notifications. 6. **Concurrency:** * Handle concurrent payment requests and webhook notifications safely. Prevent race conditions when updating payment statuses. * Assume a multi-threaded environment. ## Non-Functional Requirements 1. **Extensibility:** * The system should be easily extensible to support new payment methods without modifying existing code. Use design patterns to achieve this. 2. **Modularity:** * The system should be composed of loosely coupled modules with well-defined interfaces. 3. **Testability:** * The system should be designed to be easily testable, with clear separation of concerns. 4. **Thread Safety:** * All shared resources (e.g., `Payment` objects, payment processing state) must be accessed in a thread-safe manner to prevent data corruption. * Use appropriate synchronization mechanisms (e.g., locks, atomic variables) to ensure data consistency. 5. **Maintainability:** * The code should be well-documented and easy to understand. * Use meaningful names for classes, methods, and variables. 6. **Idempotency:** Webhook processing should be idempotent. Processing the same webhook multiple times should have the same effect as processing it once. 7. **Error Handling:** The system should handle errors gracefully, including network errors, invalid data, and unexpected responses from payment providers. Simulate error scenarios. ## Core Entities 1. **Payment:** Represents a payment transaction. Contains information like `paymentId`, `amount`, `currency`, `description`, `status`, `customer`, and `paymentMethod`. 2. **Customer:** Represents the customer making the payment. Contains information like `customerId`, `name`, `email`, `address`. 3. **PaymentMethod:** An abstract class or interface representing a payment method. Subclasses/implementations would be `CreditCard`, `NetBanking`, `UPI`, etc. 4. **PaymentProcessor:** An interface representing a payment processor. Implementations would handle specific payment methods (e.g., `CreditCardProcessor`, `NetBankingProcessor`). Uses the Strategy pattern. 5. **WebhookHandler:** Handles incoming webhook notifications from payment providers. 6. **PaymentService:** Orchestrates the payment process, including creating payments, routing to payment processors, and updating payment statuses. 7. **Refund:** Represents a refund transaction.

Design Payment Gateway like Razorpay.

Requirements

Interview Simulation

Functional Requirements

💡 Interview Tip

Non-Functional Requirements

Core Entity Identification

Premium Content