Design a Returnless Refund Flow

Problem statement

Design a returnless refund flow for an e-commerce platform. When a customer requests a return, the system evaluates whether it is cheaper to refund the customer and let them keep, donate, or discard the item instead of paying for a return label, carrier transport, receiving, inspection, and restock. If the item qualifies, the platform issues the refund immediately, marks the item as no-restock, notifies the customer of the resolution, and records the economics for auditing.

Reverse logistics is expensive. Amazon has publicly stated that it has offered returnless refunds since 2017 precisely because for low-value, heavy, bulky, hygienic, or hazardous goods, the return journey costs more than the refund itself. Walmart operates a keep-it refund path inside its self-service returns program. Shopify ships returnless refund rules as a native feature of its Returns product. So this is not a hypothetical interview toy: it is a production pattern with real money behind it.

Why this is more than a payments question

A naive answer designs a refund API. A strong answer recognizes four coupled subsystems:

1. Decision engine. Given item attributes (price, weight, category, condition), order attributes (marketplace seller vs first-party), customer attributes (return history, risk score), and current logistics cost curves, decide return vs returnless, and full vs partial refund. This decision must be explainable and versioned because finance and customer service will be asked about it later.
2. Money movement. Refunds run against a payment gateway or marketplace seller balance. They are asynchronous, can fail, can duplicate on retry, and must reconcile against the payment provider's settlement file. This is an idempotent saga, not a function call.
3. Inventory and disposition. A returnless item must never re-enter sellable inventory. The catalog item remains sellable, but this specific unit is flagged DISPOSED_NO_RETURN, and warehouse receiving must reject any parcel that arrives anyway.
4. Fraud and abuse. Returnless refunds are a free-money vector. The system needs velocity checks, device and account signals, and feedback loops so policy thresholds adapt when abuse patterns emerge.

The core invariant

State this in the first two minutes: a customer must never receive two refunds for the same return claim, and a refund must never be issued without a durable eligibility decision that names the exact policy version used. Everything else — latency, fan-out, dashboards — is negotiable. Double refunds and unexplained money loss are not.

Design assumptions for this answer

All uncited numbers below are explicit design assumptions for a mid-size marketplace:

• 2,000,000 return requests per day across all channels.
• 10% (200,000/day) are eligible for returnless under policy; average refund value $14.
• Peak multiplier 10× on the day after major sale events; assume 800 refund requests/second at absolute peak.
• Eligibility decision budget: p95 under 300 ms.
• Refund issuance budget: asynchronous, customer-visible acknowledgement under 2 seconds, money movement under 5 minutes for instant-capable rails, reconciliation within 24 hours.

The three planes

1. Decision plane — policy rules, eligibility evaluation, cost modeling, risk scoring.
2. Execution plane — refund saga, payment integration, idempotency, reconciliation.
3. Governance plane — fraud monitoring, policy versioning, finance reporting, support tooling.

A credible interview keeps these planes separate so that the decision plane can change thresholds without redeploying the execution plane, and so that a fraud spike throttles new returnless grants without pausing ordinary returns.