---
title: "Refunds"
canonical: "https://red-ant-documentation.refined.site/space/RET/1396375564/Refunds"
format: markdown
---
> Macro (toc)

## Overview

RetailOS provides a flexible and intuitive refund management process to support seamless handling of customer returns. Refunds can be initiated for any order where payment has been collected. 

There are two types of refunds supported:

- **Referenced Refunds:** Refunds initiated directly from an existing order.
- **Unreferenced Refunds:** Refunds initiated without an existing order, allowing sales associates to look up products manually and process them as returns.

### Referenced Refunds

#### Initiating a Referenced Refund

Refunds are initiated from within the order details. Sales associates can select the 'Refund' option and specify whether they are refunding the entire order or individual items. Once the items for refund have been selected:

- A new order is created in the '**Refund In Progress**' status.
- The refunded items are greyed out in the original order and marked as ‘Returned’ to indicate they are part of an ongoing refund process.
- The sales associate is navigated to the **Refund Payments** screen to complete the process.

> ℹ️ The option to ‘Refund’ is available for orders in the following statuses - ‘Partially Paid’, ‘Deposit Paid’, and ‘Complete’.

> ⚠️ For orders with a status of **‘Partially Paid’ **or **‘Deposit Paid,**’ the platform enforces a full refund. This ensures that the entire amount paid by the customer is refunded, preventing situations where a partial refund might result in an outstanding balance still owed to the customer.

##### Refund Payment Screen

The Refund Payments screen facilitates the accurate processing of refunds and is divided into three key sections:

**1. Refund Summary**

- Displays the **Total Amount to Refund**: The sum of the selected items to be refunded.
- Displays the **Amount Refunded**: Updates dynamically as refund amounts are added or removed during processing.

**2. Order Payments**

- Provides a detailed breakdown of payments from the original order, including:
  - **Tendered Amounts**: The amounts paid.
  - **Payment Methods**: The methods used for each payment.
  - **Payment Dates**: The date(s) payments were collected.
- This provides the sales associates with a reference the original payment details when determining how to process the refund.

**3. Refund Payment Block**

- Similar to the payment process during checkout, refund payment blocks allow flexible refund management.
- Each refund payment block is used to capture a specific refund amount against the order.
- Sales associates can use multiple refund payment blocks to process refunds across different payment methods if needed.

##### Adding Refunds

**Refund** **payment blocks** are used to capture each refund against an order. Key functionalities include:

- **Default Refund Payment Block:** Upon landing on the refund payment screen, a single refund payment block is expanded with a default tender type (typically card, configurable based on retailer preferences). The refund payment amount defaults to the total value of the refund but can be adjusted by the sales associate.
- **Updating Refund Summary:** As refunds are added, the **Amount Refunded **field in the refund summary is dynamically updated.
- **Mandatory Information:** Refunds can only be added once all mandatory information (e.g., tender type and refund amount) is captured.
- **Partially Paid Orders:** After the first refund is added, the refund order transitions to the ‘**Refund Partially Processed’** status. The refund payment block then collapses to display the tender type, refund amount, and an option to remove the refund (if allowed - see below for more detail).
- **Adding Additional Refunds:** If the refund does not cover the full refund total, another refund payment block is automatically added, expanded, and pre-filled with the same tender type and the outstanding amount refund. These defaults can be adjusted by the sales associate. Once the full refund total is covered, no additional refund payment blocks are added, preventing further refunds.

> ℹ️ More information on the supported tender types and the available configurations can be found [here](https://redantdigital.atlassian.net/wiki/spaces/RET/pages/1362395137/POS+Payments#Tender-Types).

##### Removing Refunds

Sales associates have the flexibility to **remove refunds** that have been added on the refund payments screen. This allows for corrective action in cases where refunds were added in error.

**Removal Conditions:**

- Refunds made using **manually processed tender types** (e.g., cash or non-integrated payments) can be removed directly from the refund payments screen.
- Refunds made through **integrated tender types** (e.g., card payments processed via RetailOS) cannot be removed because the fund transfer process is initiated upon confirmation.

This functionality strikes a balance between flexibility for manual corrections and maintaining compliance and accuracy for integrated payment refunds.

##### Close Refund

During the refund process, RetailOS provides a **Close** option on the refund payments screen. This option is always available and allows sales associates to exit the refund payments step quickly and return to the associated order details.

When the refund payments step is closed:

- The **order status** at the point of closing is preserved.
- Sales associates can resume the refund payment process later without losing any progress or payment information.

This functionality ensures flexibility during the checkout process, allowing users to handle other tasks while maintaining the integrity of the refund.

##### Completing the Refund

To finalise a refund, the sales associate must capture the total amount to be refunded. Once this is achieved, the **'Confirm'** option becomes available.

**Refund Completion Workflow**

1. **Confirming the Refund**:
  - When the sales associate selects **'Confirm'**, the system processes the refund and updates the order status:
    - **Partially Refunded**: If only a portion of the products from the original order were refunded.
    - **Fully Refunded**: If all products from the original order were refunded.
2. **Post-Refund Updates**:
  - The **Refund Payments** screen is closed, and the user is redirected to the refund order details page.
  - The refund order details page displays:
    - The refunded products.
    - A detailed breakdown of refund transactions, including:
      - Each tender type refunded to.
      - The amount refunded per tender type.
      - The date each refund was processed.

> ℹ️ After refunding an order, all sales-based metrics are re-calculated and re-attributed accordingly within [Retail Analytics](https://redantdigital.atlassian.net/wiki/spaces/~162819045/pages/33849345), [Client Book](https://redantdigital.atlassian.net/wiki/spaces/RET/pages/380141650), and [full customer profile](https://redantdigital.atlassian.net/wiki/spaces/RET/pages/378503561).

---

### Unreferenced Refunds

#### Initiating an Unreferenced Refund

Unreferenced refunds allow sales associates to process returns for customers who do not have an order record in the system (e.g. walk-in customers). To initiate:

1. The sales associate looks up the product the customer wishes to return in the catalog and adds it to the basket.
2. Next to the product in the basket is an option to **Refund** this product.
3. When selected, this updates the basket, marking the product price as a negative amount to reflect the return value.

##### Checkout & Completion

Once all products to be returned are added:

1. Proceed to **Checkout**.
2. The sales associate can either assign the refund to an existing customer or process the refund anonymously.
3. The sales associate can adjust the unit price at this stage — useful in cases where the product was sold at a different price originally.
4. Once the refund order is prepared, the sales associate can select the **Refund Paymen**t option.
5. The **Refund Payment** screen is then displayed, allowing the sales associate to issue the refund using the same flexible tender process described for referenced refunds.

##### Completing the Refund

Once the required amount has been refunded and the sales associate selects **Confirm**:

- A new order is created with a status of **Fully Refunded**.
- The refund order details page displays:
  - The refunded product(s).
  - A detailed breakdown of refund transactions, including:
    - Each tender type refunded to.
    - The amount refunded per tender type.
    - The date each refund was processed.

---

### Order Status Transition

**Return Status**

| **Status** | **Description** | **Action(s)** |
| --- | --- | --- |
| Refund In Progress | The refund process is initiated, but no refunds have been captured. | - **Continue: **Returns to the payment refund.
- **Cancel: **Marks the refund order as ‘Cancelled’ |
| Refund Partially Processed | At least one refund amount has been added but the full refund amount has not yet been completed. | - **Continue: **Returns to the payment refund with previously added refunds. |
| Partially Refunded | A portion of the original order value has been refunded, typically where only a subset of items from the order are being returned. | - **Receipt: **Print a physical receipt or trigger an e-receipt |
| Fully Refunded | All items in the original order have been refunded, resulting in the full order value being returned. | - **Receipt: **Print a physical receipt or trigger an e-receipt |

### **🔄 Returning Stock During Refunds**

RetailOS includes an optional configuration to automatically return stock to inventory when a refund is processed.

✅ **How it Works:**

- If enabled, when a product is refunded, the system will automatically increase the stock level for the refunded product.
- Stock will only be returned if the product variant has an associated `variantStoreStock` record.
- This ensures accurate stock levels for products available for resale.

**Configuration:**

- This setting is configurable based on the retailer’s operational needs.
  - If not enabled, refunded items will not be automatically returned to stock, and inventory updates will need to be managed externally.