Method and apparatus for reducing fraudulent credit transactions by requiring merchant return of multi-digit authorization codes

[0001] This application claims the benefit of U.S. Provisional Application No. 60/572,585, filed May 19, 2004, which is hereby incorporated by reference herein in its entirety.

[0002] 1. Field of the Invention

[0003] This invention generally relates to data processing for business practices, and in particular it relates to financial transaction processing.

[0004] 2. Background Art

[0005] Submission of fraudulent records of charge (ROCs) account for a significant proportion of the incidence of credit card transaction fraud. In order to combat this, credit providers (such as credit card issuers) have been seeking to implement processes by which false submissions of ROCs are reduced, without unduly impacting the time it takes to authorize a legitimate credit transaction.

[0006] One known solution, implemented by certain credit providers such as American Express Co. of New York, N.Y., involves generating a two-digit authorization code for each credit transaction, that can be transmitted with a credit approval. The authorization code could then be stored by the credit provider and referenced in the case of a charge dispute or the like. However, there are various limitations to the protection afforded by such a method.

[0007] First, the two-digit codes in such systems only include a limited range of possible character strings. In the context of the hundreds of millions of credit transactions that are conducted annually, these limited number of codes will be repeated often, making it easier to fake or forge a two-digit approval in connection with fraudulent ROCs.

[0008] Second, the determination of fraudulent charge submissions is limited and credit dispute resolution is continuously delayed by the time it takes for a credit provider to retrieve authorization code information from its records and determine a transaction's authenticity.

[0009] Finally, not all merchants in today's transaction networks are equipped to receive and resubmit authorization codes. In early 2003, over 11% of U.S. credit transactions were submitted for payment without a valid authorization code. This gap leaves credit providers open to further fraudulent charge submissions.

[0010] It would be possible for a credit provider to simply reject any merchant request for payment up front when it is submitted without the authorization code. However, a significant proportion of charge volume could needlessly be lost since the majority of such submissions are legitimate. This, in turn, could negatively impact a credit provider's revenues. Accordingly, there is a need for a method and apparatus for reducing fraudulent credit transactions that addresses the above-described problems and short-comings in existing methodologies.

[0011] Fraudulent credit transactions may be reduced by requiring merchant return of multi-digit authorization codes. In particular, one aspect of the disclosure includes a merchant payment process by which a merchant completes a credit transaction with a customer. The merchant transmits a credit transaction request, including a transaction amount and an identification of a customer's credit account, to the credit provider maintaining the customer's credit account. The credit provider responds with an approval for the credit transaction when the customer's credit account is in good standing. The approval includes a multi-digit authorization code (e.g., a six-digit alphanumeric code). When the merchant later submits a request for payment for the approved credit transaction request, the merchant may be flagged as subject to a chargeback if the received request does not include the multi-digit authorization code as provided with the approval, as lack of a proper authorization code may be evidence of a fraudulent charge. In addition, a dispute of the credit transaction subsequently received from a customer associated with the credit account may be seen as further evidence of a fraudulent charge. Therefore, if a credit transaction involving a flagged merchant is disputed by the customer associated with the credit account at issue, a chargeback may be assessed against the merchant by the credit provider.

[0012] Further embodiments, features, and advantages of the present invention, as well as the structure and operation of the various embodiments of the present invention, are described in detail below with reference to the accompanying drawings.

[0016] The present invention will be described with reference to the accompanying drawings. The drawing in which an element first appears is typically indicated by the leftmost digit(s) in the corresponding reference number.

[0017] While specific configurations and arrangements are discussed, it should be understood that this is done for illustrative purposes only. A person skilled in the pertinent art will recognize that other configurations and arrangements can be used without departing from the spirit and scope of the present invention. It will be apparent to a person skilled in the pertinent art that this invention can also be employed in a variety of other applications.

[0018] The terms “merchant” as used herein shall mean any person, entity, distributor system, software, and/or hardware that is a provider, broker, and/or any other entity in the distribution chain of goods or services. For example, a merchant may be a grocery store, a retail store, a travel agency, a service provider, an online merchant, or the like.

[0019] Referring now to FIGS. 1-2, wherein similar components of the present disclosure are referenced in like manner, various embodiments of a method and system for reducing fraudulent credit transactions are disclosed, in which merchants are required to return multi-digit authorization codes supplied by credit providers (e.g., issuers) with credit transaction approvals.

[0020] A goal of the processes disclosed herein is to more readily assess chargebacks to merchants for unpaid transactions (once merchants are properly notified of the requirement) in order to encourage the submission of authorization codes with all merchant payment requests, thereby reducing the possibility of successful attempts to submit fraudulent ROCs. This simplifies prior processes, in which unpaid or disputed ROCs were evaluated according to certain standards, such as threshold transaction amounts, chargeback time-frames, or first-in-first-out processes, before chargebacks could be assessed, thus increasing the costs associated with resolving unpaid credit transactions.

[0021] The processes disclosed herein decrease such costs by providing longer authorization codes that are more difficult to forge. Such authorization codes may also be confirmed from the submission of ROCs themselves, thus reducing time to recall and verify stored records. If the submitted authorization code is blank, all zeros, any combination other than the prescribed number of digits, or includes one or more invalid characters, the merchant is flagged immediately upon submission as liable for chargeback. This has the benefit of automating the chargeback process and assessing chargeback fees more expediently, when submitted transactions are disputed or otherwise remain unpaid. This, in turn, should encourage merchants to more readily comply with the authorization code scheme.

[0022] The present invention or any part(s) or function(s) thereof may be implemented using hardware, software, or a combination thereof and may be implemented in one or more computer systems or other processing systems. No capability of a human operator is necessary, or desirable in most cases, in any of the operations described herein which form part of the present invention. Rather, the operations are machine operations. Useful machines for performing the operation of the present invention include general purpose digital computers or similar devices.

[0023] Turning now to FIG. 1, there is depicted an exemplary communication network 100, over which the processes of the present disclosure may be performed. The network 100 may be any known type of financial transaction network over which today's credit transactions are currently implemented. Such systems typically include a credit provider's server 102 that intercommunicates financial transaction and related data with a plurality of merchant servers 104, either directly or through a third party payment processing server 106. Merchant servers 104 and third party payment processing server 106 include similar components as credit provider's server 102, as described below.

[0024] Credit provider's server 102 includes one or more processors, such as processor 108. The processor 108 is connected to a communications infrastructure 110 (e.g., a communications bus, cross-over bar, or network). Various software embodiments are described in terms of this exemplary communication network. After reading this description, it will become apparent to a person skilled in the relevant art(s) how to implement the invention using other computer systems and/or architectures.

[0025] Server 102 also includes a main memory 112, such as random access memory (RAM), and may also include a secondary memory 114. Secondary memory 114 may include, for example, a hard disk drive 116 and/or a removable storage drive 118, such as and without limitation, a floppy disk drive, a magnetic tape drive, or an optical disk drive. Removable storage drive 118 reads from and/or writes to a removable storage unit 120 in a well known manner.

[0026] Removable storage unit 120 may be, for example and without limitation, a floppy disk, magnetic tape, or an optical disk, which is read by and written to removable storage drive 118. As will be appreciated, removable storage unit 120 includes a computer usable storage medium having stored therein computer software and/or data.

[0027] In alternative embodiments, secondary memory 114 may include other similar devices for allowing computer programs or other instructions to be loaded onto server 102. Such devices may include, for example and without limitation, a removable storage unit and an interface. Examples of such include a program cartridge and cartridge interface, a removable memory chip (such as an erasable programmable read only memory (EPROM), or programmable read only memory (PROM)) and associated socket, and other removable storage units and interfaces which allow software and data to be transferred from the removable storage unit to server 102.

[0028] Server 102 may also include a communications interface 122. Communications interface 122 allows software and data to be transferred between server 102 and external devices, such as servers 104 and/or 106. Examples of communications interface 122 may include a modem, a network interface (such as an Ethernet card), a communications port, a Personal Computer Memory Card International Association (PCMCIA) slot and card, etc. Software and data transferred via communications interface 122 are in the form of signals which may be electronic, electromagnetic, optical, or other signals capable of being received by communications interface 122. These signals are provided to communications interface 122 over communication infrastructure 110. Communications infrastructure 110 may be implemented using wire or cable, fiber optics, a telephone line, a cellular link, a radio frequency (RF) link, and/or other communications channels. Alternatively, communications infrastructure 110 may be a wireless communications infrastructure.

[0029] In this document, the terms “computer program medium” and “computer usable medium” are used to generally refer to media such as removable storage unit 120, a hard disk installed in hard disk drive 116, removable memory chips, cartridges and the like, and the signals sent over communications interface 110. These computer program products provide software to server 102.

[0030] Computer programs (also referred to as computer control logic) are stored in main memory 112 and/or secondary memory 114. Computer programs may also be received via communications interface 122. Such computer programs, when executed, enable server 102 to perform the features of the present invention, as discussed herein. In particular, the computer programs, when executed, enable the processor 108 to perform the features of the present invention. Accordingly, such computer programs represent controllers of server 102.

[0031] In an embodiment where the invention is implemented using software, the software may be stored in a computer program product and loaded onto server 102 using, for example, removable storage drive 118, hard drive 116, or communications interface 122. The control logic, when executed by processor 108, causes processor 108 to perform the functions of the invention as described herein.

[0032] In another embodiment, the invention is implemented primarily in hardware using, for example, hardware components such as application specific integrated circuits (ASICs). Implementation of the hardware state machine so as to perform the functions described herein will be apparent to persons skilled in the relevant art(s).

[0033] In yet another embodiment, the invention is implemented using a combination of both hardware and software.

[0034] Referring to FIG. 2, therein is depicted an exemplary merchant payment process 200 performed between a merchant and a credit card provider over the communications network 100 of FIG. 1. Process 200 commences after a customer enters into a financial transaction, such as a credit card payment transaction, with a merchant.

[0035] With regard to use of a credit account, users may communicate with merchants in person (e.g., at the box office), telephonically, or electronically (e.g., from a user computer via the Internet). During the interaction, the merchant may offer goods and/or services to the user. The merchant may also offer the user the option of paying for the goods and/or services using any number of available credit accounts. Furthermore, the credit accounts may be used by the merchant as a form of identification of the user. The merchant may have a computing unit implemented in the form of a computer-server, although other implementations are possible.

[0036] In general, credit accounts may be used for transactions between the user and merchant through any suitable communication means, such as, for example, a telephone network, intranet, the global, public Internet, a point of interaction device (e.g., a point of sale (POS) device, personal digital assistant (PDA), mobile telephone, kiosk, etc.), online communications, off-line communications, wireless communications, and/or the like.

[0037] The merchant initially, in step 202, submits a request for approval of the credit transaction. Such request may be transmitted, for example, from one of merchant servers 104 to credit provider's server 102.

[0038] Next, at step 204, the credit provider that maintains the customer's credit account may provide an approval of the requested transaction in response to the merchant's request. The approval may be provided when the customer's account is in good standing, and the submitted request includes known, standard transaction information needed to approve the request. Such standard transaction information may include, for example and without limitation, the transaction amount and a proper identification of the customer's credit account. An “account” or “account number”, as used herein, may include any device, code, number, letter, symbol, digital certificate, smart chip, digital signal, analog signal, biometric or other identifier/indicia suitably configured to allow a consumer to access, interact with, or communicate with a financial transaction system. The account number may optionally be located on or associated with any financial transaction instrument (e.g., rewards, charge, credit, debit, prepaid, telephone, embossed, smart, magnetic stripe, bar code, transponder, or radio frequency card).

[0039] The approval further includes an authorization code that is generated, for example, by the credit provider server 102 or by the third-party payment processing server 106. In order to minimize the possibility of successfully submitting fraudulent authorization codes with ROCs, it is preferred that the authorization code be at least three digits, and preferably be six digits or more, in order to reduce the number of times such codes are repeated in annual credit transactions. With a six-digit authorization code having only numeric characters, for example, a million credit transactions may be processed without repeating any codes. However, a person of skill in the pertinent art will recognize that the authorization code may include alphabetic, alphanumeric, or other types of characters as well.

[0040] The authorization code may be generated randomly with each transaction and stored for later reference. Alternatively, the authorization code may include encrypted information that may be decoded to reveal information that correlates to the customer account, for more ready verification. Such encryption may be carried out in any of a variety of well-known manners, and the customer account information that is encrypted may be varied from transaction to transaction, in order to decrease the likelihood of successful fraudulent submissions of authorization codes.

[0041] Next, at step 206 of process 200, the merchant submits an ROC to the credit provider for payment. The ROC may or may not include a valid authorization code. This may occur at any time after the customer has completed the initial transaction. The ROC for a particular transaction may be submitted alone or with ROCs from a number of other transactions.

[0042] In step 208, the credit provider then determines whether a valid authorization code has been submitted by the merchant. If so, process 200 continues to step 216 below. Otherwise, process 200 continues to step 210.

[0043] In step 210, the submitted transaction and/or the merchant is flagged immediately for possible chargeback. For example, the merchant may be given a chargeback status based on receipt of the valid authorization code.

[0044] Next, at step 212, the credit provider monitors whether the submitted credit transaction is disputed or is otherwise unpaid by the customer. The monitoring may occur during a certain threshold time interval (e.g., 30 days). If, during the certain threshold time interval, there is a dispute of the transaction or the transaction is otherwise identified as fraudulent, process 200 may proceed immediately to step 214. In step 214, a chargeback fee is assessed against the merchant for the submitted transaction.

[0045] In step 216, the merchant is provided with the requested payment. Step 216 occurs if a valid authorization code is included with the transmitted ROC from step 206. Step 216 also occurs if no disputes arise after the threshold time interval or if the transaction is paid by the customer.

[0046] After step 214 or step 216, process 200 ends with respect to that transaction.

[0047] Implementation of a process similar to process 200 above by a credit provider may result in an immediate increase in merchant chargeback fees related to non-compliance. However, over time, merchant compliance should dramatically increase, thus making the financial processing system more secure.

[0048] Although the best methodologies of the invention have been particularly described in the foregoing disclosure, it is to be understood that such descriptions have been provided for purposes of illustration only. For example, although the above description speaks of credit card accounts, it will be understood by those in the relevant art(s) that the present invention may be implemented in conjunction with any transaction account. A “transaction account” as used herein refers to an account associated with an open account or a closed account system. The transaction account may exist in a physical or non-physical embodiment. For example, a transaction account may be distributed in non-physical embodiments such as an account number, frequent-flyer account, telephone calling account or the like. Furthermore, a physical embodiment of a transaction account may be distributed as a financial instrument.

[0049] A financial transaction instrument may be traditional plastic transaction cards, titanium-containing, or metal-containing, transaction cards, clear and/or translucent transaction cards, foldable or otherwise unconventionally-sized transaction cards, radio-frequency enabled transaction cards, or other types of transaction cards, such as credit, charge, debit, pre-paid or stored-value cards, or any other like financial transaction instrument. A financial transaction instrument may also have electronic functionality provided by a network of electronic circuitry that is printed or otherwise incorporated onto or within the transaction instrument (and typically referred to as a “smart card”), or be a fob having a transponder and an RFID reader.

[0050] Thus, other variations both in form and in detail can be made thereupon by those skilled in the art without departing from the spirit and scope of the present invention, which is defined first and foremost by the appended claims.