Refund payment processing in call center

This article explains how payment refunds are generated through call centers when returns are created, or when orders or order lines are canceled:

Refund payment processing in call centers - Commerce | Dynamics 365 | Microsoft Learn

Something important to pay an attention:

Some functional details on that topic to be able understand how call center refunds work:

When canceling an order that was originally created in call center – we will attempt to refund back to the original payment method. If the original payment method cannot be found (this happens if the order being canceled was not originally created by call center) we will not be able to obtain the original payment method. In that situation, we apply the refund method defined in this call center parameters:

If we can locate the original payment and the order was originally paid by card (credit card, gift card, loyalty card) we will refund back to that same card. If the original order was paid by a “Customer account” type – no refund is due but we will use that same payment type to create the negative payment line to offset the original payment capture.

The major area that our customers often aren’t familiar with is outlined below:

If the original order was paid for with a payment method configured as “normal” or “check” (this is defined in payment method setup):

Then the call center application is designed to check the configuration of the Call Center Refund Methods form. Please note only one payment method per currency can be defined here:

The reason we do that is because if the order was paid by “normal” or “check” we are not in a position to refund back to the original payment method (call center doesn’t support cash refunds and we can’t just give the customer back their original check) – therefore, we have to issue a refund through the Accounts Receivable functions of the ERP. The setup above informs us which AR payment method to use on that refund payment journal that gets created. The Retail payment method is really just there as a placeholder – because we need to apply a payment method to the canceled order to net out the payments to 0. We do enforce that the payment you choose must be of a type check – no other options are displayed as other options (such as card) have their own 3^rd party connectors and processing flows that would require special data that would not be able to be captured if the original order was paid by “normal” or “check”.

Example

• call center order placed with payment method “cash” in USD currency (this is a “normal” payment type).  
• User chooses to “cancel” this order
• Call Center will systematically apply refund payment method 2 to this order (based on current configuration of call center refund methods)
• A payment journal will be created using payment method “REF-CHK”
• The company must print the refund check and post the journal (this can be done from the payment journal form or from the refund check form found in call center menu)

So, that is the way it works – the customer does not get to decide or choose what method of payment is applied to the cancelation – it is systematically done. It will either go back to the original Card – or if it was Normal or Check it will be refunded via the AR method of payment defined in the Call Center Refund Methods form.

This design is created on purpose and we do not allow to use any other payment method for return order as Check (in case when initial payment method was with Function Normal). Check payment journal procedure is standard behaviour from core fin and we cannot change this.

From the documentation, link below, you can see how a call center determines which payment method to apply to a return order:

Refund payment processing in call centers - Commerce | Dynamics 365 | Microsoft Learn 

If the Call Center Refund methods is set to Customer account, we will receive an error message as below (RetailPaymentsRefundMethodsCustomerAccountFlight is enabled - this flight is enabled by default to block refunding using customer account: 

'Customer account is not a supported refund method for cash or check payments'.

Following the document - Refund payment processing in call centers - Commerce | Dynamics 365 | Microsoft Learn - we can see:

“If the original order payment type is unknown for any reason, or if multiple payment methods were used to pay for the original order, call center logic applies the default return payment method that is defined on the RMA/Return tab of the Call center parameters page.

The following illustration shows the Payment method field on the RMA/Return tab of the Call center parameters page.

Note

The refund processing rules that are described earlier also apply to orders or order lines that a call center user cancels in Commerce headquarters. If the cancellation of an order or specific order lines causes any overpayments, the same rules will be used to generate refund payment lines."

The system is taking refund payment method from the Call center refund methods page when we have multiple payment methods with the same ‘Normal’ function (due to integration you do not use Card type payment methods, but Normal instead). They all have the same configuration. If our payment methods would have different Functions, like Card and Gift card, then the system would take them as multiple payment methods and use refund payment method from RMA/Return tab of the Call center parameters.

The Call Center Returns when the original order is a non-Call Center Omni channel order:

If we create an order in Microsoft eCommerce and want to return or cancel a line from the order, if we do not have the following features enabled  - Call Center will not see the Payment for the eCommerce order: 

• Omni-channel Commerce order payments
• Omni-channel payments
• Unified payment posting journal defaults for Commerce

The customer is welcome to customize or extend the solution further to meet their needs – but we would not be able to provide guidance on this. 

There is also no plans to change the current process flow of call center cancelation/refund logic at this time.