Extension points - Refunds
While the enfore platform has built-in handling for refunding of sales performed via the enfore platform, sometimes refunds must be granted for sales performed outside of the enfore platform. Or for sales performed by other organizations.
For this, the enfore platform provides CUWOs that allow each organization to implement whathever refund logic is suitable for them and integrated them as seamlessly as possible into the regular enforePOS UI.
The choice of CUWOs for that integration stems from the fact that most, if not all, refunds processes require some kind of user interface. For example, the customer will surely need to choose what to refund. A CUWO has the additional benefit that the enfore platform does not "see" any information (e.g., full sales history of a customer including sales done outside the enfore system) that it should not have access to. The platform provides the CUWO with a runtime environment but is not involved in the actual user/UI interaction.
In general, the enfore platform processes refunds as a "refund process" that goes through the following steps:
- Started - newly created RP, refund hat not been authorized yet
- Authorized - refund has been authorized and refund amount has been defined
- Processed - refund has been processed
Additionally, refund processes can "Fail" or become "Canceled".
Note that transitions from "Authorized" to "Canceled" only occur after a previous authorization has been released/reverted. And that transitions from "Authorized" to "Failed" only occur after that release/reversal failed.
CUWO extension points
For the built-in refund functionality, the enfore platform contains the logic to perform the operations necessary to transition the states of the refund processes. For CUWO-based refunds, that logic must be provided by the CUWOs. Thus, we will define the following new CUWO extension points for the enfore platform:
AuthorizeRefundProcessRefundCancelRefund
For refunds, the possible activity flow looks like this:
About abortion of CUWOs
A CUWO normally ends itself by invoking the terminateSuccess or terminateFailure methods of the CUWOCallback API that is injected into the browser instance by enforePOS.
For cases where the CUWO does not end itself, e.g. when the CUWO application could not be loaded or has bugs, the enforePOS UI wrapper around the CUWO window provides a way to cancel/abort a CUWO. There is a process in place how that UI and the CUWO interact to provide the CUWO with a way to gracefully terminate itself but also ensure that an unresponsive CUWO does not block the enforePOS runtime. See the Aborting Workflows in the CUWO documentation about more details.
When any of the refund-related CUWOs becomes unresponsive and needs to be terminated by the enforePOS runtime, that CUWO will be treated as "failed" as the status of the refund/payout is unknown to the enfore platform.
For example, when an AuthorizeRefund CUWO needed to be terminated, the enforePOS runtime will invoke a CancelRefund CUWO as it must assume that the AuthorizeRefund CUWO has already authorized something. Independent of the result status of the CancelRefund CUWO, the refund process will be marked as failed. The enfore runtime will keep track of which CUWO was invoked and how it terminated (success, failure, cancel) to support investigation of failed refunds.