Advanced orders edit business event

This event occurs when certain payment information needs to be updated, added, or deleted from an order. Edits can occur as long as the order is not closed. For example, edits occur under the following circumstances:

The purpose of this event is to ensure the new payment information is valid and the new payment instruction amounts add up to the order amount. It also ensures that if payment instructions are removed, all related payment actions are reversed whenever possible. Payment instructions can be created during the processing of this type of event.

Payment instructions can be added during a storeAndValidate event, after a storeAndValidate event and before a primePayment event, and after a primePayment event. They can also be added before and after a reservePayment event.

This event verifies that no payment reservation exists with outstanding releases. For example, if two reservePayment events occur for an order, there should be two finalizePayment events for the order (assuming two releases occur; the number of finalizePayments events corresponds to the number of releases). If there are two finalizePayments events, an edit can occur. If a finalizePayment request still needs to occur, an edit cannot occur and an error is returned.

An edit event can occur if a deposit already happened during the primePayment event (or reservePayment event followed by a finalizePayment event) as long as the amount does not need to be reduced below the deposited amount. An edit to increase the amount is always allowed. A decrease might not be allowed if funds were already deposited (however, the edit can be forced to allow the increase).

The possible payment actions associated with this event are not configurable.

Edits will trigger reversals and validation of payment instructions. A triggerActions business event will trigger equivalent actions for the primePayment event.

If a deposit has already happened against a payment instruction that is being removed, the edit will fail unless it is forced. In this case, a tickler will be created to notify a Customer Support Representative that an amount might need to be refunded to the customer.

Example: A customer's credit card order has been captured. The customer later contacts the Customer Support Representative to switch brand of credit cards. The Customer Support Representative edits the payment information to make the change and an edit business event occurs. In the triggerActions business event, the system verifies that the payment instructions can indeed be changed (that is, payments have not already been reserved for the order), and reads the payment action rules required for the payment method.

Feedback