Payment handling in LLD - Interactive Code Practice

Practice - 5 Tasks

1fill in blank

easy

Complete the code to define the main class for payment processing.

LLD

class [1]:
    def __init__(self):
        self.transactions = []

Drag options to blanks, or click blank then click option'

ATransactionManager

BPaymentProcessor

COrderHandler

DUserAccount

Attempts:

3 left

💡 Hint

Common Mistakes

Using unrelated class names like OrderHandler or UserAccount.

The main class handling payments is typically called PaymentProcessor.

2fill in blank

medium

Complete the code to add a method that initiates a payment.

LLD

def [1](self, amount, method):
    # code to start payment
    pass

Drag options to blanks, or click blank then click option'

Ainitiate_payment

Bprocess_order

Ccancel_payment

Drefund_payment

Attempts:

3 left

💡 Hint

Common Mistakes

Using method names like cancel_payment or refund_payment which do not start payments.

The method to start a payment is called initiate_payment.

3fill in blank

hard

Fix the error in the method that validates payment status.

LLD

def validate_status(self, status):
    if status == [1]:
        return True
    return False

Drag options to blanks, or click blank then click option'

A"completed"

Bcompleted

CTrue

D"pending"

Attempts:

3 left

💡 Hint

Common Mistakes

Not using quotes around string literals.

The status should be compared as a string literal, so it must be in quotes: "completed".

4fill in blank

hard

Fill both blanks to create a dictionary comprehension that maps transaction IDs to amounts for successful payments.

LLD

successful_payments = {txn['id']: txn[1] for txn in transactions if txn['status'] [2] 'success'}

Drag options to blanks, or click blank then click option'

A['amount']

B==

C!=

D['status']

Attempts:

3 left

💡 Hint

Common Mistakes

Using wrong dictionary keys or incorrect comparison operators.

The dictionary maps transaction IDs to their amounts, so use ['amount']. The filter checks for status equal to 'success', so use ==.

5fill in blank

hard

Fill all three blanks to create a method that refunds payments over a certain amount and updates their status.

LLD

def refund_large_payments(self, threshold):
    for txn in self.transactions:
        if txn['amount'] [1] threshold:
            self.process_refund(txn[2])
            txn['status'] = [3]

Drag options to blanks, or click blank then click option'

A>

B['id']

C'refunded'

D<=

Attempts:

3 left

💡 Hint

Common Mistakes

Using wrong comparison operators or wrong keys for refund.

The method refunds payments where amount is greater than threshold (>), calls refund with transaction ID (['id']), and sets status to 'refunded'.

Practice

1. What is the primary purpose of a payment handling system in software design?

easy

A. To store user profile pictures

B. To securely process and record financial transactions

C. To manage user login and authentication

D. To display product information to users

Solution

1. Step 1: Understand the role of payment handling

   Payment handling systems focus on managing money transfers safely and reliably.

2. Step 2: Identify the core function

   The core function is to process payments securely and keep records of transactions.

3. Final Answer:

   To securely process and record financial transactions -> Option B

4. Quick Check:

   Payment handling = Secure transaction processing [OK]

Hint: Payment handling means safe money transfer and record keeping [OK]

Common Mistakes:

• Confusing payment handling with user authentication
• Thinking it manages product display
• Assuming it stores user media files

2. Which of the following is the correct sequence of steps in a typical payment processing flow?

easy

A. Notify user -> Record transaction -> Process payment -> Validate payment details

B. Record transaction -> Validate payment details -> Notify user -> Process payment

C. Validate payment details -> Process payment -> Record transaction -> Notify user

D. Process payment -> Notify user -> Validate payment details -> Record transaction

Solution

1. Step 1: Identify logical payment flow order

   First, payment details must be validated to ensure correctness.

2. Step 2: Follow with processing, recording, and notifying

   After validation, payment is processed, transaction recorded, then user notified.

3. Final Answer:

   Validate payment details -> Process payment -> Record transaction -> Notify user -> Option C

4. Quick Check:

   Payment flow = Validate -> Process -> Record -> Notify [OK]

Hint: Payment flows from validation to processing, then record and notify [OK]

Common Mistakes:

• Not validating before processing
• Not recording transaction before notifying
• Mixing notification before processing

3. Consider this simplified payment processing pseudocode:

def process_payment(amount, card_info):
    if not validate_card(card_info):
        return "Invalid card"
    if amount <= 0:
        return "Invalid amount"
    if not charge_card(card_info, amount):
        return "Charge failed"
    record_transaction(card_info, amount)
    return "Payment successful"

What will be the output of process_payment(100, 'expired_card') if validate_card returns False for expired cards?

medium

A. "Invalid card"

B. "Charge failed"

C. "Payment successful"

D. "Invalid amount"

Solution

1. Step 1: Check card validation result

   Since validate_card returns False for expired cards, the first if condition triggers.

2. Step 2: Return error message immediately

   The function returns "Invalid card" without further processing.

3. Final Answer:

   "Invalid card" -> Option A

4. Quick Check:

   Expired card -> validate_card = False -> "Invalid card" [OK]

Hint: If validation fails, function returns error immediately [OK]

Common Mistakes:

• Assuming charge_card runs despite invalid card
• Confusing invalid amount with invalid card
• Expecting success despite validation failure

4. A payment system logs duplicate transactions when retrying failed payments. Which design fix will best prevent this issue?

medium

A. Use unique transaction IDs and check before recording

B. Increase payment timeout duration

C. Remove transaction logging entirely

D. Allow multiple retries without checks

Solution

1. Step 1: Identify cause of duplicate logs

   Retries cause repeated transaction records without uniqueness checks.

2. Step 2: Implement unique transaction IDs and check

   Assign unique IDs and verify before logging to avoid duplicates.

3. Final Answer:

   Use unique transaction IDs and check before recording -> Option A

4. Quick Check:

   Unique IDs prevent duplicate transaction logs [OK]

Hint: Unique IDs stop duplicate transaction records [OK]

Common Mistakes:

• Ignoring duplicate checks on retries
• Removing logging which loses audit trail
• Increasing timeout doesn't fix duplicates

5. You are designing a payment system that must handle 10,000 transactions per second with minimal latency and high reliability. Which architectural approach best supports this requirement?

hard

A. Store all payment requests in a single database table and process sequentially

B. Process all payments synchronously on a single server to ensure order

C. Use client-side scripts to process payments directly without server validation

D. Use a distributed message queue to process payments asynchronously with multiple worker nodes

Solution

1. Step 1: Analyze scalability and latency needs

   Handling 10,000 TPS requires distributing load and minimizing blocking.

2. Step 2: Choose asynchronous distributed processing

   Using a message queue with multiple workers allows parallel processing and reliability.

3. Step 3: Eliminate options causing bottlenecks or insecurity

   Single server or sequential DB processing causes bottlenecks; client-side processing lacks security.

4. Final Answer:

   Use a distributed message queue to process payments asynchronously with multiple worker nodes -> Option D

5. Quick Check:

   High TPS + low latency = distributed async processing [OK]

Hint: Distribute load with async workers for high TPS [OK]

Common Mistakes:

• Using single server causing bottlenecks
• Sequential DB processing slowing throughput
• Relying on client-side payment processing