Refund sequence

The refund sequence determines the sequence in which Sterling™ Order Management System creates negative charge or refund requests.

The logic it follows is described below.

1. The refund requests are created against the payment methods in the order of the 'Actual Refund Sequence'. The requests are created against the payment methods in the ascending order of the payment type's configured refund sequence as defined in the seller configuration and then the descending order of the payment method's transactional charge sequence as defined in the specific order.
2. The refund requests are created only against payment types that are marked as VALID_FOR_RETURN. If a payment method is suspended, it is not considered for refund. The steps involved in determining the refund amount are:
   1. In the first parse of the order's payment methods, the refund against a payment method does not exceed the total charge against the payment method.
   2. After the first parse finishes, there could still be some refund that needs to be issued for which a valid payment method, that has the relevant funds charged against it, could not be found. For this extra refund amount, the following logic is applied:
      • If the "PAYMENT->EXCEED_CHARGE_AMOUNT_FOR_REFUND" rule is set as Y (a document type or rule set level definition), the first priority (lowest Actual_Refund_Sequence) payment method on the order is chosen to issue all remaining credit.
   3. Even the above option might fail if there are NO payment methods on the order that are valid for return. In this case, the payment Type, marked as Default For Return, is created for the order and the refund is issued against this payment type. If this payment type requires more information to make it complete, an INCOMPLETE_PAYMENT_INFORMATION event is raised.

If both the above fail (there is no Default_For_Return payment type), then an INCOMPLETE_PAYMENT_INFORMATION event is raised.