Cancellation and refund policy in LLD - System Design Guide

Problem Statement

Users often cancel orders or subscriptions, and without a clear policy, the system may incorrectly process refunds or fail to handle cancellations consistently. This can lead to financial losses, customer dissatisfaction, and disputes due to unclear or inconsistent refund handling.

Solution

Implement a well-defined cancellation and refund policy as part of the system's business logic. This policy enforces rules on when cancellations are allowed, how refunds are calculated, and how to handle partial or full refunds. The system validates cancellation requests against these rules and processes refunds accordingly to ensure fairness and consistency.

Architecture

User Request

(Cancel/Refund)

→Cancellation

↓

Validation

& Rules Check

This diagram shows the flow from a user's cancellation or refund request through the policy engine that validates and applies rules, then processes the refund via the payment gateway.

Trade-offs

✓ Pros

→

Ensures consistent and fair handling of cancellations and refunds.

→

Reduces financial risk by enforcing business rules on refunds.

→

Improves customer trust with transparent and automated refund processing.

→

Simplifies dispute resolution by having clear, codified policies.

✗ Cons

→

Adds complexity to the order management system with additional validation logic.

→

Requires careful maintenance to keep policies up to date with business changes.

→

May delay refund processing if rules are complex or require manual review.

Use when your system handles paid orders or subscriptions with potential cancellations, especially if refund amounts vary by timing or conditions. Recommended for systems with over 1000 transactions daily to automate and scale refund handling.

Avoid if your system only handles free services or non-refundable transactions, or if cancellations are extremely rare (less than 10 per month), where manual handling is simpler.

Real World Examples

Amazon

Amazon enforces cancellation and refund policies that vary by product category and timing, automating refunds only when conditions are met to reduce fraud and errors.

Airbnb

Airbnb uses cancellation policies that define refund eligibility based on how far in advance a booking is canceled, automating partial or full refunds accordingly.

Uber

Uber applies cancellation fees or refunds based on timing and driver status, enforcing policies to balance driver compensation and rider satisfaction.

Code Example

The before code processes refunds without any rules, always refunding full amount if cancelled. The after code introduces a CancellationPolicy class that calculates refunds based on timing, allowing full refunds within 24 hours and partial refunds afterward. This enforces business rules consistently.

LLD

### Before: No policy enforcement, refunds processed directly
class Order:
    def __init__(self, amount):
        self.amount = amount
        self.is_cancelled = False

    def cancel(self):
        self.is_cancelled = True

    def refund(self):
        if self.is_cancelled:
            return self.amount  # Full refund without checks
        return 0


### After: Policy enforced with timing and partial refund rules
from datetime import datetime, timedelta

class CancellationPolicy:
    def __init__(self, full_refund_period_hours, partial_refund_percent):
        self.full_refund_period = timedelta(hours=full_refund_period_hours)
        self.partial_refund_percent = partial_refund_percent

    def calculate_refund(self, order_time, cancel_time, amount):
        if cancel_time - order_time <= self.full_refund_period:
            return amount  # Full refund
        else:
            return amount * self.partial_refund_percent / 100  # Partial refund

class OrderWithPolicy:
    def __init__(self, amount, order_time):
        self.amount = amount
        self.order_time = order_time
        self.is_cancelled = False
        self.cancel_time = None
        self.policy = CancellationPolicy(full_refund_period_hours=24, partial_refund_percent=50)

    def cancel(self, cancel_time):
        self.is_cancelled = True
        self.cancel_time = cancel_time

    def refund(self):
        if not self.is_cancelled:
            return 0
        return self.policy.calculate_refund(self.order_time, self.cancel_time, self.amount)

Alternatives

Manual Refund Processing

Refunds and cancellations are handled manually by customer service agents without automated policy enforcement.

Use when: Choose when transaction volume is low and refund cases are rare, making automation cost-ineffective.

Fixed Refund Policy

A simple policy that always refunds full or no amount without conditional rules or timing considerations.

Use when: Choose when simplicity is prioritized over flexibility, such as for low-value transactions.

Summary

Cancellation and refund policies prevent inconsistent or unfair refund processing.

They enforce business rules to calculate refunds based on timing and conditions.

Automating these policies improves customer trust and reduces financial risk.

Practice

1. What is the primary purpose of a cancellation and refund policy in a system?

easy

A. To define rules for stopping services and returning money

B. To increase the price of products

C. To track user login times

D. To manage database backups

Solution

1. Step 1: Understand the role of cancellation policies

   Cancellation and refund policies set clear rules about when and how users can stop services and get money back.

2. Step 2: Eliminate unrelated options

   Options about pricing, login times, or backups do not relate to cancellation or refunds.

3. Final Answer:

   To define rules for stopping services and returning money -> Option A

4. Quick Check:

   Cancellation policy = service stop rules [OK]

Hint: Cancellation policies define service stop and refund rules [OK]

Common Mistakes:

• Confusing cancellation policy with pricing strategy
• Thinking it manages user authentication
• Assuming it handles technical backups

2. Which of the following is a correct component to include in a cancellation policy data model?

easy

A. login_attempts: int

B. user_password: string

C. product_price: float

D. allowed_cancellation_time: datetime

Solution

1. Step 1: Identify relevant data for cancellation policy

   The allowed cancellation time defines until when a user can cancel and get a refund.

2. Step 2: Exclude unrelated fields

   User password, product price, and login attempts are unrelated to cancellation timing.

3. Final Answer:

   allowed_cancellation_time: datetime -> Option D

4. Quick Check:

   Cancellation policy needs cancellation time [OK]

Hint: Cancellation policy needs allowed cancellation time field [OK]

Common Mistakes:

• Including unrelated user or product fields
• Confusing cancellation time with login data
• Using incorrect data types for time

3. Given this pseudocode for refund calculation:

if cancellation_time <= allowed_cancellation_time:
    refund_amount = full_price
else:
    refund_amount = 0
print(refund_amount)

What will be printed if cancellation_time is after allowed_cancellation_time?

medium

A. Error

B. full_price

C. 0

D. null

Solution

1. Step 1: Analyze the condition

   If cancellation_time is after allowed_cancellation_time, the else branch runs.

2. Step 2: Determine refund amount

   In else, refund_amount is set to 0, so 0 will be printed.

3. Final Answer:

   0 -> Option C

4. Quick Check:

   Late cancellation = zero refund [OK]

Hint: Late cancellations get zero refund [OK]

Common Mistakes:

• Assuming refund is full regardless of time
• Expecting an error due to condition
• Confusing variable names

4. Identify the bug in this refund policy code snippet:

def calculate_refund(cancellation_time, allowed_time, price):
    if cancellation_time > allowed_time:
        refund = price
    else:
        refund = 0
    return refund

medium

A. Price variable is not used

B. Refund is given after allowed time instead of before

C. Function does not return any value

D. Refund is always zero

Solution

1. Step 1: Understand refund logic

   Refund should be given if cancellation_time is before or equal to allowed_time.

2. Step 2: Check condition logic

   Current code gives refund if cancellation_time is after allowed_time, which is incorrect.

3. Final Answer:

   Refund is given after allowed time instead of before -> Option B

4. Quick Check:

   Refund condition reversed = bug [OK]

Hint: Refund condition must check cancellation before allowed time [OK]

Common Mistakes:

• Reversing the refund condition
• Ignoring return statement
• Misusing price variable

5. You are designing a cancellation and refund system for an online booking platform. Which approach best balances user trust and system scalability?

hard

A. Allow partial refund based on how close cancellation is to booking time

B. Allow full refund anytime, no restrictions

C. Allow full refund only if cancellation is made 24 hours before booking time, else no refund

D. Never allow refunds to avoid complexity

Solution

1. Step 1: Consider user trust

   Partial refunds based on cancellation timing show fairness and flexibility, building trust.

2. Step 2: Consider system scalability

   Partial refund rules can be implemented with clear logic and scale well without manual intervention.

3. Step 3: Evaluate other options

   Full refund anytime is costly; no refunds reduce trust; strict cutoff is less flexible.

4. Final Answer:

   Allow partial refund based on how close cancellation is to booking time -> Option A

5. Quick Check:

   Partial refund balances trust and scalability [OK]

Hint: Partial refunds balance fairness and system load best [OK]

Common Mistakes:

• Choosing no refund which harms user trust
• Allowing full refund anytime which is costly
• Using strict cutoff without flexibility