---
title: "POS Payments"
canonical: "https://red-ant-documentation.refined.site/space/RET/1362395137/POS%20Payments"
format: markdown
---
> Macro (toc)
## Overview
The payments functionality in our platform provides a flexible and streamlined approach to managing customer payments. Whether processing full payments, partial payments, or deposits, sales associates can handle transactions directly within the platform, ensuring a seamless checkout experience.
With built-in tools for tracking payment methods, managing multiple tender types, and updating payment statuses, the platform ensures accurate and transparent financial handling. Sales associates can easily capture outstanding balances, view detailed payment breakdowns, and confirm completed transactions, providing clarity for both retailers and customers.
This guide outlines the key steps for processing payments, including capturing payments, viewing payment details, and completing the payment process.
---
### Payments Screen
The Payments Screen is the central interface for sales associates to process and manage customer payments. After confirming the order details with the customer and selecting the **Request Payment** option, the sales associate is navigated to this screen. This step marks the transition from order review to payment collection, ensuring a smooth and efficient checkout process.
#### Payment Summary
The Payment Summary section provides a clear overview of the financial details associated with an order. It is designed to ensure transparency for both sales associates and customers during the checkout process. The summary includes the following fields:
- **Total**
Displays the total value of the order, including all items, taxes, and any additional charges.
- **Minimum Deposit** *(only visible if deposits are enabled for the retailer)*
Shows the minimum payment required at the time of order. This amount is a configurable percentage of the total order value. Retailers can define this percentage as part of enabling the deposits feature
- **Paid**
Reflects the total amount that has been paid against the order so far.
- **Outstanding Balance** *(only visible if deposits are enabled for the retailer)*
Represents the remaining balance to be paid on the order. This value is calculated as:
**Total - Paid Amount**
> 📝 - If deposits are not enabled for the retailer, only the **Total** and **Paid** fields will be shown.
> 📝 - The **Minimum Deposit** and **Outstanding Balance** fields provide flexibility for retailers offering deposit-based payment structures, helping ensure clarity on payment expectations.
---
#### Payment Due Date
The **Payment Due Date** feature is an optional field designed to support retailers who offer partial or deposit payments. It allows sales associates to specify the date by which the customer must pay any outstanding balance. This date is included on the receipt issued to the customer for their records.
**Key Details**
1. **Feature Availability**
- The Payment Due Date field is **optional** which can be enabled based on the needs of the retailer.
- If the feature is activated, it appears on the **Payments** step of the checkout process, regardless of whether a partial or full payment is being captured.
2. **Field Behavior**
- The default value is set to **dd/mm/yyyy** until a date is specified.
- The date is only recorded against the order when the sales associate selects **Close** or **Confirm** on the payment step.
- Once set, the field remains editable:
- If the associate exits the checkout process (e.g., by selecting **Close**) and later continues the payment step, the due date can still be updated.
3. **Restrictions**
- The due date cannot be set in the past
- If edited, the field must be updated to a valid future date.
4. **Storage and Display**
- It is always visible on the **Payments** step of checkout, even if no value has been set yet.
- The due date is stored within the details object of the order for tracking purposes
```
},
"paymentDetailsFormData": {
"paymentDueDate": "2025-01-20"
}
}
```
5. **Customer Records**
- If a Payment Due Date is specified, it is automatically included on the customer’s receipt for reference.
---
#### Tender Types
Out-of-the-box all payments are processed manually - this means that RetailOS is not connected with any third-party payment processors to authorise the payment payments; instead, sales associates are responsible for verifying payment completion externally (e.g., via card terminals, cash drawers, gift card management system etc.) before recording it in the platform.
> 📝 We also offer [integrated payment](https://redantdigital.atlassian.net/wiki/spaces/RET/pages/1362395137/POS+Payments#Integrated-Tender-Types) functionality via **Adyen**, supporting features such as [Pay by Link](https://redantdigital.atlassian.net/wiki/spaces/RET/pages/1524924418), [card payments](https://redantdigital.atlassian.net/wiki/spaces/RET/pages/1486028801), and [gift cards](https://redantdigital.atlassian.net/wiki/spaces/RET/pages/1555365889). However, this requires configuration to connect to the retailer's existing Adyen account.
The platform's flexibility allows for the easy configuration of additional tender types to align with retailer-specific workflows and policies. Each tender type can be tailored with:
- **Additional Fields**: Each tender type can have its own unique set of custom fields to capture details specific to the payment method. For example, these fields can record authorisation codes for manual card payments, the last 4 digits of a gift card, or any other payment-related information required by the retailer.
- **Custom Validation**: Each tender type can include validation rules to enforce correct data entry, such as format checks or mandatory field requirements, reducing errors during checkout.
- **Removal Conditions**: Retailers can specify whether a tender type can be removed after being added to an order, providing control over payment edits and ensuring compliance with business policies.
This configurable approach ensures that the platform can adapt to the retailer's operational needs while maintaining a consistent and efficient payment process.
##### Manual Tender Types
| **Type** | **Sub-Types** | **Sub-Type Behaviours / Data Capture Required** |
| --- | --- | --- |
| [Card (Manual)](https://redantdigital.atlassian.net/wiki/spaces/RET/pages/1486028801/Integrated+Card+Payments+Adyen#Manual-Card-Tender-as-a-Fallback-Option) | - MasterCard
- Visa
- American Express | - Card type (single-select dropdown which includes the following options - MasterCard, Visa, MasterCard and American Express)
- Cardholder Name
- Last 4 digits of the card number
- Card expiry month
- Card expiry year
- Amount*
- Authorisation Code* |
| Cash (Manual) | - | - Amount*
- Cash Received* (used to calculate the change due) |
| Gift Card (Manual) | - | - Last 4 digits of gift card number
- Amount* |
| [Customer Credit on File](https://redantdigital.atlassian.net/wiki/spaces/RET/pages/1447165953) | - | - Available Credit (non-editable)
- Amount* |
##### Integrated Tender Types
| **Type** | **Sub-Types** | **Sub-Type Behaviours / Data Capture Required** |
| --- | --- | --- |
| [Card Payments (Adyen)](https://redantdigital.atlassian.net/wiki/spaces/RET/pages/1486028801) | - | - Amount*
- Payment Device* |
| [Cash (Managed)](https://redantdigital.atlassian.net/wiki/spaces/RET/pages/1726939172) | - | - Amount*
- Cash Received* (used to calculate the change due)
- Payment Device* |
| [Foreign Cash (Managed)](https://redantdigital.atlassian.net/wiki/spaces/RET/pages/1842151429) | - | - Amount (Local Currency)*
- Payment Device*
- Amount in [Selected Currency]* (non-editable)
- Tendered Amount ([Selected Currency])* |
| [Pay By Link (Adyen)](https://redantdigital.atlassian.net/wiki/spaces/RET/pages/1524924418) | - | - Amount* (non-editable as it must cover the full order total) |
| [Gift Card (Adyen/Givex)](https://redantdigital.atlassian.net/wiki/spaces/RET/pages/1555365889) | - | - Gift Card Number* (numerical input - must be between 16-21 characters)
- Amount*
- Payment Device* |
> ℹ️ RetailOS supports the configuration of payment limits for specific tender types. This allows retailers to enforce maximum payment thresholds, such as setting a cash payment limit to comply with regulations like anti-money laundering policies. If a sales associate attempts to exceed the configured limit for a tender type during checkout, the system will prompt them to select an alternative payment method.
---
##### Adding Payments
RetailOS supports flexible payment management through **payment blocks**, which are used to capture each payment against an order. Key functionalities include:
- **Default Payment Block:** Upon landing on the payment screen, a single payment block is expanded with a default tender type (typically card, configurable based on retailer preferences). The payment amount defaults to the total order value but can be adjusted by the sales associate.
- **Updating Payment Summary:** As payments are added, the **Paid** and **Outstanding Balance** fields in the payment summary are dynamically updated.
- **Mandatory Information:** Payments can only be added once all mandatory information (e.g., tender type and amount) is captured.
- **Partially Paid Orders:** After the first payment is added, if it does not meet or exceed the minimum deposit, the order transitions to the **Partially Paid** status. The payment block then collapses to display the tender type, tendered amount, and an option to remove the payment (if allowed - see below for more detail).
- **Adding Additional Payments:** If the payment does not cover the full order total, another payment block is automatically added, expanded, and pre-filled with the same tender type and the outstanding balance. These defaults can be adjusted by the sales associate.
- **Fully Paid Orders:** Once the full order total is covered, no additional payment blocks are added, preventing further payments.
> ℹ️ **Payment Authorisation Code**
> ℹ️
> ℹ️ A **Payment Authorisation Code** is a unique identifier generated during the card payment process. When the retailers EFTPOS system processes the transaction, it checks with the card issuer to confirm the card's validity and ensure sufficient funds are available. If approved, the issuer provides an authorisation code, which is displayed on the EFTPOS terminal.
> ℹ️
> ℹ️ For manual card payments, the sales associate must enter this authorisation code into RetailOS during the **Payment Step**. This ensures the transaction is accurately recorded and compliant with payment requirements. The authorisation code serves as a critical reference to confirm the payment was successfully authorised by the issuer.
---
##### Removing Payments
Sales associates have the flexibility to **remove payments** that have been added on the payments screen. This allows for corrective action in cases where payments were added in error.
**Removal Conditions:**
- Payments made through **manually processed tender types** (e.g., cash or non-integrated payments) can be removed directly from the payments screen.
- Payments made through **integrated tender types** (e.g., [Adyen card payments ](https://redantdigital.atlassian.net/wiki/spaces/RET/pages/1486028801)processed via RetailOS and [credit on file](https://redantdigital.atlassian.net/wiki/spaces/RET/pages/1447165953)) cannot be removed because the funds have already been collected. In these cases, the sales associate must follow the **refund process** to address any mistakes.
This functionality ensures that payment corrections are handled appropriately while maintaining compliance and accurate financial tracking for integrated payments.
##### Payments Error Handling
Total payments are less than the minimum deposit
The option to ‘Complete’ is disabled, and the payment summary shows the amount left to pay.
Total payment amount exceeds the amount left to pay
If the payment amount entered for an individual payment exceeds the amount left to pay, a validation error is shown to prevent the user from adding the payment to the order.
Total payment entered is zero
If the user attempts to add a zero-value payment, a validation error is shown requesting a valid payment amount to be entered.
---
#### Deposits
RetailOS includes a configurable feature that allows retailers to define the minimum deposit amount required for orders, calculated as a percentage of the total order value. This is managed through the environment variable `POS_MINIMUM_DEPOSIT_PERCENTAGE`.
Configuring Deposits
**How It Works**
- The value of `POS_MINIMUM_DEPOSIT_PERCENTAGE` determines the minimum percentage of the order total that must be paid as a deposit.
- This variable accepts numeric values:
- For example, setting the value to `20` means the customer must pay a minimum deposit of 20% of the order total.
- A value of `100` (default) means the customer must pay the full order total upfront, effectively disabling the deposits functionality.
**Default Configuration**
By default, `POS_MINIMUM_DEPOSIT_PERCENTAGE` is set to `100`. This ensures that deposits are disabled unless explicitly configured.
The order status transitions to **"Deposit Paid" **once the minimum deposit has been collected. If payments are later reduced to below the minimum deposit threshold, the order status will automatically revert to **"Partially Paid"**.
The option to '**Confirm'** the order will only become available once the minimum deposit amount has been collected.
> ℹ️ **Deposit Calculation**
> ℹ️
> ℹ️ The minimum deposit amount is calculated as a percentage of the total order value, which includes the cost of the products and any applicable delivery fees. This ensures the deposit amount reflects the full value of the transaction.
---
#### Close Checkout
During the checkout process, RetailOS provides a **Close** option on the payments screen. This option is always available and allows sales associates to exit the payments step quickly and return to the associated order details.
When the payments step is closed:
- The **order status** at the point of closing is preserved.
- Sales associates can resume the checkout 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 order.
> ℹ️ If a payment has been added, upon selecting ‘Close’ the user is displayed an alert informing them that they may need to refund the order.
> ℹ️
> ℹ️ 
---
#### Completing the Payment
To finalise a payment, the sales associate must ensure the total outstanding amount has been tendered. Once this is achieved, the **'Confirm'** option becomes available.
**Payment Completion Workflow**
1. **Confirming the Payment**:
- When the sales associate selects **'Confirm'**, the system processes the payment and updates the order status:
- **Complete**: Once the full payment for the order has been received.
2. **Post-Payment Updates**:
- The **Payment **screen is closed, and the user is redirected to the order details page.
- The order details page displays:
- The products purchased.
- A detailed breakdown of payment transactions, including:
- Each tender type used.
- The amount tendered per tender type.
- The date each payment was collected.
---
#### Order Status Transition
**Payment Status**
| **Status** | **Description** | **Action(s)** |
| --- | --- | --- |
| Draft | The order is created when the sales associate enters checkout from the basket. | - **Resume**: Populates the basket with the contents of the order, preserving previous selections made during checkout.
- **Delete Draft**: Marks the order as 'Void,' removing it from Order Management (but retained in the database). |
| Payment In Progress | The sales associate has progressed to the payment step of checkout. | - **Continue**: Returns to the payment step of checkout with previously added payments.
- **Cancel**: Cancels the payment and order, setting the status to 'Cancelled.' |
| Partially Paid | One or more payments have been collected, but the full order value remains outstanding. | - **Continue**: Returns to the payment step of checkout with previously added payments.
- **Refund**: Process a refund for the order.
- **Receipt: **Print a physical receipt or trigger an e-receipt |
| Deposit Paid | A retailer-defined deposit has been collected, but the remaining balance is still outstanding. | - **Continue**: Returns to the payment step of checkout with previously added payments.
- **Refund**: Process a refund for the order.
- **Receipt: **Print a physical receipt or trigger an e-receipt |
| Complete | The full order value has been collected, and the order is finalised. | - **Reassign**: Assign the order to another sales associate.
- **Refund**: Process a refund for the order.
- **Exchange: **Process an exchange on the order.
- **Receipt: **Print a physical receipt or trigger an e-receipt |
> ℹ️ Information on the return status transition can be found [here](https://redantdigital.atlassian.net/wiki/spaces/RET/pages/1396375564/Refunds#Order-Status-Transition).
### **📦 Stock Management During Checkout**
By default, stock levels in** **`variantStoreStock`** **are not managed by RetailOS. Instead, these are often maintained through client-side integrations. However, we offer an optional configuratio**n **for securing and decrementing stock during the checkout process.
#### **✅ How Stock Decrementing Works**
- When enabled, stock is decremented upon entering the payments step of checkout, as the order transitions from 'Draft' to 'Payment in Progress'.
- We only decrement stock for products that have the following flag set within the product's details:
`{ "decrementStock": true } `
- This allows flexibility, ensuring only physical products with actual inventory are tracked. Non-stocked items (like services) can be excluded from stock tracking by omitting this flag.
---
#### **🔄 Handling Cancellations and Refunds**
- Order Cancellations: If an order is cancelled before payment is taken, the decremented stock can be automatically returned to inventory.
- Refunds: When processing a refund, stock can also be [optionally returned](https://redantdigital.atlassian.net/wiki/spaces/RET/pages/1396375564/Refunds#Returning-Stock-During-Refunds) to inventory if this configuration is enabled.
---
#### **📉 Negative Stock Levels**
- If required, we can **allow stock levels to go into negative values**.
- This is useful for providing better **visibility into overselling**, helping retailers identify discrepancies between recorded and actual stock levels.