OPTIMIZING EMV REFUND PROCESSES FOR BATCH TRANSACTIONS

Design an intuitive workflow and user interface to streamline the refund process for batch-processed transactions handled through EMV devices.


OVERVIEW

As our company introduced batch processing for transactions via EMV devices—card terminals integrated with ERP or CRM systems—I was tasked with designing an intuitive workflow and user interface to facilitate refunds for these complex transactions, each linked to multiple sales orders.

PROBLEM

Users struggled to refund individual sales orders from batch-processed EMV transactions via the Order module. Initially, only full transaction refunds were supported, and listing all associated orders in the confirmation modal reduced readability. There was a need to support single-order refunds while clearly displaying all sales orders associated with the batch.

ACTION

Adjusting the flow

To support individual sales order refunds, I proposed enabling partial refunds by allowing users to enter specific sales order amounts in the Order module. To enhance clarity, I recommended displaying linked sales orders in a separate modal and redirecting users to the Transaction screen to process the parent transaction refund—better aligning the flow with the user's mental model.

Revised flow
Revised flow
Mockup showing partial refund.
Enabling partial refund by pre-filling sales order amount.
Modal showing linked sales orders.
Displaying linked sales orders in a separate modal.
Mockup showing the transaction history screen with the parent transansaction filtered in the table.
Redirecting users to the Transaction screen to process the parent transaction refund.

Initial Design Attempt: Encountering Pushback

In the Salesforce team meeting, my proposed design was well-received. However, the team highlighted a technical limitation: the system couldn't associate a partial refund amount with a specific sales order within a batch-processed EMV transaction. They also suggested enabling full transaction refunds directly from the Order module to reduce user clicks, challenging the initial approach of redirecting users to the Transaction screen.

Adjusting the flow and design

Collaborating with developers revealed that enabling users to specify a particular sales order for refund could allow individual refunds within batch-processed EMV transactions. To facilitate this, I introduced a checkbox in the Order module, serving as a trigger for the system to process the refund for the selected sales order.

Revised flow
Specify a particular sales order for refund allows refunding the full or partial amount of the sales order; otherwise, allow full transaction refund.
Modal showing a checkbox to refund this particular sales order.
Checkbox to specify a particular sales order for refund in the Order module.
Modal showing the Refund Amount field.
Selecting `Refund Only This Sales Order` reveals the Refund Amount input field, with the full sales order amount prefilled.
Mockup showing the warning modal.
A warning message is displayed when the entered amount exceeds the original sales order amount.

RESULTS

Refund Individual Sales Order from Order Module

I introduced a checkbox in the Order module, serving as a trigger for the system to process the refund for the selected sales order.

Final modal enabling individual sales order refund.

Parent Transaction Refund from Order Module

To enhance convenience, I enabled full parent transaction refunds directly from the Order module. I also added a hyperlink to redirect users to the Transaction screen, allowing them to process partial parent transaction refunds as needed.

Modal showing a checkbox to refund this particular sales order.
Modal showing the Transaction History sceen to pay partial pament of the parent transaction.

Display Linked Sales Orders in a Separate Modal

To enhance visibility and scannability, I introduced a hyperlink that opens a separate modal displaying linked sales orders. This approach keeps the main interface uncluttered while providing users with quick access to related information.

Invoice data.

RETROSPECTIVE

Initially, technical constraints seemed to limit improvements to the user flow. However, by questioning these limitations and collaborating with cross-functional teams, I gained a deeper understanding of the challenges—ultimately overcoming the constraints and aligning the solution with user needs.