System and method for stand-in processing

A system and method for stand-in processing are provided. The system includes a processor and a memory unit communicatively coupled to the processor. The memory unit is configured to store transaction data received from an acquirer corresponding to a transaction made by a payment card. The processor is configured to determine data representing a point of sale (POS) entry mode of the transaction from the transaction data and, using one or more stand-in rules provided by an issuer of the payment card, process the transaction on behalf of the issuer based on the data representing the POS entry mode. Processing includes approving or declining the transaction.

CROSS REFERENCE TO RELATED APPLICATIONS

This patent application claims priority to Singapore Application No. 10201609753R filed on Nov. 21, 2016, the disclosure of which is incorporated by reference herein in its entirety as part of the present application.

BACKGROUND

The present disclosure relates broadly, but not exclusively, to a system and method for stand-in processing of a transaction involving a payment card.

In payment card transaction processing, stand-in processing or authorization is a service provided by a payment card network, in which the payment card network acts on behalf of the issuer or as a back-up to the issuer in the authorization process. This can happen, for example, when the issuer's systems are not available or when the issuer delegates the authorization of certain transactions to the payment card network.

Typically, the issuer establishes stand-in parameters that control which transactions are subject to stand-in authorization. Stand-in parameters are conventionally based on the Bank Identification Number (BIN) range (also known as the Issuer Identification Number—IIN—range) and therefore have certain limitations. For example, while it is possible to edit or remove the stand-in authorization set up for a BIN, other types of customization cannot be done.

A need therefore exists to provide a method and system that seeks to address the above problems or provide a useful alternative.

BRIEF DESCRIPTION

An aspect of the present disclosure provides a system for stand-in processing, including a processor and a memory unit communicatively coupled to the processor. The memory unit is configured to store transaction data received from an acquirer corresponding to a transaction made by a payment card. The processor is configured to determine data representing a point of sale (POS) entry mode of the transaction from the transaction data and, using one or more stand-in rules provided by an issuer of the payment card, process the transaction on behalf of the issuer based on the data representing the POS entry mode, wherein processing includes approving or declining the transaction.

The processor may be configured to select the transaction for processing based on the POS entry mode prior to processing the transaction.

The processor may be configured to process the transaction on behalf of the issuer through a zone control master key (ZCMK) shared by the issuer.

The zone control master key may include a PIN verification key (PVK).

The zone control master key may include a card verification key (CVK).

The data representing the POS entry mode may include the data element22of a message compliant with ISO 8583.

The transaction may include one of a group consisting of a web-based transaction, an ATM-based transaction, and a POS device-based transaction.

A second aspect of the present disclosure provides a method for stand-in processing. The method includes receiving, from an acquirer, transaction data corresponding to a transaction made by a payment card. Using a processor, data representing a point of sale (POS) entry mode of the transaction is determined from the transaction data. Using one or more stand-in rules provided by an issuer of the payment card, the transaction is processed on behalf of the issuer based on the data representing the POS entry mode, wherein processing includes approving or declining the transaction.

The method may further include selecting the transaction for processing based on the POS entry mode prior to the processing step.

Processing the transaction on behalf of the issuer may include using a zone control master key (ZCMK) shared by the issuer.

The zone control master key may include a PIN verification key (PVK).

The zone control master key may include a card verification key (CVK).

The data representing the POS entry mode may include the data element22of a message compliant with ISO 8583.

The transaction may include one of a group consisting of a web-based transaction, an ATM-based transaction, and a POS device-based transaction.

DETAILED DESCRIPTION

Embodiments of the present disclosure provide a method and system to manage stand-in authorization or processing of a transaction involving a payment card based on the point of sale (POS) entry mode, instead of solely based on the Bank Identification Number (BIN).

The example embodiments will now be described, by way of example only, with reference to the drawings. Like reference numerals and characters in the drawings refer to like elements or equivalents.

Unless specifically stated otherwise, and as apparent from the following, it will be appreciated that throughout the present specification, discussions utilizing terms such as “scanning”, “calculating”, “determining”, “replacing”, “generating”, “initializing”, “outputting”, or the like, refer to the action and processes of a computer system, or similar electronic device, that manipulates and transforms data represented as physical quantities within the computer system into other data similarly represented as physical quantities within the computer system or other information storage, transmission, or display devices.

The present disclosure also provides an apparatus for performing the operations of the methods. Such apparatus may be specially constructed for the required purposes, or may include a general purpose computer or other device selectively activated or reconfigured by a computer program stored in the computer. The algorithms and displays presented herein are not inherently related to any particular computer or other apparatus. Various general purpose machines may be used with programs in accordance with the teachings herein. Alternatively, the construction of more specialized apparatus to perform the required method steps may be appropriate. The structure of a conventional general purpose computer will appear from the description below.

In addition, the present disclosure also implicitly provides a computer program, in that it would be apparent to the person skilled in the art that the individual steps of the method described herein may be put into effect by computer code. The computer program is not intended to be limited to any particular programming language and implementation thereof. It will be appreciated that a variety of programming languages and coding thereof may be used to implement the teachings of the disclosure contained herein. Moreover, the computer program is not intended to be limited to any particular control flow. There are many other variants of the computer program, which can use different control flows without departing from the spirit or scope of the disclosure.

The present disclosure may also be implemented as hardware modules. More particularly, in the hardware sense, a module is a functional hardware unit designed for use with other components or modules. For example, a module may be implemented using discrete electronic components, or it can form a portion of an entire electronic circuit such as an Application Specific Integrated Circuit (ASIC) or Field Programmable Gate Array (FPGA). Numerous other possibilities exist. Those skilled in the art will appreciate that the system can also be implemented as a combination of hardware and software modules.

The present disclosure relates to methods for stand-in authorization of a transaction involving a payment card. Currently, many merchants accept electronic payment transactions as an alternative to cash for the payment for products. In such electronic payment transactions, a payment card may be used. As used herein, the terms “transaction card,” “financial transaction card,” and “payment card” refer to any suitable transaction card, such as a credit card, a debit card, a prepaid card, a charge card, a membership card, a promotional card, a frequent flyer card, an identification card, a gift card, and/or any other device that may hold payment account information, such as mobile phones, Smartphones, personal digital assistants (PDAs), key fobs, and/or computers.

FIG. 1shows a schematic diagram100illustrating the stand-in authorization process according to an example embodiment. Typically, in a payment card transaction, when a payment card holder (consumer) wishes to purchase a product/service from a merchant at a point of sale (POS)102, the payment card holder presents his/her payment card to the merchant. The merchant then submits a request to an acquirer104(a financial institution such as a bank that processes and settles the merchant's transactions with the help of an issuer). The acquirer104then sends the request to the issuer106(a financial institution, bank, credit union or company that issues or helps issue cards to payment card holders) to authorize the transaction. A payment facilitator, also known as a card network or card scheme108(e.g. MasterCard®), acts as an intermediary between the acquirer104and the issuer106. As described in more detail below, the card network108in the example embodiments further includes stand-in authorization services, in the form of an application or module110that authorizes the transaction on behalf of the issuer106. If the card network108authorizes the transaction using application/module110or if issuer106authorizes the transaction, the merchant releases the product/service to the payment card holder.

The transaction authorization process described above involves multiple parties (payment card holder (consumer), merchant102, acquirer104, issuer106, Stand-In Authorization Service110, and payment facilitator108). However, the transaction authorization process may be essentially viewed as a transaction between a payment card holder and a merchant (with the other parties facilitating the transaction).

During the transaction, certain data associated with the transaction (i.e. transaction data) may be generated and the transaction data may be captured/collected by the payment facilitator108. Such transaction data may be stored in a transaction database. For example, the transaction data may be uploaded to a data warehouse on a regular basis (e.g. daily, weekly, monthly). If necessary, various algorithms/rules can be applied to anonymize the transaction data so that no personally identifiable numbers are available to the users of the transaction data.

The transaction data that can be generated/captured include transaction level information (e.g. Transaction ID, Account ID (anonymized), Merchant ID, Transaction Amount, Transaction Local Currency Amount, Date of Transaction, Time of Transaction, Type of Transaction, Date of Processing, Cardholder Present Code Merchant Category Code (MCC)), Account Information (e.g. Account ID (anonymized), Card Group Code, Card Product Code, Card Product Description, Card Issuer Country, Card Issuer ID, Card Issuer Name, Aggregate Card Issuer ID, Aggregate Card Issuer Name), Merchant Information (e.g. Merchant ID, Merchant Name, MCC/Industry Code, Industry Description, Merchant Country, Merchant Address, Merchant Postal Code, Aggregate Merchant ID, Aggregate Merchant Name, Merchant Acquirer Country, Merchant Acquirer ID), and Issuer Information (e.g. Issuer ID, Issuer Name, Aggregate Issuer ID, Issuer Country).

Typically, the transaction data may be organized according to a standard, for example, standards promulgated by the International Organization for Standardization (ISO). For example, ISO 8583 defines a message format for financial transaction card originated messages, in which standard fields carrying transaction information are known as data elements. Up to 128 data elements may be defined.

FIG. 2shows a flow chart200illustrating a method for stand-in processing according to an example embodiment. At step202, transaction data corresponding to a transaction made by a payment card is received from an acquirer. At step204, data representing a point of sale (POS) entry mode of the transaction is determined from the transaction data using a processor. At step206, using one or more stand-in rules provided by an issuer of the payment card, the transaction is processed on behalf of the issuer based on the data representing the POS entry mode. Processing may include approving or declining the transaction.

The present method seeks to provide stand-in processing of the transaction based on the POS entry mode, instead of solely based on the BIN data. Thus, in one implementation of step204, the method looks for the data element22of the standardized message compliant with ISO 8583 that is received from the acquirer to identify where the transaction was initiated prior to step206. In other words, the mode or type of transaction is determined, since each type of transaction has a unique POS entry mode value in the data element22. For example, the transaction may be a web-based transaction, an ATM-based transaction, or a POS device-based transaction.

With reference toFIG. 1, typically the issuer106configures the stand-in setup according to it requirements. This can be done via a Web interface for example. The requirements may be specific to a transaction type or according to any stand-in parameters defined by the issuer106. For example, the issuer106may allow the application110of the card network108to perform stand-in processing of ATM-based transactions only. The issuer106is not excluded from setting stand-in parameters at the BIN level, rather, the present method provides additional mechanisms to select a transaction for stand-in processing.

The issuer106also provides one or more rules to the application110for stand-in processing of the transaction. For example, a rule may specify a maximum transaction amount that can be subjected to stand-in processing. Another rule may specify the maximum number of transactions permitted over a specified period, e.g. one day, one week, or one month. Other rules may be prescribed by the issuer106as appropriate such that, together with the stand-in parameters, the issuer106has overall system management rights.

Furthermore, the issuer106shares the relevant keys, such as the zone control master key (ZCMK) with the application or module110for secure processing. For example, the ZCMK can be the PIN Verification Key (PVK) and/or the Card Verification Key 1 (CVK 1). The sharing of the zonal key can facilitate the PVK and CVK values to be transferred from the issuer106to stand-in application or module110.

FIG. 3shows a schematic diagram300illustrating an example configuration of the method and system of the example embodiments. During operation, a server302of the card network108(FIG. 1) receives a message compliant with ISO 8583 containing transaction data of the transaction, which may be a POS device-based transaction304, a web-based transaction306, or an ATM-based transaction308. The server302determines, based on the POS entry mode value of the data element22and the stand-in parameters set up by the issuer106(FIG. 1), whether the transaction should be selected for stand-in processing. If the transaction does not qualify for stand-in processing, the message is routed to the issuer106. On the other hand, if the transaction qualifies for stand-in processing, the message is handled by a stand-in service310of the card network108. The stand-in service310applies the rule(s) provided by the issuer106and either approves or declines the transaction. Typically, the card network then communicates the outcome of the processing to the acquirer104(FIG. 1).

The method and system of the example embodiments can thus provide more options to customize stand-in processing of a transaction, particularly based on the POS entry mode. The issuer can maintain overall control by determining the stand-in requirements such that stand-in processing can kick in to avoid the possibility of a transaction being declined in the event that the issuer's server is down or disrupted. The method and system of the example embodiments can also minimize the load of processing Low Value Transactions, can set up rules for the Stand-In services to take action on such transactions.

FIG. 4depicts an exemplary computing device400, hereinafter interchangeably referred to as a computer system400, where one or more such computing devices400may be used for the server302, the acquirer's system or the issuer's system. The following description of the computing device400is provided by way of example only and is not intended to be limiting.

As shown inFIG. 4, the example computing device400includes a processor404for executing software routines. Although a single processor is shown for the sake of clarity, the computing device400may also include a multi-processor system. The processor404is connected to a communication infrastructure406for communication with other components of the computing device400. The communication infrastructure406may include, for example, a communications bus, cross-bar, or network.

The computing device400further includes a main memory408, such as a random access memory (RAM), and a secondary memory410. The secondary memory410may include, for example, a hard disk drive412and/or a removable storage drive414, which may include a floppy disk drive, a magnetic tape drive, an optical disk drive, or the like. The removable storage drive414reads from and/or writes to a removable storage unit418in a well-known manner. The removable storage unit418may include a floppy disk, magnetic tape, optical disk, or the like, which is read by and written to by removable storage drive414. As will be appreciated by persons skilled in the relevant art(s), the removable storage unit418includes a computer readable storage medium having stored therein computer executable program code instructions and/or data.

In an alternative implementation, the secondary memory410may additionally or alternatively include other similar means for allowing computer programs or other instructions to be loaded into the computing device400. Such means can include, for example, a removable storage unit422and an interface420. Examples of a removable storage unit422and interface420include a program cartridge and cartridge interface (such as that found in video game console devices), a removable memory chip (such as an EPROM or PROM) and associated socket, and other removable storage units422and interfaces420which allow software and data to be transferred from the removable storage unit422to the computer system400.

The computing device400also includes at least one communication interface424. The communication interface424allows software and data to be transferred between computing device400and external devices via a communication path426. In various embodiments of the disclosure, the communication interface424permits data to be transferred between the computing device400and a data communication network, such as a public data or private data communication network. The communication interface424may be used to exchange data between different computing devices400which such computing devices400form part an interconnected computer network. Examples of a communication interface424can include a modem, a network interface (such as an Ethernet card), a communication port, an antenna with associated circuitry and the like. The communication interface424may be wired or may be wireless. Software and data transferred via the communication interface424are in the form of signals which can be electronic, electromagnetic, optical or other signals capable of being received by communication interface424. These signals are provided to the communication interface via the communication path426.

As shown inFIG. 4, the computing device400further includes a display interface402which performs operations for rendering images to an associated display430and an audio interface432for performing operations for playing audio content via associated speaker(s)434.

As used herein, the term “computer program product” may refer, in part, to removable storage unit418, removable storage unit422, a hard disk installed in hard disk drive412, or a carrier wave carrying software over communication path426(wireless link or cable) to communication interface424. Computer readable storage media refers to any non-transitory tangible storage medium that provides recorded instructions and/or data to the computing device400for execution and/or processing. Examples of such storage media include floppy disks, magnetic tape, CD-ROM, DVD, Blu-ray™ Disc, a hard disk drive, a ROM or integrated circuit, USB memory, a magneto-optical disk, or a computer readable card such as a PCMCIA card and the like, whether or not such devices are internal or external of the computing device400. Examples of transitory or non-tangible computer readable transmission media that may also participate in the provision of software, application programs, instructions and/or data to the computing device400include radio or infra-red transmission channels as well as a network connection to another computer or networked device, and the Internet or Intranets including e-mail transmissions and information recorded on Websites and the like.

The computer programs (also called computer program code) are stored in main memory408and/or secondary memory410. Computer programs can also be received via the communication interface424. Such computer programs, when executed, enable the computing device400to perform one or more features of embodiments discussed herein. In various embodiments, the computer programs, when executed, enable the processor404to perform features of the above-described embodiments. Accordingly, such computer programs represent controllers of the computer system400.

Software may be stored in a computer program product and loaded into the computing device400using the removable storage drive414, the hard disk drive412, or the interface420. Alternatively, the computer program product may be downloaded to the computer system400over the communications path426. The software, when executed by the processor404, causes the computing device400to perform functions of embodiments described herein.

It is to be understood that the embodiment ofFIG. 4is presented merely by way of example. Therefore, in some embodiments one or more features of the computing device400may be omitted. Also, in some embodiments, one or more features of the computing device400may be combined together. Additionally, in some embodiments, one or more features of the computing device400may be split into one or more component parts.

It will be appreciated that the elements illustrated inFIG. 4function to provide means for performing the various functions and operations of the servers as described in the above embodiments.

In an implementation, a server may be generally described as a physical device including at least one processor and at least one memory including computer program code. The at least one memory and the computer program code are configured to, with the at least one processor, cause the physical device to perform the requisite operations.

It will be appreciated by a person skilled in the art that numerous variations and/or modifications may be made to the present disclosure as shown in the specific embodiments without departing from the spirit or scope of the disclosure as broadly described. The present embodiments are, therefore, to be considered in all respects to be illustrative and not restrictive.