Returns Setup Flow

## Core Setup

### Customer Entry and Verification

**Settings area:** General/customer experience settings.

The Return Center must be enabled before customers can use the Return Portal. A brand can then configure:

- Customer lookup and verification by phone, email, or either identifier.

- Supported OTP delivery behavior when phone verification is used.

- Brand logo, colors, typography, button style, policy links, support details, and customer-facing notes.

- Whether customers may edit their pickup address and contact details during the request.

- Whether the journey is available normally, under maintenance, or through an authorized presigned entry.

The portal uses the verified identity to find orders. A presigned link may take an authorized customer or staff-assisted journey directly to a specific order, but it does not change the brand's eligibility rules.

**Brand decision:** choose identifiers customers reliably used at checkout. Enabling an identifier that is absent from older orders can increase “order not found” support cases.

### Order and Item Eligibility

**Settings areas:** General settings, Tagging and Restrictions, collection restrictions, SKU restrictions, sale-order restrictions, and discount-code restrictions.

Eligibility is calculated before the customer chooses a resolution. Common controls include:

- Refund and exchange windows measured from delivery.

- A different window for products carrying configured tags.

- Refund-only, exchange-only, replacement-only, or combined capability.

- Partial-quantity returns for multi-quantity line items.

- Whether exchange orders can themselves be returned or exchanged.

- Product collection, product tag, order tag, order-created date, and order-value restrictions.

- Maximum prior exchanges before another refund or exchange is allowed.

- Restrictions for offered discounts or Pragma-generated gift cards.

- SKU-specific rules that can hide an item, block refund or exchange, or disable downstream shipment/refund/exchange processing.

- Uploaded sale-order restrictions for date-bounded, SKU-level exceptions.

- Discount-code rules that can block a resolution, narrow available modes, force exchange, or add a charge.

Eligibility is both order-level and item-level. An order may appear in the portal while only some items or resolutions are available. The customer-facing reason should come from the evaluated policy rather than a generic error.

**Dependency:** tags, collections, SKU values, delivery timestamps, payment state, quantities, and prior requests must be available and consistent in the commerce data.

### Reasons, Evidence, and Consent

**Settings area:** Customer Reasons, Sub-Reasons, Reject Reasons, QC Reasons, and consent settings.

Brands can maintain separate refund and exchange reasons. Each reason can control:

- The customer-facing label and optional sub-reasons.

- Whether a comment is required.

- Minimum photo or video evidence.

- Whether a handling charge applies.

- Whether requests using that reason qualify for automatic approval, refund, or exchange.

- Ordering or visibility in the portal.

Request consent and product-tag consent can show brand-defined text that the customer must acknowledge. Evidence requirements should be limited to what the brand will actually review; asking for media without an operating process increases abandonment without improving decisions.

Reject Reasons and QC Reasons serve different purposes. A Reject Reason explains a brand review decision. A QC Reason records the outcome of inspecting a returned item.

### Refund, Exchange, and Replacement Choices

**Settings areas:** General, Refund, Exchange, and restriction settings.

- A **refund** returns value through an allowed refund method.

- An **exchange** replaces the item with the same variant, another variant, or another product according to catalog, inventory, and price rules.

- A **replacement** supplies a replacement item when the brand permits that resolution, without presenting it as a cash refund.

- A **mixed request** contains different resolutions across its items, such as one refunded item and one exchanged item.

Brands can enable or disable each capability and can restrict customers from mixing resolution types in one request. The portal only shows actions that survive both brand configuration and item-level eligibility.

### Refund Methods

**Settings areas:** Refund settings, Refund Method Rules, and refund-provider configuration.

Refund configuration answers two separate questions:

1. Which method can the customer choose?

2. Which provider or operating process executes that method?

Supported method types include:

- Refund to the original payment source.

- Bank transfer or UPI.

- Payment-link refund.

- Coupon.

- Gift card.

- Store credit, including supported third-party or Shopify store-credit options.

Method visibility can differ for COD, prepaid, and partially paid orders. Refund to source is not applicable to a fully COD order. A partially paid order may require source refund for the prepaid portion and a configured secondary method for the remaining COD portion.

Bank and UPI methods can collect customer details and optionally verify them. Coupon, gift card, and store-credit methods retain value with the brand but require the corresponding generation/provider configuration. A method should not be exposed until its execution path and failure owner are ready.

Brands can also configure editable or pre-approved refund amounts, refund approval, approval verification, restocking behavior, shipping reimbursement, customer notes, offers, and alerts for exceptional refund values.

Manual/offline refund recording is an operator fallback and is not presented as a normal customer-selectable Refund Method Rule.

### Exchange Behavior

**Settings area:** Exchange settings.

Exchange configuration can control:

- Same-variant exchange, another variant of the same product, or any permitted catalog product.

- Product/collection restrictions and customer-facing option labels.

- Inventory locations used when checking exchange availability.

- Whether exchange mapping uses SKU or variant identity.

- Whether a lower-, equal-, or higher-value product can be selected.

- When price differences are waived for the same variant or collection.

- Whether a customer pays a positive difference and whether the brand reimburses a negative difference.

- COD/prepaid treatment, exchange-order value, discount handling, naming, and item price editing.

- Whether exchange orders can later enter another return journey.

- Exchange offers and nudges that encourage exchange instead of refund.

An exchange may use a native commerce-platform exchange when the brand has been onboarded for that supported mode, or create a replacement exchange order. Native exchange is not assumed to be an ordinary self-service toggle. If the customer owes money, order creation can wait for payment. If the brand owes the customer, a reimbursement refund can be created.

**Brand decision:** define inventory and price-difference policy together. Allowing broad product selection without a clear collect/reimburse rule creates requests that cannot be completed automatically.

### Return Addresses and Reverse Shipping

**Settings areas:** Return Shipping, Return Addresses, courier configuration, and warehouse priority.

A **Return Address** is a physical receiving location configured with the identifiers required by connected courier services. One address can be the default. Each address can carry an ordered courier priority list and provider-specific warehouse identifiers.

For merchant-managed pickup, accepted items are assigned to a Return Address. The Return Center can then:

- Group items by Assigned Return Warehouse.

- Apply pincode-level warehouse priorities when configured.

- Map the original Shopify or WMS facility to a return destination for return-to-origin behavior.

- Use the configured multi-location fallback when return-to-origin mapping cannot resolve a destination.

- Use the default Return Address when pincode and return-to-origin routing do not apply.

- Retry through a configured single-location fallback after shipment generation fails for one assigned destination.

- Apply courier rules for request type and single- or multi-item quantity.

- Prefer the forward-shipment courier when configured and eligible.

- Try courier providers in priority order until an AWB is generated or all valid options fail.

An address alone is insufficient: the selected courier must be configured, the destination must carry the expected provider identifier, and the pickup/customer address must be serviceable.

### Notifications and Customer Tracking

**Settings areas:** Active channel/template configuration where available; API/Pragma-assisted webhook configuration.

The customer can track request review, item decisions, reverse-shipment milestones, QC, refund initiation, exchange initiation, payment needs, and available follow-up actions. Because these states can differ by item, brands should use item details rather than treating the request-level status as the entire truth.

Notification events can cover request creation and acceptance/rejection, shipment and pickup milestones, QC, refund methods and completion, exchange creation/payment, self-ship, comments, and feedback journeys. Actual delivery depends on the configured email, SMS, or WhatsApp channel and template.

Operational teams should decide which events are customer-facing and which are better handled through merchant webhooks or internal alerts. Too many overlapping notifications can be as confusing as too few.

## Optional Capabilities

### Customer Self-Shipping

When enabled, the customer can choose to ship the item back rather than wait for a merchant-arranged pickup. The portal shows an allowed Return Address, and the current customer flow requires courier, AWB, tracking link, and shipment proof.

The Return Center records the external reverse shipment and can create a pending shipping reimbursement when the brand supports it. The brand must define who validates the proof, when reimbursement becomes payable, and how a wrong destination or unusable AWB is handled.

### Quality Checks

Quality Check can be recorded per returned item and can gate automated refund or exchange processing. Brands can maintain QC pass/fail reasons and inspect items individually or in bulk.

Do not confuse warehouse QC with a courier's **pickup QC failure**. Warehouse QC evaluates the returned product after receipt. Pickup QC failure is a reverse-shipment event that may prevent the item from being collected.

If automation depends on QC pass, items without a completed passing result remain waiting even when the reverse shipment has been delivered.

### Handling Charges, Offers, and Exchange Incentives

Handling rules can apply charges to refund, exchange, shipping, or selected reasons. Rules may depend on request count, exchange-order count, order/return value, reducing order value, quantity, per-product values, or refund mode.

Brands can also configure refund-mode offers, exchange incentives, and exchange nudges. These change customer economics and must be tested together with tax, discounts, partial quantities, mixed requests, and payment collection.

### Advanced Restrictions and Controlled Bypasses

Advanced restrictions include order/product tags, collections, dates, order value, prior exchange count, discount codes, specific sale orders, SKUs, and offered discounts.

Three controlled exception concepts must remain separate:

- A **Policy Exception Rule** matches configured customer email addresses or discount codes and bypasses only selected restrictions.

- An **Inventory Override** lets an authorized merchant-created flow proceed despite the normal inventory check.

- A **Refund Calculation Override** is a recovery mechanism for cases where the normal commerce-platform calculation cannot be used.

These are not a general “ignore policy” switch. Brands should limit access, define when each is permitted, and preserve an operational reason for its use.

### Multiple Return Warehouses

Multi-warehouse brands can route items using pincode priorities, Origin Facility mappings, an item-selected destination, or a default/fallback Return Address. Each destination can have its own courier provider identifiers and courier priority order.

Test at least one order from every mapped origin and representative customer pincodes. A mapping that points to an address missing from Return Address settings causes shipment generation to fail even when the logical warehouse exists in another system.

### Merchant-Created Requests

Authorized brand staff can find an order and create a Return Request for the customer. The merchant flow supports selecting items and resolutions, refund details, merchant-handled shipping, optional charges, notifications, tags, and an authorized inventory override.

Merchant-created requests are still validated for staff permission, duplicate submissions, order/item identity, quantities, and other server-owned context. They should be used for assisted service or operational exceptions, not as a way to silently rewrite customer history.

### Shopify Return Synchronization

Brands can enable creation of a corresponding native Shopify return for supported Return Center processing. This is separate from simply recording the Return Request in the Return Center and from the onboarded native exchange mode.

Before enabling it, verify which accepted items are synchronized, when restocking occurs, how other refund modes are recorded in Shopify, and which system owns retry when Shopify rejects the operation.

### Cancellation, Partial-Cancellation, and Return-to-Origin Refunds

These merchant-side request types are part of the Return Center even though they do not originate from the normal customer Return Portal journey:

- **Cancellation refund:** refunds an order cancelled before the normal delivered-item return flow.

- **Partial-cancellation refund:** refunds only the cancelled portion of an order.

- **RTO refund:** handles money owed after a shipment returns to origin rather than being delivered to the customer.

They have dedicated dashboard visibility and can use Return Center refund processing, approval, and status tracking. They should be separated in reports from customer-created returns because their eligibility, shipment, and operational cause are different.

## Advanced Integrations and Automations

### Approval and Processing Automations

Automation is configured in layers:

- Global automatic request approval must be enabled.

- The selected customer reason must be allowed for the relevant automatic action.

- Refund and exchange acceptance buffers can delay approval.

- Refund or exchange execution can wait for pickup, delivery, or QC pass.

- Additional processing buffers can delay execution after the trigger.

- Restriction tags/values, order payment mode, pending exchange payment, warehouse mapping, and per-item flags can still block processing.

- A merchant can mark a request to skip automation when manual control is required.

Other optional automations can close completed requests, create WMS return work, restock or mark return states, and refresh payment/refund results. Automation reduces repetitive work only after the manual path and exception owner are proven.

### Shipment Failure Recovery and Non-Pickup Reports

Reverse-shipment failures commonly come from missing Return Addresses, missing courier priority, invalid provider warehouse identifiers, invalid customer contact/address data, non-serviceable pincodes, expired credentials, provider limits, or provider outages.

Recovery tools include:

- Regenerate the AWB.

- Force regeneration or skip the previous courier when configured.

- Try the next courier in the destination's priority list.

- Add or update a manual shipment/AWB.

- Cancel or mark shipment status manually when authorized.

- Use a **Non-Pickup Report (NPR)** for shipments not picked up or cancelled.

- Auto-initiate NPR after the configured non-pickup age threshold.

- Auto-regenerate AWBs after a configured buffer, with a maximum regeneration attempt count.

NPR and AWB regeneration are alternative recovery strategies in the relevant configuration; they should not be enabled as competing responses without validating the intended behavior.

### Warehouse Management Systems

A Warehouse Management System (WMS) is the brand's external operational system for inventory, facilities, receiving, putaway, and warehouse-side return work. The Return Center remains the owner of the customer Return Request while synchronizing selected actions and states to the WMS.

#### Unicommerce

Brands use Unicommerce to coordinate warehouse facilities and return receiving. The integration can support reverse-pickup creation, facility mapping, marking the sale order returned/putaway, exchange-order creation, bundle handling, and order hold/release behavior. Reverse-pickup or return actions may be manual or triggered after configured shipment events.

#### EasyEcom

Brands use EasyEcom to coordinate order/warehouse state and tracking. The integration can support forward and reverse tracking, marking a pending return, marking return completion, facility mapping, and hold/release behavior. Pending-return creation can run after pickup or after delivery, depending on brand policy.

#### Increff

Brands use Increff for warehouse return-management workflows. The integration can create a return in Increff, consume processing updates, and track completion. Return creation can be manual or automated after pickup or delivery.

WMS enablement requires provider onboarding, facility identifiers, event ownership, retry ownership, and test orders. A WMS facility is not automatically a Return Address; it must be mapped to a configured receiving destination where the flow requires one.

### Refund and Payout Providers

Refund method and provider are separate. Depending on method and onboarding, the Return Center can execute or record refunds through the original Shopify transaction, Cashgram/Cashfree, RazorpayX, Easebuzz Wire, Credits Yard, EasyRewardz, Shopify store credit, coupon, gift card, or a controlled manual process.

Provider configuration can include priority and a full-failure action, such as leaving the refund for manual processing or notifying operations. Do not expose a customer refund option until credentials are validated, fallback ownership is defined, and status reconciliation is tested.

### Webhooks and External Notifications

Merchant webhooks can publish lifecycle events such as request created/accepted/rejected/closed, shipment initiated/status updated, QC completed, refund initiated/approved/completed, refund link regenerated, and exchange initiated/completed. Treat webhook enablement as API/Pragma-assisted configuration unless a live merchant settings surface is confirmed for the brand.

Webhooks are for system-to-system coordination and should be idempotent at the receiving side. Customer notifications use separate channel/template configuration. A webhook success does not prove that an email, SMS, or WhatsApp message was delivered.

## Operating the Returns Dashboard

### Work Queues and Filters

The dashboard provides request- and item-focused views, including refunds, exchanges, cancellation/RTO items, pending refunds, bulk uploads, NPRs, exchange payments, open/closed/archived/deleted work, and attention-needed or failure states.

Teams can search by order, request reference, customer contact, AWB, or tags and filter by request, pickup, QC, refund, exchange, reason, method, and time. Saved operating procedures should start from a queue and expected next action rather than “check all requests.”

### Reviewing and Accepting Requests

An operator reviews customer reason/evidence, item eligibility, quantities, requested resolution, charges, refund details, and any existing request history. Items can be accepted or rejected independently, creating a partially accepted request.

Acceptance identifies which items require reverse shipment and confirms or assigns their return destination. Rejecting the request or an item prevents its normal shipment/resolution path but does not erase the audit history.

### Managing Reverse Shipments

After acceptance, the operator can initiate merchant pickup, confirm item-to-warehouse assignment, monitor AWB/status, view pickup images, add manual shipment details, cancel, mark delivered, or regenerate a failed shipment as permitted.

When one request spans multiple destinations, separate reverse shipments may exist. Always troubleshoot the specific item, AWB, and Assigned Return Warehouse rather than assuming one request has one shipment.

### Processing Quality Checks

The item work view supports individual and bulk QC. Record the result and reason only after the warehouse inspection is authoritative. If refund/exchange automation waits for QC pass, a failed or missing QC result keeps the resolution from proceeding automatically.

### Initiating Refunds and Exchanges

Refund operations can initiate a request-, item-, or bundle-level refund, create reimbursement, pre-approve or approve an amount, refresh status, resend a link/notification, regenerate a link, or deactivate a stale refund where supported.

Exchange operations can initiate the exchange, monitor or resend payment, edit an allowed item/price selection, cancel the generated order, convert a return to exchange where supported, and release a held exchange order.

Finance teams should use refund status and provider status together. Returns operators should use exchange generation and exchange-payment status together.

### Finding and Recovering Failures

Use attention/failure queues first, then request history and provider-specific details. Request logs and trace drill-down help distinguish policy blocks, configuration gaps, customer data problems, provider failures, and retryable background work.

| Symptom | Likely area | First checks | Typical recovery |

| --- | --- | --- | --- |

| Customer sees no eligible item | Eligibility | Delivery date, window, tags, collection/SKU/order restrictions, remaining quantity | Correct policy/data or use an approved Policy Exception Rule |

| Customer sees no refund method | Refund rules | Payment type, enabled/visible methods, partial-paid secondary method | Enable a valid method and provider path |

| Request remains pending | Review/automation | Auto-approval flag, reason flag, buffer, skip-automation | Review manually or correct automation settings |

| Shipment cannot be generated | Warehouse/courier | Assigned Return Warehouse, Return Address, provider identifier, priority, serviceability | Correct mapping/config; retry or add manual AWB |

| Pickup is stalled or cancelled | Reverse shipment | Latest courier status and attempt count | NPR, AWB regeneration, alternate courier, or manual follow-up |

| Delivered item does not refund/exchange | Processing trigger | Pickup/delivery/QC trigger, buffer, QC result, payment, skip flag | Complete missing gate or initiate manually |

| Refund is pending/failed | Refund/provider | Approval, customer details, provider status, source refundable amount | Approve, correct details, refresh/retry, or process manually |

| Exchange is waiting | Exchange/payment | Inventory, price delta, customer payment, hold state | Collect/reconcile payment, choose valid product, or release/correct order |

| WMS action failed | WMS | Provider enablement, facility mapping, accepted items, provider response | Correct mapping/config and retry manual or scheduled action |

## Common Brand Use Cases

### Standard Prepaid Refund with Merchant Pickup

Enable prepaid refund to source, configure a default Return Address and courier priority, define refund reasons, and choose manual or automated approval. If resolution waits for delivery or QC, configure that trigger before enabling automatic refund.

### COD Refund by Bank, UPI, or Store Value

Enable only the COD-visible methods the brand can execute. Configure customer detail collection/verification for bank or UPI, or configure coupon/gift card/store-credit generation. Refund to source is not a COD option.

### Same-Product Exchange

Enable exchange and same-product/variant selection, define inventory locations and price rules, then decide whether equal-value differences are waived and whether exchange waits for pickup, delivery, or QC.

### Different-Product Exchange with Price Difference

Enable any-product exchange, catalog/collection boundaries, higher/lower value behavior, payment collection, and reimbursement. Test all three price directions: equal, customer pays, and brand reimburses.

### Customer Self-Ship with Reimbursement

Enable self-ship, choose the Return Address visible to the customer, define required tracking/proof, and establish shipping-reimbursement review and payment ownership.

### QC-Gated High-Risk Return

Require appropriate evidence, keep approval manual if needed, enable warehouse QC, and trigger refund/exchange only after QC pass. Define the action for QC failure; do not leave it as an unspecified terminal state.

### Multi-Warehouse Return-to-Origin

Configure every Return Address, map Origin Facilities, add provider identifiers/courier priorities, and define fallback behavior. Test an order from every origin and a case where no mapping matches.

### WMS-Coordinated Return

Choose Unicommerce, EasyEcom, or Increff according to the brand's warehouse system. Define whether WMS work is created manually, after pickup, or after delivery; map facilities; and establish retry ownership.

### Mixed Refund and Exchange Request

Enable mixed resolution only if operations can track item-level shipment, refund, exchange, payment, and QC state. Test partial acceptance and separate completion timing.

### Merchant-Assisted, Cancellation, Partial-Cancellation, or RTO Refund

Use the appropriate merchant-side request type, preserve the operational cause, and route it through the relevant approval/refund process. Report it separately from standard customer-created returns.

## Configuration Checklist

- [ ] Return Center enabled and branded customer experience reviewed.

- [ ] Phone/email verification works for representative historical orders.

- [ ] Refund, exchange, replacement, and mixed-request policy agreed.

- [ ] Delivery windows, tags, collections, SKU, order-value, date, discount, and exchange-count restrictions tested.

- [ ] Reasons, sub-reasons, comments, evidence, consent, reject reasons, and QC reasons configured.

- [ ] COD, prepaid, and partial-paid refund methods each have at least one valid execution path.

- [ ] Exchange inventory, product scope, price difference, payment, reimbursement, and order behavior tested.

- [ ] Default Return Address exists; all mapped addresses have valid provider identifiers and courier priorities.

- [ ] Self-ship and merchant pickup behavior tested if both are offered.

- [ ] Manual request review, shipment, QC, refund, and exchange paths verified before automation.

- [ ] Automation triggers, buffers, reason flags, exclusions, and skip behavior verified.

- [ ] Notifications/templates and merchant webhooks tested independently.

- [ ] WMS facility mapping and retry ownership verified if a WMS is enabled.

- [ ] Failure queues, request logs, manual recovery, NPR, and AWB regeneration runbooks assigned.

- [ ] Standard prepaid, COD, partial paid, exchange price delta, self-ship, multi-warehouse, failure, and special refund scenarios tested.

## Provider Identifier and Integration Appendix

This appendix records provider identifiers and integration categories present in the current Return Center domain. An identifier does not by itself prove end-to-end availability for every brand; the main guide explains selection behavior without depending on this inventory remaining unchanged.

### WMS Integration Inventory

| Provider | Return Center use |

| --- | --- |

| Unicommerce | Facility mapping, reverse pickup, return completion/putaway, optional exchange-order and hold/release coordination |

| EasyEcom | Forward/reverse tracking, pending/completed return updates, facility mapping, and hold/release coordination |

| Increff | Return creation and warehouse return-processing updates |

### Refund and Store-Value Providers

| Category | Current options |

| --- | --- |

| Original payment source | Shopify/source transaction |

| Payment link or direct payout | Cashgram/Cashfree, RazorpayX, Easebuzz Wire, subject to configured execution mode |

| Store credit | Credits Yard, EasyRewardz, Shopify Store Credit |

| Brand-issued value | Coupon and gift card |

| Controlled fallback | Manual/offline recording |

### Reverse-Shipping Providers

The current provider identifiers include Shiprocket, Delhivery, WareIQ, Bluedart, iThink Logistics, Pickrr, EcomExpress, GoSwift, Shipyaari, Shadowfax, Proship, Smartr, NimbusPost, DTDC, Shipway, ShipEase, SmartShip, Ekart, Vamaship, InTargos, eShipz, XpressBees, Bicree, ShipDelight, ShypBuddy, ClickPost, Shipclues, Shipmozo, Eshopbox, Shiperfecto, Shipfast, Shypfy, Urbane Bolt, RapidShyp, ShipDockets, and configured versioned variants of selected providers.

Provider availability depends on brand onboarding and current integration support. “Customer” or “Other” shipment modes represent self-managed/manual logistics rather than a connected courier integration.

## Glossary

- **Air waybill (AWB):** the shipment identifier used to track a reverse shipment.

- **Assigned Return Warehouse:** the Return Address selected for a specific returned item.

- **Cash on delivery (COD):** an order payment context with no prepaid source transaction for the cash-collected portion.

- **Inventory Override:** an authorized merchant-side choice to proceed despite the normal inventory check.

- **Merchant Returns Operations:** the brand-facing work area and processes for handling Return Requests.

- **Non-Pickup Report (NPR):** follow-up for a shipment that was not picked up or was cancelled.

- **One-time password (OTP):** a short verification code used to authenticate a customer.

- **Origin Facility:** the Shopify/WMS facility associated with original fulfillment.

- **Policy Exception Rule:** a configured email/discount-code rule that bypasses selected restrictions.

- **Quality Check (QC):** inspection result for a returned item; distinct from courier pickup QC failure.

- **Refund Calculation Override:** controlled recovery when normal source calculation cannot be used.

- **Return Address:** configured physical receiving location with shipping-provider identifiers and priorities.

- **Return Center:** the complete brand-configured product for customer returns, exchanges, and replacements.

- **Return Portal:** the customer-facing request and tracking journey.

- **Return Request:** the case grouping returned items and their requested resolutions for one order.

- **Return Request Item:** an item/quantity with its own decision, shipment, QC, and resolution state.

- **Return Resolution:** the refund, exchange, or replacement outcome requested for an item.

- **Return to origin (RTO):** an undelivered forward shipment returned to the brand's origin, which may require a merchant-side refund.

- **Reverse Shipment:** movement of accepted items from customer to the Assigned Return Warehouse.

- **Stock keeping unit (SKU):** the brand/catalog identifier used by item-specific policy and mapping rules.

- **Unified Payments Interface (UPI):** a supported payment address/method for configured customer refunds.

- **Warehouse Management System (WMS):** external system coordinating facilities, inventory, and warehouse return work.