IE20020621A1 - A merchant disputed transaction management system - Google Patents

Abstract

A merchant dispute manager (MDM) system enables a merchant to effectively process disputed transactions. It has an upload module for interfacing automatically with an acquirer system to receive disputed transaction message. It also has an online module for interactive case management. The upload module automatically updates an MDM database as email messages are received. The online module may route messages to a merchant subdivision system. Both the upload and online modules have an object-oriented structure and the online function has a case object for managing case progression. One instance of the case object is instantiated per case and is terminated upon completion of the case. <Figure 1>

Description

Field of the Invention The invention relates to merchant systems, particularly for disputed card transactions.

Prior Art Discussion At present, the task of managing transactions which are in dispute is very timeconsuming. The extent of manual effort and the volume of paperwork have in practice resulted in significant backlogs and associated inefficiencies. This situation had developed primarily because the nature of such transactions does not lend itself to automation because of their complex nature.

The invention addresses this problem.

SUMMARY OF THE INVENTION According to the invention there is provided a merchant disputed transaction processing system comprising means for controlling communication with an acquirer system, characterised in that said control means comprises: an upload function comprising means for receiving disputed transaction messages from the acquirer system and for updating a database according to a disputed transaction case reference, and an online function comprising means for retrieving data from the database and for directing communication of messages incorporating said data to and from the acquirer system to progress a disputed transaction case. -2In one embodiment the upload function comprises means for operating in an automatic manner without user intervention.

In one embodiment the upload function comprises means for automatically searching for relevant incoming messages and for triggering database updates according to message characteristics.

In another embodiment the online function comprises means for operating with user interaction.

In one embodiment the upload function comprises a database update object associated with each of a plurality of storage mechanisms and an object for monitoring incoming messages.

In one embodiment the upload function further comprises a case object comprising means for automatically processing messages which have been identified by the monitoring object and updated to the database by the database update object.

In another embodiment the monitoring object comprises means for parsing incoming messages to allow the database update object to update the database according to the relevant case.

In one embodiment the online function comprises a queue object comprising means for determining fresh updates in the database for sorting them in priority order in a queue and for generating a user prompt for activation of priority cases.

In one embodiment the online function comprises a search object for performing database searches according to combination of user-specified criteria. -3ΗΕ ο 2 0 R 2 I In one embodiment the online function comprises a case object comprising means for managing data for cases, and for allowing user actions for cases.

In another embodiment an instance of the case object is instantiated for each case, and the online function comprises means for terminating the instance upon completion of the associated case.

DETAILED DESCRIPTION OF THE INVENTION Brief Description of the Drawings The invention will he more clearly understood from the following description of some embodiments thereof, given by way of example only with reference to the accompanying drawings in which:Fig. 1 is a high-level block diagram showing operation of a merchant dispute manager (MDM) system of the invention; Fig. 2 is a diagram showing integration of the system with merchant subdivisions; Fig. 3 is a diagram illustrating system architecture in overview; Fig. 4 is a diagram showing upload architecture in more detail; and Fig. 5 is a diagram showing online architecture in more detail.

Description of the Embodiments Referring to Fig. 1, a merchant transaction management system resides on a merchant server, and is also referred to as a Merchant Dispute Manager (MDM). It -4comprises an MDM online function, an MDM upload function, and an MDM database. The context is transaction processing in communication with an acquirer system having a chargeback (dispute) system and database, an e-mail server and a card network gateway. Referring to Fig. 2, integration with merchant subdivisions (branches / departments / outlets / stores / chains) is illustrated.

The following are signal flows, with reference to Fig. 1.

Operation of System fAcquirer - Merchant) Flow 1: Data relating to card transactions is sent from a card scheme to the acquirer’s card management system.

Flow 2: Data relating to disputed card transactions are sent from the card management system to the chargeback (dispute) system.

Flow 3: Document requests (in the form of chargeback files) are then sent to the router.

Flow 4: The requests are then sent to the acquirer’s server.

Flow 5: The requests are then sent to the merchant’s server.

Flow 6: The MDM upload application processes the file and updates the MDM database & file source.

Flow 7: When the relevant document to meet the request has been sourced, it is sent to the merchant’s server.

Flow 8: The documents or a link to the document are then emailed to the acquirer’s server.

Flow 9: This information then passes from the server to the router.

Flow 10: This information is then passed to the chargeback system.

Flow 11: This information and other relevant details are then passed to the acquirer card management system.

Flow 12: This information and other relevant details are then passed to the card scheme. -5IE020621 The following are signal flows, with reference to Fig. 2 Operation of System (Merchant - Subdivision) Flow 1: Requests for documents are sent to the merchants server.

Flow 2: The requests are the emailed to the, merchant subdivision’s e-mail server. Flow 3: The request then passes from the e-mail server to the relevant client.

Flow 4: When the relevant document to met the request has been sourced, it is sent to the merchants subdivision’s e-mail server.

Flow 5: The requests are the emailed to the merchant’s e-mail server.

Flow 6: The MDM upload application processes the mail and updates the MDM database & file source.

The MDM system is setup in the merchant site (typically the head office). It comprises online and upload functions. Document requests relating to retrieval requests and chargebacks are sent to the merchant (as files) from the card management system. These files are picked up automatically by MDM upload and details are loaded into the database. MDM online is then used to further process these cases. In order to send a response back to the acquirer the merchant may need to get information from a merchant subdivision. This process is automated and is achieved by sending messages to the merchant subdivision. When the response is returned from the subdivision it is picked up by MDM upload and the database and file server are updated using the details on the email. If enough information has been provided the response may then be sent back to the acquirer.

An important feature of the system is that incoming messages from the acquirer are automatically identified as such, processed and extracted data is updated to the MDM databases. -6The MDM upload application is installed on any desired number of «user machines and specifies the configuration settings that are needed for receiving incoming emails, receiving incoming files, for storing e-mails in tbe database as well as for how the archive facility will operate. It may be run as a service or as a standalone executable.

All relevant files originate from the acquirer system. When a file is located then the upload will take the information contained within the file, parse it and use the relevant information to create a case in the MDM database.

All relevant case e-mails originate from the merchant subdivision. These e-mails are recognised using field identifiers in the subject line. These field identifiers are agreed in advance with the acquirer and are configurable within tbe MDM system. The upload program searches through all unopened incoming e-mails in the user’s e-mail system looking for the specific subject line information as agreed with the merchant subdivision. When an e-mail message with the appropriate subject line information is located then the upload will take the information contained within the message and place it in tbe MDM database.

Within each relevant e-mail message is an XML (extensible Markup Language) file which has a series of tags identifying the case by its case id and account number. All case information is formatted in this manner and the XML file will correctly match information per case using the acquirer case id and account number contained within the XML tags.

It also searches for any images within these mail messages and extracts any appropriate images, saving them out to an image folder (usually on a fileserver). Each individual case will have an associated sub-folder in this image folder where case-related information and images can be stored. This facilitates universal access to -7all case related information and documentation as the users within the organisation can view all case data in the database and on the file server MDM upload deals with any duplicates that may come into the system as it would a normal MDM related case, however, it updates the database with an additional comment indicating it’s a duplicate and specifying the original case number.

Queues A Queues tab generated by MDM online presents the following two queues: • Retrieval Requests queue • Chargeback Requests queue.

The information contained in both these queues is read from the database by the online application and is ordered in terms of priority, i.e. the number of days left with which to take an action. This deadline management concept means that the crucial time limits associated with dispute-related transaction are always highlighted by ensuring that the most urgent cases are dealt first.

Retrieval Requests queue This queue displays cases that are currently at retrieval request stage where the voucher must be returned as proof of the transaction to the acquirer. These cases are awaiting the receipt of the voucher from the merchant subdivision or central filing system and will be returned, when received from the merchant subdivision or central filing system, to the acquirer for continuation of this process.

The retrieval request queue contains the following fields: • Days Left • Account Number -8• Merchant Reference Number • Branch Name • Transaction Date • Transaction Amount • Transaction Currency • Case ID Fields For a retrieval request case the details screen contains the following fields: • Case ID • Account Number • Merchant Reference. No.

• Branch Name • Transaction Date • Transaction Amount • Transaction Currency • Comment • Reminder Date • Reminder Comment Case History The case history outlines a full history of the case including both user and automatic system actions. This frame will be populated with descriptions of any actions that have been taken on the case following its creation. This is a useful facility for getting a quick synopsis of the case.

Fields The case history dialog contains the following fields: • User ID • Date/Time • Comment Type • Comment Document History The document history outlines a full history of all case-related documentation. This document frame provides a list of all relevant documents that are associated with the specific case. As documentation relevant to the case is sent/received this document history will automatically update to include these records.

Fields The document history dialog contains the following fields: • Document ED • User ID • Date/Time • Sent/Received • File Name • Actions There are six possible actions available on a case at either retrieval request or chargeback stage: - Add Comment - Add Reminder/Cancel Reminder -10- Reply to Acquirer - Send Document - Send Email Close Case Action 1: Add Comment This action allows one to add a comment to a case.

Action 2: Add Reminder This action allows one to add a reminder to a case. By taking this action a reminder tag will be added to the case and when the reminder date is reached it will be moved to the top of the queue until the reminder is cancelled.

Action 3: Reply to Acquirer This action allows one to send a reply to the acquirer via e-mail. A system e-mail screen appears with the address and subject fields already populated. This information is read from the database. There is a comment facility on the e-mail message as well as an option to add attachments to the message for sending documentation. Or using the web interface of the On Line function an email may he sent to the acquirer with a link to the relevant documentation.

A confirmation message will appear stating that the e-mail has been sent successfully to the acquirer.

Action 4: Send Document This action allows one to send a document/letter to other parties (in particular a merchant subdivision) involved in the dispute. A choice of available documents/letters appears on the Send Document screen and one chooses the appropriate document/letter. This list of documents/letters is previously configured in the database and templates are drawn up for each document/letter. Data is IE Ο 2 06 2 1 -11 merged with the template to create the relevant document/letter using Microsoft Word™.

By clicking Send the document/letter is sent straight through to the relevant recipient 5 via e-mail and a confirmation message appears to notify that the e-mail message containing the relevant document/letter has been sent.

By clicking Edit one can open the document/letter and edit if necessary and by clicking Print you can print the document/letter.

Action 5: Send Email This action allows one to send an e-mail to a merchant subdivision.

A comment field is available for writing any accompanying message text and one 15 also have the option to add attachments if necessary using the Add button in the Attachment field. The Remove button in this field will remove an attachment from the message. The Scan Document button allows one to scan a document/image and attach it to the email.

Chargeback Requests Queue This queue displays all cases that are currently at chargeback stage.

Fields The chargeback requests queue displays the following fields: • Days Left • Case ID • Account Number • Merchant Reference Number - 12• Branch Name • Transaction Date • Transaction Amount • Transaction Currency • Chargeback Reason Details For a chargeback case the ‘Details’ screen provides the following extra information: • Case ID • Account Number • Merchant Reference. No.

• Branch Name • Transaction Date • Transaction Amount • Transaction Currency • Comment Search A Search tab presents the various criteria that are available to search on.

The search criteria available are: • Account Number • Branch Name * Transaction Date (from - to) * Transaction Amount (from - to) * Transaction Currency • Case ID -13• System Case ID Reporting A comprehensive MIS reporting facility is provided. This reporting facility allows one to manage business exposure by generating MIS reports. The information contained in these reports is extremely useful for calculating dispute related costs and effort as well as forming a reference for future business predictions. There are many different types of reports that can be created using this facility. These reports are generated using XSL (extensible Stylesheet Language) to transform XML into HTML (Hypertext Markup Language) format Report Types This reporting facility allows one to produce a wide range of MIS reports. These reports provide the necessary information to enable one to access and improve business exposure. This facility is extremely flexible and enables one to specify reporting structures that will compliment specific business needs.

These report types are accessible from a Reports tab and appear in a Reports List dialog box. Certain reports can be implemented to produce very specific information by allowing the user to specify a required date range, branch name, case ID, etc.

Sample reports are: Case Details: This report details full information/history about a particular case.

Monthly Retrieval Request: This report details information about all retrieval request cases for a particular month.

Monthly Chargeback Request: This report details information about all chargeback cases for a particular month. -14Monthly Statistics: This report details all case statistics for a particular month.

Subdivision Details: This report details all information regarding a particular merchant subdivision.

Resolved Cases: This report details all cases that have been resolved.

Architecture of System In more detail and referring to Fig. 3 the MDM system comprises two tiers as follows. 1. Application Tier - This consists of two modules. > MDM upload : A non-interactive module which is responsible for processing all MDM related incoming files/emails and loading the MDM database with data from the files & emails. > MDM online: An interactive module which enables users to deal with and respond to the requests from the acquirer. Requests may also be forwarded to other merchant subdivisions. 2. Data Tier - This consists of the three main sources of data. > Database - All data pertaining to the acquirer requests are held in the database tables. > Files - All data & images relating to acquirer requests are stored on a file server. > Email - All responses to the acquirer are via email. Requests may also be forwarded to merchant subdivisions via email and response to these may also be in email format. ΙΕΟ 206 2 1 -15The functions of the MDM upload program are as follows: 1. Process incoming files from tire acquirer. > Add the requests to the database. > Archive the files. 2. Process incoming emails from the merchant subdivision: > Save any attachments to the file server. > Update the status of request in the database. > Archive the emails.

The MDM upload application consists of a number of objects which achieve the 15 above functionality represented in Fig. 4: INPUT Object The INPUT object processes incoming data files, parses this file and retrieves all data 20 relevant to document requests. This is then sent send to the CASE objet for processing The INPUT object also watches the mail inbox and processes all new MDM related emails. The email subject line is used to indicate that this is an MDM related email. An MDM email may contain one or more attachments. The contents of the mail message and all attachments are verified and all appropriate messages are sent to the CASE object for processing.

Finally when emails have been processed by the CASE object they are then archived to a specific archive folder. -16CASE Object The contents of these attachments will differ depending on the source, a file from the acquirer, an email from the merchant subdivision. The first task of the CASE object is to decide on the message type and process the message appropriately.

Request from acquirer Files from the acquirer will contain details of the request The data is used to create a new MDM case. This file contains all relevant data pertaining to the request from acquirer. This data is processed and a new case created in the MDM database.

Update from merchant subdivision Emails from the merchant subdivision contain data which may be used to update the status of an existing MDM case. In addition, any other documents relating to the case may be contained in this message. One of the attachments must be a file containing XML data (extension of this file is .XML). This file contains all relevant data pertaining to the case. This data is processed and the relevant case updated in the MDM database. The contents of the message and all other attachments are stored on the file server in a specific folder for this case.

DATABASE Object All database interaction whether it be login/logout, inserts, updates, select are processed by the DATABASE object. All database specific code is contained in this object. ODBC (Open Database Connectivity) drivers are used to connect to the database so in the future if there is a need to support other database platforms only the database driver will need to change.

FILE Object -17All interactions with the file system, creating folders, saving files etc, are taken care of by the FILE object. This object is designed to allow it to be enchanced in the future to store files in a document management system without having a major impact on the other upload objects.

Referring to Fig. 5, the functions of the MDM online application are as follows: 1. Prioritise cases for the user 2. Add comments to a case 3. Send case onto the merchant subdivision where additional information is required 4. Send response to acquirer . Request information from merchant subdivision 6. Set a reminder for the case 7. Close a case 8. View images associated with a case 9. Search the database . Report on cases in the database The MDM online application consists of a number of objects which achieve the above functionality.

QUEUE Object When the online function is first run the database is examined and all cases which have been added or updated (by MDM upload) are loaded into the QUEUE object. These are displayed to the user in order of priority thereby indicating to the user the order in which cases should be processed. This object is updated as the priority of cases change (as they are processed) and/or as new cases are read into the database. When a case is first created in the database the priority is determined based on -18information provided by the acquirer. As the user processes the cases the priority is set based on the time to respond associated with the action.

SEARCH Object All searches on the database are performed by the SEARCH object. The user may search on any number of different criteria.

CASE Object Once a case in loaded form either the queue or search screen the CASE object is instantiated and all details pertaining to a case are held in the CASE object. There are a number of actions available to the user and each of these is implemented by the CASE object. These include: Add comments Set reminder Send document/letter to merchant subdivision Send case onto merchant subdivision Send response to acquirer Close case View case history View images associated with case REPORT Object The REPORT object generates and displays the reports to the user. XML is used to define the reports that are available and the contents of each report. XSL is used to define the layout of the reports. The XML is processed and the report data is generated. XSL is then used to format this and the resulting data displayed to the if V '<& -19user in HTML format. This approach is extremely flexible and additional reports may be added without having any impact on the online application.

WORD INTEGRATION Object Request may be sent onto the merchant subdivision via Word documents/letters. The WORD INTEGRATION object interacts with the Microsoft Word Object Library to create Word documents. Document templates may be created and the WORD INTEGRATION object will create documents from these templates by taking all required data from the database and replacing the appropriate fields in the templates.

FILE Object AU interactions with the file system, opening files, viewing files etc, are taken care of by the FILE object. This object is designed to aUow it to be enchanced in the future to store files in a document management system without having a major impact on the other On Line objects.

DATABASE Object AU database interaction whether it be login/logout, inserts, updates, select are processed by the DATABASE object. AU database specific code is contained in this object. ODBC (Open Database Connectivity) drivers are used to connect to the database so in the future if there is a need to support other database platforms only the database driver will need to change.

EMAIL Object -20IE 0 20 6 2 1 Emails may be sent to the acquirer and to a merchant subdivision. The EMAIL object will create these emails based on data from the CASE object and will interact with the email system.

It will be appreciated that the invention allows significantly improved control by a merchant over handling of disputed transactions. It effectively completes a link of feeding of disputed transaction data from a customer to an issuer, to an acquirer and to the merchant. This link is now automated to a large extent with underlying technical features performing automation and generating priority information for a user to make inputs in an effective manner. The system will be of particular benefit to merchants having greater drat 100,000 transaction per day.

The invention is not limited to the embodiments described but may be varied in construction and detail.

Claims (12)

Claims

1. A merchant disputed transaction processing system comprising means for controlling communication with an acquirer system, characterised in that said control means comprises: an upload function comprising means for receiving disputed transaction messages from the acquirer system and for updating a database according to a disputed transaction case reference, and an online function comprising means for retrieving data from the database and for directing communication of messages incorporating said data to and from the acquirer system to progress a disputed transaction case.

2. A system as claimed in claim 1, wherein the upload function comprises means for operating in an automatic manner without user intervention.

3. A system as claimed in claim 2, wherein the upload function comprises means for automatically searching for relevant incoming messages and for triggering database updates according to message characteristics.

4. A system as claimed in any preceding claim, wherein the online function comprises means for operating with user interaction.

5. A system as claimed in any preceding claim, wherein the upload function comprises a database update object associated with each of a plurality of storage mechanisms and an object for monitoring incoming messages.

6. A system as claimed in claim 5, wherein the upload function further comprises a case object comprising means for automatically processing -22messages which have been identified by the monitoring object and updated to the database by the database update object.

7. A system as claimed in claims 5 or 6, wherein the monitoring object 5 comprises means for parsing incoming messages to allow the database update object to update the database according to the relevant case.

8. A system as claimed in any preceding claim, wherein the online function comprises a queue object comprising means for determining fresh updates in 10 the database for sorting them in priority order in a queue and for generating a user prompt for activation of priority cases.

9. A system as claimed in any preceding claim, wherein the online function comprises a search object for performing database searches according to 15 combination of user-specified criteria.

10. A system as claimed in any preceding claim, wherein the online function comprises a case object comprising means for managing data for cases, and for allowing user actions for cases.

11. A system as claimed in claim 10, wherein an instance of the case object is instantiated for each case, and the online function comprises means for terminating the instance upon completion of the associated case 25

12. A computer program product comprising software code for completing a system as claimed in any preceding claim when executing on a digital computer.