Refunds
Refund basics
In practice, when a customer requires a refund, store employees can find the order and refund the products by scanning the receipt and the barcodes of the concerned products, respectively.
To offer your customers the utmost convenience, there are various options for configuring your organization on what kinds of refunds to allow—for example, returning online orders in other OUs, which enables customers to visit local stores to return parts from their order - while also giving your store employees a chance to exchange or upsell other products.
What is and isn't allowed when returning and refunding is mainly based on settings. You can find these settings further down this page. How refunds can be done also depends on what payment methods have been configured (since they determine what options are available in your checkout menu) and what payment data is added to any transactions 'pushed' into EVA. For more information, see Non-integrated payment parties.
There are two permissions required for refunds:
- Refunds allows you to create refunds and refund orders in general
- OrderLinePriceCorrection will allow you to refund by changing a unit price
Three types of refunds
When looking at the larger picture of refunds, before the specific refund methods and settings come into play, we can make a distinction between three possible types of refunds:
- Retake with complete refund The standard way of refunding in our POS and Companion: a customer brings in a product which is accepted by the store employee and selected in the corresponding order; the customer is refunded entirely and the selected product either goes back in to the sellable stock or is discarded by the employee (or returned to the supplier).
- Retake with partial refund A customer brings in a product which does not warrant an entire refund, due to obvious wear and tear for example. Once again the product is selected in the corresponding order, but the price of the product can be altered. The product still has to be physically taken in.
- Refund without retake
This option is mostly used by customer service employees, as it can be used to issue a refund without taking in the product in question. It can be used to make up for a shoe's missing laces or even a bad customer experience for example. The Refund without retake can be done in Admin Suite in two ways.
Two flows for refunds without retake
Generally speaking there are two flows for giving a customer a "refund". We use quotation marks here because the first flow is not actually a refund, but it does work out that way for the customer.
Price correction reason
In the first flow we don't mark the product in question as being refunded, but instead we perform a price correction reason on it. By doing so we indicate that this specific product needs to have a lower price, due to damages for example. Any correction after the sale will make the order's total amount negative, and thus lead to a refund for the consumer. Due to the latter, any price correction that leads to a price that's lower than the original amount will require you to enter a refund reason.
The benefit of a price correction over an actual refund, is that an actual refund (with or without retake) is still possible at a later stage. Any refund after a price correction will by default refund no more than the actually paid amount.
The Order history tab in Suite will show any price override along with its original price.
Although price corrections can also be performed in the POS, using them to refund is not possible. The corrections are only possible in the POS before the sale, specifically to prevent using a discount where it is unwelcome from a fiscal point of view.
Creating a return (without retake) order
Only in Suite are you able to select items to refund while indicating the customer can keep the product(s).
All products selected for a refund will be moved to a new return order which will show the order's total negative amount. You can refund the customer straight away by going to the Payments tab and creating a new payment. The total amount will be pre-filled for you.
If you'd go to to the original order, the refunded order lines would show as no longer editable.
Refund methods
We'll start with an overview of the most basic refund options on your checkout screens. Your settings and payment methods influence this, but we'll get to that later.
Auto Refund
This catch-all refund option allows for quick and easy refunding: clicking it will automatically refund all (auto-)refundable transactions attached to this order. An "automatic refund" entails that each specific transaction will be refunded on the same payment method used for that transaction - the original transaction is reversed.
The method is important to this refund because it considers the Refund priority. This means it will prioritize refunding on gift cards, for example. It can be specifically disabled with RequiresInteractionForRefunds in your custom payment type's Options.
All the other refund options will be grouped under Show more as long as Auto Refund is available - see also App:Checkout:HideShowMore. Should only part of the transaction be available for auto refund, we will redirect you to the refund checkout to perform the rest.
Cash, Cards and Custom
- Cash
Choosing this refund method lets you set a certain amount to refund in cash. In principle, this method can be used even when no reference to the original order exists. - Card
The same goes here: set an amount to refund, and the PIN terminal takes over the rest, allowing the customer to choose whichever type of payment card to use. - Bank refund
Although not shown in this overview, the Bank refund option deserves special mention. This option lets you refund a customer on the card used in the order without presenting the actual card. Although this is possible in the 2nd and 3rd refund possibilities below, it differs from them profoundly due to the ability to set a custom refund amount, bypass the refund priority, and go to the card immediately. - Custom
Although not shown in this overview, all kinds of custom refund options are possible. You can configure gift cards for refunds, manual (wire transfer) refunds, or even remove the cash option as a refund.
Refundable payments
The Refundable button will only be shown in case of a reference refund: the original order is known in EVA, giving you a list of all transactions attached to it. You can then select which specific transaction you want to refund. The selected transaction will be refunded automatically.
"Refundable transactions" also implies that not every transaction is refundable. This can be the case for custom payment methods (created via Admin Suite or API), as these can be configured not to allow refunds without an associated original transaction. Note that prohibiting refunds can be configured via payment methods but also via settings. For example, the setting
Refund:DisableRefundsWithoutOriginalTransactionallows you to block refunds for orders without original transactions, even for refund methods such as Cash.
In principle, you can only refund to user card if the original transaction was made by user card. The setting UserCards:AllowRefundsWithoutOriginalTransaction specifically lets you change this limitation. Setting it to true will allow you to refund on a user card regardless of how it was paid originally.
Settings for refunding
Ecom returns to warehouse
Sometimes customers are allowed to return an order to a warehouse directly. Since there are no employees available to manually validate and refund those orders, an automatic refund process needs to be implemented. In principle any online orders returned by mail are automatically refunded on the payment method used by the customer originally.
Open to view warehouse returns settings
| Settings | Description |
|---|---|
| CRM:Refund:AutoRefundOnReturn | This will automatically trigger a refund when the return order is completed. |
Cancellations
Cancellations require two extra settings. Cancellations mean that an order, or a specific order line, is cancelled by an employee or customer before any shipping is done. As soon as shipping is done, an invoice is created and cancellation is no longer possible.
In that case, refunds should be done automatically.
Open to view cancellations settings
| Settings | Description |
|---|---|
| AllowRefundsOnPaidOrders | Allowing refunds on orders that have been paid, but not yet shipped. |
| CRM:Refund:AutoRefundOnReturn | This will automatically trigger a refund when the return order is completed. |
| AutoCancelNonShippedLinesOnFinalShipment | Will cancel any remaining order lines after final shipping. |
| Orders:Shipment:RefundOpenAmountAfterShipment s | After the final shipping has been done and there are remaining (cancelled) order lines, they will be refunded automatically. |
Overview returns settings
Here you can find an entire overview of all settings related to returns and refunds, including printing of receipts.
Open to view the complete refund settings overview
| Setting | Description |
|---|---|
| CRM:Refund:AutoRefundOnReturn | Whether or not to automatically trigger a refund when completing a return order (when it's received in warehouse). |
| CRM:Refund:AutoReturnGiftWrappingCosts | Whether or not to automatically refund wrapping costs on returns. |
| CRM:Return:RequiresOrderSecurityCode | Enalbing this will add an additional security layer to returns, making returns possible only when a receipt/invoice is scanned. |
| CRM:Refund:AutoReturnShippingCosts | Whether or not to automatically refund shipping costs on returns. |
| CRM:Return:AutoPlaceOnReturn | Determines whether PlaceOrder is called automatically after creating the return. Defaults to false. (Exporting the order warehouse could be an outcome of auto placement.) |
| CRM:Return:RequireEmployeeVerification | Whether or not creating returns requires employee verification. Defaults to false. |
| OrderMaxLinesToReturn | Set a maximum amount of order lines allowed to be returned. |
| Orders:Lines:UnitPriceCorrections:OnlyOnManualReturnLines | Whether or not to allow OrderLine price corrections on normal (positive) lines or only on manual return lines. Defaults to false, allowing price corrections on normal lines as well as return lines. |
| Orders:Cancellations:RefundOpenAmountAfterPartialCancellation | when set to true, this setting refunds automatic after an orderline is partial cancelled. |
| Orders:Returns:DefaultExporter | Determines which exporter is used to export the return order to an external system. |
| Orders:Returns:DenyInNonShipFromShop | Disallow orders to be returned in a shop the order wasn't sold from. |
| Orders:Returns:DenyReturnsInNonReturnOrganizationUnit | Disallow orders to be returned in a shop other than the Return OU of the fulfilment OU - this only applies a return OU is set. |
| Orders:Shipment:RefundOpenAmountAfterShipment | Whether or not to trigger a refund of any open remaining amount on the order after shipping a delivery order. |
| AutoCancelNonShippedLines | Shipping an order partially will then trigger cancellations for the remaining lines that we not in the ship message |
| RefundAfterReservationOrderLineCancelled | when set to true, this setting refunds automatic after an orderline is cancelled. |
| AutoCancelNonShippedLinesOnFinalShipment | Will cancel any remaining order lines after final shipping. (Final shipment flag 'true' on the ShipExternalOrderservice.) |
| AutoCancelShippingCostsWhenOrderIsFullyCancelled | when set to true, this setting will ensure the shipping costs are also cancelled when an order is fully cancelled. |
| CanCancelPlacedBundleLines | Whether or not users are allowed to cancel bundle lines |
| OrderFulfillment:AllowPartialCancellation | Whether or not it is allowed to partially cancel orders |
| OrderLineCancelled:Mail:Timeout | Time in seconds before a cancellation e-mail is sent out after cancellation |
| OrderLineCancelled:RequestExternalCancellations | Since the order is external at that point, we need confirmation of that warehouse system if they took the items out of their logistics process. You can disable those requests with this setting |
| Orders:Cancellations:RefundOpenAmountAfterCompleteCancellation | Whether or not the open order amount should automatically be refunded when an order has been cancelled completely |
| Orders:Shipment:Receipt:CancelDeficiencies | Partially receiving goods, so missing items in a store shipment, remain on the purchase order available for a new shipment to receive. This setting cancels the quantities that were in deficit and thus not creating a new shipment/expecting those any more for the store |
| Returnable:InvoicedDays | Amount of days after invoicing after which order can no longer be returned. |
| ProduceReceipt:ReprintReturnedOrder | When you print a receipt for a return order, this setting determines whether or not a new receipt will also be printed for the original order that is being returned. Defaults to true. |
| Discounts:AllowOnReturnOrders | Whether or not to allow discounts on return orders. |
| Refund:DisableRefundsWithoutOriginalTransaction | This allows you to block refunds for orders without original transactions, even for refund methods such as Cash |
| UserCards:AllowRefundsWithoutOriginalTransaction | By setting this to true, refunds will be possible on user cards - even if the original transaction was not by user card. |
| AllowRefundsOnPaidOrders | Allowing refunds on orders that have been paid, but not yet shipped. |
| EnableKlarnaLineInfoForRefunds | Enable this to add line information in the refund request to Klarna. The information will only be added however, if the sum of the collected lines is the same as the amount to refund. |
| Orders:Returns:ReturnFee | Specify a value here to use as a one-time return fee to subtract from a consumer's refund. If part of a partial return, the fee will only be subtracted once. |
| App:Checkout:HideShowMore | By enabling this app setting with true, the Auto Refund will be the only refund method shown (so long as there are auto-refundable transactions). If set to false, the Show more button will be shown alongside the Auto Refund button. |
Varying refund options per user
The setting CRM:Return:RequiresOrderSecurityCode in the table above will toggle the addition of a 'SecurityCode' property to barcodes - those created from this moment on that is. This property will then be passed on in the CreateCustomerReturn call, allowing for a valid return.
Since this would mean you cannot return items sold before the activation of the security code, this requirement can be bypassed by users with the 'ReturnWithoutSecurityCode' role.
Non-returnable products property
Returns can be disabled for certain products based on a product property. To do so, choose or create a product property to use here. The property has to be a boolean. You can then use setting Orders:Returns:NonReturnableProductProperty. The value for the setting has to be the product property of your choice. Now EVA will exclude products from being returned when the product property (mentioned in that setting) is set to true for that specific product.
Preferred refund method
To further improve the refund flow for end-customers, we support our customers setting a preferred refund method when using a return portal. In that case, the original payment method - and your specific refund priority - will be ignored and the refunding will be done based on whatever the customer chose.
This is generally not relevant to our front ends, unless the return portal advises the customer to deliver the products registered for refunding to a store close by. In that case specific case, the refund in the POS for example would adhere to the customer's requested refund method.
For more information on how to set this up, see Preferred refund method in Integrations.
Refund reasons
The Orders module in Admin Suite contains the Return and refund reasons chapter, allowing you to create a refund reason for when issuing refunds via Admin Suite. These reasons will be available in Cookbook as well, allowing you to properly account for manual refunds either as discounts or operational expenses.
These include the following cards:
- Organization returns reasons - reasons used in RMA/RTS flows
- Customer returns reasons - reasons consumers may give when making returns
- Refund reasons - manual refunds which might be given without an actual return, AKA coulance refund
Whichever reason you create, the creation modal will be the same.
As you can see in the following example, you can set a reason for a single store or a specific set of OUs. Additionally you can specify a Priority. This is especially useful when you're working with large lists of reasons; by specifying one you can determine how high on your list the reason should be. The higher the number, the higher on your list and more the more accessible it will be.
