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.

Authorization

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 missing shoelaces or even a bad customer experience for example.
  
  Mind that there are two distinct functionalities which both result in this kind of refund, as explained in the following section.

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

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 Admin Suite will show any price override along with its original price.

You can create a price correction via the Edit order icon.

Price correction in POS

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 Admin Suite are you able to select items to refund while indicating the customer can keep the product(s). Note that this kind of refund cannot be combined with an actual return.

Creating such a refund will automaticallly take you to a new return order, which will show the order's total negative amount which you can refund straight away by going to the Payments tab and creating a new payment. The total amount will be pre-filled for you. Which refund methods will be available here, depends on the store you picked in the OU selector. Keep in mind that if you want to create a refund, the order needs to be shipped and there can be no currently pending refunds.

As for the original order, the refunded order lines will show as no longer editable.

No mix and match

To reiterate: if you have an order with products you want to return and some products you want to refund but not return, then you'll have to go through this flow at least twice. For more information on how to perform this kind of refund, see Create return order icon.

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. It is our primary refund option and 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 giftcards, 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 in the Overview returns settings. POS will only show the tile if there are transactions that can be refunded this way. If only parts of the order are eligible for an auto refund, we will redirect you to the refund checkout to process the remaining transactions.

Cash, Cards and Custom

The following refund methods will be displayed either:

• right away, when the order was paid entirely by a non-autorefundable type (such as Cash);
• after having exhausted the Auto Refund possibilities (no more auto-refundable transactions available for the order);
• by clicking the Show more button.

When selecting transactions for a refund, EVA automatically fills in the correct amount. If the refundable amount is less than or equal to the open amount, the refundable amount is pre-filled. However, if the refundable amount is greater than the open amount, the open amount is pre-filled.

• 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 giftcards 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:DisableRefundsWithoutOriginalTransaction allows you to block refunds for orders without original transactions, even for refund methods such as Cash.

Refunding on user card

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:Lines:UnitPriceCorrections:CreateSeparateLine	Enabling this will result in a separate order line being created when you perform a price correction.
Orders:Cancellations:RefundOpenAmountAfterPartialCancellation	when set to true, this setting refunds automatic after an order line 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 fulfillment OU - this only applies a return OU is set.
Orders:Returns:AllowCustomerChangesOnReturns	Defaults to true. When false, changing the consumer, or its billing/shipping address on a return order that only has return lines is not allowed. Regardless of the setting value, this is always allowed when - the original order does not have a customer; - the customer is anonymized due to a privacy removal request; - the order is a mixed order.
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 order line 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. Note that an override is possible with OverrideReturnablePeriod functionality.
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.
Orders:Returns:ReturnFeeOnlyFor	Specify for what kind of return you want to charge the fee for. Excluding custom implementations, the possible values are: - GOOGLE_EXPRESS - PUSHRETURNORDER (through PushReturnOrder service) - CUSTOMERRETURN (through CreateCustomerReturn service) - RETURNLINES (through ReturnOrderLines service)
Orders:Returns:ReturnFeeUseOriginalOrder	By setting this to true (default false), the return fee calculation will be based on whatever is set for the originating sold from organization unit, rather than the current OU where the refund is being performed.
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.
App:TapToPay:AllowPartialPayment	When set to true, orders can be partially paid and refunded using Tap to Pay.

Varying refund options per user

The setting CRM:Return:RequiresOrderSecurityCode in the table above will toggle the addition of a SecurityCode property to barcodes. 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 Reasons chapter, allowing you to create Customer refund reason and Refund correction reasons. These reasons will be available in Cookbook as well, allowing you to properly account for manual refunds either as discounts or operational expenses.

Refunds and coupons

A customer will never be paid back something that wasn't paid in the first place. But in some cases the customer is elligible to get another shot with the promotion. This is for example the case when using coupons.

Coupons are tied to the order lines they're involved in. This means that if a specific order line, which was (partially) paid with or had a reduced price due to a coupon, is returned, then the customer can get the coupon back as well.

Some details:

• It's not exactly the coupon that's returned, but the coupon usage. For example: if a coupon can be used five times, then one returned order line will bump up the usage by one.
• A coupon cannot be returned if it's expired.
• If a coupon is returned for an order with a customer attached, then an email will be sent out informing the customer (via the ReturnDiscountCoupon stencil).
• An event export message will be sent out about this returned coupon with target Coupon, type Release_coupon.