AU2014204560B2 - Secure channel payment processing system and method - Google Patents

Secure channel payment processing system and method Download PDF

Info

Publication number
AU2014204560B2
AU2014204560B2 AU2014204560A AU2014204560A AU2014204560B2 AU 2014204560 B2 AU2014204560 B2 AU 2014204560B2 AU 2014204560 A AU2014204560 A AU 2014204560A AU 2014204560 A AU2014204560 A AU 2014204560A AU 2014204560 B2 AU2014204560 B2 AU 2014204560B2
Authority
AU
Australia
Prior art keywords
transaction
server
information
response
payment
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Ceased
Application number
AU2014204560A
Other versions
AU2014204560A1 (en
Inventor
Laure Canis
Cedric Florimond
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Amadeus SAS
Original Assignee
Amadeus SAS
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Priority claimed from EP13290173.7A external-priority patent/EP2830014A1/en
Priority claimed from US13/949,019 external-priority patent/US20150032617A1/en
Application filed by Amadeus SAS filed Critical Amadeus SAS
Publication of AU2014204560A1 publication Critical patent/AU2014204560A1/en
Application granted granted Critical
Publication of AU2014204560B2 publication Critical patent/AU2014204560B2/en
Ceased legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00Payment architectures, schemes or protocols
    • G06Q20/38Payment protocols; Details thereof
    • G06Q20/40Authorisation, e.g. identification of payer or payee, verification of customer or shop credentials; Review and approval of payers, e.g. check credit lines or negative lists
    • G06Q20/401Transaction verification
    • G06Q20/4016Transaction verification involving fraud or risk level assessment in transaction processing
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00Payment architectures, schemes or protocols
    • G06Q20/08Payment architectures
    • G06Q20/10Payment architectures specially adapted for electronic funds transfer [EFT] systems; specially adapted for home banking systems
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00Payment architectures, schemes or protocols
    • G06Q20/38Payment protocols; Details thereof
    • G06Q20/42Confirmation, e.g. check or permission by the legal debtor of payment
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q50/00Information and communication technology [ICT] specially adapted for implementation of business processes of specific business sectors, e.g. utilities or tourism
    • G06Q50/10Services
    • G06Q50/14Travel agencies

Landscapes

  • Business, Economics & Management (AREA)
  • Accounting & Taxation (AREA)
  • Engineering & Computer Science (AREA)
  • Strategic Management (AREA)
  • Theoretical Computer Science (AREA)
  • Finance (AREA)
  • General Physics & Mathematics (AREA)
  • General Business, Economics & Management (AREA)
  • Physics & Mathematics (AREA)
  • Tourism & Hospitality (AREA)
  • Economics (AREA)
  • Primary Health Care (AREA)
  • Marketing (AREA)
  • Health & Medical Sciences (AREA)
  • General Health & Medical Sciences (AREA)
  • Development Economics (AREA)
  • Human Resources & Organizations (AREA)
  • Computer Security & Cryptography (AREA)
  • Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)

Abstract

The present invention relates to a method and system for performing fraud screening and choosing whether to accept or deny a transaction within any channel. The system may facilitate the fraud screening processing for the case where this channel is the offline card not present 5 channel, which may be utilized for call center transactions. The system may include a server that receives a transaction request and performs a first fraud screening based on transaction information of the requested transaction. The server may further determine which operation to perform: whether to issue a final response right away (accept, reject) or whether to gather more information before issuing a final response. The information gathering may be an authentication method only usable in another channel (online channel or offline card present channel). The server may create an asynchronous payment, which secures the reservation of the good, while allowing performing the new channel authentication at a later time. Depending on the information gathering results, the server further determines which operation to perform: whether to issue a final response right away (accept, reject) or whether to gather information a second time before issuing a final response. This second information gathering may be a manual review. The system may provide for the selecting an operation flow based on the transaction information. User input a voice transaction request Call center receives the voice transaction request Payment server receives the transaction request Payment server checks whether the payment instrument is enrolled in an authentication program Rejects the transaction Payment server performs a 460 fraud screen Accepts the transaction 4t 470 Request more information FIG. 2(A)

Description

I SECURE CHANNEL PAYMENT PROCESSING SYSTEM AND METHOD CROSS REFERENCE TO RELATED APPLICATIONS 3 This application is related to co-pending application no. 13/786,497 titled "Fraud Decision Processing System and Method," the content of which is incorporated by reference in its entirety. TECHNICAL FIELD The present invention relates to a method and a system to perform fraud decision processing for call-center transaction requests. BACKGROUND Merchants need to reduce the number of fraudulent transactions because when a fraud occurs, they are responsible for reimbursing the amounts of fraudulent transactions to the real credit card holder. Thus, a payment system performs a fraud screening to reduce fraud. Based on transaction information such as the amount of the transaction, location of the sale, IP address of the requesting device, whether the credit card is on a black list and even data on repeated transactions with the same credit card number, email, or name (velocity checks), the fraud screening service provider may deny the requested transaction, allow the requested transaction, or direct the requester for manual review. For a manual review, the system waits for additional information. In an example of airline ticket purchase, the transaction information may further include the origin, destination, and time before departure. 5 One type of fraud screening is a non-predictive fraud screening, where the system relies on rules input by the merchant to determine which result to output based on the information at its disposal. The response can be: "Accept", "Deny", "Challenge". One type of fraud screening is a predictive fraud screening, where the system does not rely on rules input by the merchant to determine which result to output, but builds a predictive 2 model for detecting fraud based on historical information. The system, then determines a probability of fraud based on this predictive model and the transaction information. Another type of fraud-prevention measure is an authentication of the payment instrument, such as a credit card or debit card. 5 An example of such type of payment instrument authentication is the 3-D Secure@ authentication protocol developed by Visa@ and adopted by MasterCard@. A password may be provided to user for authentication. One added feature of this type of authentication is the shift in fraud cost. When the payment instrument is enrolled in the 3-D Secure@ authentication program and that authentication is performed successfully, the cost of fraud is 10 shifted to the issuing bank of the instrument. Accordingly, merchants are willing to use the 3-D Secure@ authentication. Today, this authentication method can only be used for online payments. Another example of such authentication is the EMV verification process. EMV stands for Europay, MasterCard@ and Visa@ and is a global standard for inter-operation of 15 integrated circuit cards (IC cards or "chip cards") for authenticating credit and debit card transactions. One implementation of EMV cards confirms the identity of the cardholder by requiring the entry of a PIN (Personal Identification Number). Today, this authentication method can only be used for offline card present, which may include face to face payments. Both the offline card present channel and the online channel possess an optimal way 20 of processing card payments and minimizing the total cost of fraud. For the offline card present channel, EMV authentication is ideal: fraud rates are low, fraud liability is shifted to the issuing bank of the instrument, and there are minimal lost sales. For the online channel, the "Fraud Decision Processing System and Method" presented how 3-D Secure@ authentication could be combined with fraud screening to considerably improve the final 25 acceptance or rejection decision through additional information. There is a need for a similar process in the case of offline card not present transactions (e.g., in call-centers, where a voice transaction requested may be entered via a telephone). SUMMARY 30 According to an aspect of the present invention, there is provided a processing system comprising: 2a a first server of a call center, the first server including an interactive voice response system; and a second server in communication with the first server, the second server being a payment server; 5 wherein the first server: receives a transaction request from a user using the interactive voice response system; and in response to receiving the transaction request, transmits the transaction request and transaction information to the second server, the transaction information 10 defining a payment instrument, a good or service requested, and an amount of the transaction; and wherein the second server, in response to receiving the transaction request and the transaction information: 15 verifies whether the payment instrument is enrolled in an authentication program by transmitting the transaction information to, and receiving a response from, an authentication service provider server; performs a fraud screening by transmitting the transaction request and the transaction information to, and receiving a fraud screening result from, a fraud 20 screening service provider server, the fraud screening result including an instruction to accept the transaction request, reject the transaction request, or gather information; in response to the instruction being to gather information and the payment instrument being enrolled in the authentication program, reserves the good or service requested and provides a time limit to the user for providing the information; 25 in response to the user providing the information before the time limit, completes the transaction; and in response to the user not providing the information before the time limit, cancels the reservation. According to another aspect of the present invention, there is provided a 30 computer-implemented method for secure channel payment processing, the method comprising: receiving, by a first server including an interactive voice response system, a transaction request from a user by voice; 2b in response to receiving the transaction request, transmitting, by the first server, the transaction request and transaction information to a second server, the transaction information defining a payment instrument, a good or service requested, and an amount of the transaction; in response to receiving the transaction request and the transaction information at the 5 second server, verifying, by the second server, whether the payment instrument is enrolled in an authentication program by transmitting the transaction information to, and receiving a response from, an authentication service provider server; performing, by the second server, a fraud screening by transmitting the transaction request and the transaction information to, and receiving a fraud screening result from, a fraud 10 screening service provider server, the fraud screening result including an instruction to accept the transaction request, reject the transaction request, or gather information; in response to the instruction being to gather information and the payment instrument being enrolled in the authentication program, reserving, by the second server, the good or service requested and providing, by the second server, a time limit to the user for providing 15 the information; in response to the user providing the information before the time limit, completing, by the second server, the transaction; and in response to the user not providing the information before the time limit, canceling, by the second server, the reservation. 20 CONTINUES ON PAGE 3 3 The computer-implemented secure channel payment processing system, after an initial fraud screening, may allow the requested transaction right away, deny the requested transaction right away, or require authentication which will be performed through a shift of channel to the online channel or offline card present channel. The choice of which channel shift to use can be 5 based on whether the payee has an internet connection or not. In certain embodiments, the online channel can be used as the default choice, unless the payee has no internet connection, and in this case the offline card present channel will be used. In the case where authentication is required, depending on the result of authentication, the computer-implemented secure channel payment processing system may allow the requested ) transaction, deny the requested transaction, or request more information. In the case where more information is requested, depending on the information results, the computer-implemented secure channel payment processing system may finally allow the requested transaction or deny the requested transaction. In the case where the fraud screening is of a predictive type, the choice of which flow to follow can be based on at least one of the following factors: the probability of fraud output by the predictive fraud screening engine, a cost for processing a chargeback, a cost for gathering more information, a cost of lost sales for a false fraud detection, a probability of causing a timeout for an action performed as part of the information gathering, a false negative rate and a false positive rate of the authentication processes and the manual review process. In the case where the fraud screening is not of a predictive type, the computer implemented secure channel payment processing system may allow the requested transaction, deny the requested transaction if the fraud screening engine response is "Accept" or "Deny", or ask for authentication through a channel shift if the response is "Challenge". In the latter case, the computer-implemented secure channel payment processing performs a second call to the 5 fraud screening engine, which gives a response based on the authentication results. This response can be "Accept" or "Deny", in this case the computer-implemented secure channel payment processing system may allow the requested transaction or deny the requested transaction, or it can be "Challenge": in this case information gathering is performed. In the latter case, the computer-implemented secure channel payment processing performs a third call to the fraud screening engine, which gives a final response based on the information gathering results. This 4 response can be "Accept" or "Deny", the computer-implemented secure channel payment processing system may finally allow the requested transaction or deny the requested transaction. In the case where authentication through another channel, is required, the authentication does not have to be real-time and the booking may be guaranteed until the payment deadline. 5 In certain embodiments, the authentication for the online channel may be a 3-D Secure® authentication. In certain embodiments, the authentication for the offline card present channel may be an EMV@ authentication. In certain embodiments, the information gathering may be a manual review. In certain embodiments, there may even be a fourth alternative after the first fraud screening on top of allowing the requested transaction, denying the requested transaction, or performing an authentication: perform information gathering. In certain embodiments, this information gathering could be a manual review. In certain embodiments, there may be more than two authentication or information gathering operations before a final acceptance or rejection decision is made. In certain embodiments, a 3-D Secure® enrollment verification may be performed before the first fraud screening. The computer-implemented secure channel payment processing system may include a server communicating with a terminal and computer readable medium. The computer implemented secure channel payment processing system may receive a transaction request which is by voice, and may perform a payment instrument authentication. Based on the payment instrument authentication, the system may perform one of the following functions: allowing the requested transaction; rejecting the requested transaction; and requesting for more information Requesting for more information may include performing a fraud screen with information from 5 the payment instrument authentication. The system may reserve a purchase of the requested transaction before a payment of the requested transaction. The computer-implemented secure channel payment processing system may perform a fraud screen. Accordingly, the system may perform one of the following functions as a result to the fraud screen: allowing the requested transaction; rejecting the requested transaction; and requesting more information. The computer-implemented secure channel payment processing system may generate asynchronous payment processing in response to the result of the fraud 5 screen. The system may generate asynchronous payment processing when the result of the fraud screen is requesting more information. The function of requesting more information may include performing a payment instrument authentication. The system may perform payment instrument authentication based on a value determined by the fraud screen. The value determined by the 5 fraud screen may be a probability of fraud. Based on the payment instrument authentication, the system may perform one of the following functions: allowing the requested transaction, and rejecting the requested transaction. Based on the payment instrument authentication, the system performs one of the following functions: allowing the requested transaction, and requesting for more information. Requesting more information includes performing the fraud screen with information from the payment instrument authentication. In another embodiment, the computer-implemented secure channel payment processing system may include a server communicating with a terminal and a computer readable medium. The system may receive a voice transaction request, and may perform a payment instrument authentication of the requested transaction. Based upon the payment instrument authentication, the system may perform one of the following functions: allowing the requested transaction; and rejecting the requested transaction. Based on the payment system authentication, the system may also perform on of the following functions: allowing the requested transaction; and requesting for more information. Requesting more information may include performing the fraud screen with information from the payment instrument authentication. In yet another embodiment, the payment processing of the requested transaction may include real-time processing of a payment. The voice transaction request may be made via a call center. The payment processing of the requested transaction may be performed electronically, and also the processing may not be performed electronically. 5 This Summary is provided to introduce a selection of concepts in a simplified form that are further described below in the Detailed Description. This Summary is not intended to identify key features or essential features of the claimed subject matter, nor is it intended to be used as an aid in determining the scope of the claimed subject matter. The details of one or more embodiments are set forth in the following detailed description of the invention and the accompanying drawings. Other objectives, features, and advantages of the invention will be 6 more readily understood upon consideration of the following Detailed Description of the invention, taken in conjunction with the accompanying drawings, and with the claims. DESCRIPTION OF THE DRAWINGS 5 The present invention is further described in the detailed description which follows, in reference to the noted plurality of drawings by way of non-limiting examples of certain embodiments of the present invention, in which like numerals represent like elements throughout the several views of the drawings, and wherein: FIG. 1 illustrates an embodiment of present invention. FIGS. 2(A) and 2(B) illustrate flows of embodiments of present invention. FIG. 3 illustrates one response flow of a payment instrument authentication. DETAILED DESCRIPTION OF EXEMPLARY EMBODIMENTS A detailed explanation of the system and method according to the preferred embodiments of the present invention are described below. The embodiments may take the form of a hardware embodiment, a software embodiment, or an embodiment combining software and hardware. In one embodiment, the present invention takes the form of a computer-program product that includes computer-useable instructions embodied on one or more computer-readable media. The various fraud screen and authentication techniques, methods, and systems described herein can be implemented in part or in whole using computer-based systems and methods. Additionally, computer-based systems and methods can be used to augment or enhance the functionality described herein, increase the speed at which the functions can be performed, and provide additional features and aspects as a part of or in addition to those described elsewhere in 5 this document. Various computer-based systems, methods and implementations in accordance with the described technology are presented below. One aspect of the present invention generally directs to a secure channel payment processing system. The secure channel includes one channel having a transaction request inputted or received by voice or audio. Referring to the computer-implemented secure channel payment processing system of FIG 1, the server 100, the client device, which may be a telephone 200, and the processor 110 may include a general-purpose computer and can have an internal or 7 external memory for storing data and programs such as an operating system (e.g., DOS, Windows 2000TM, Windows XPTM, Windows NTTM, OS/2, UNIX or Linux) and one or more application programs. Examples of application programs include computer programs implementing the techniques described herein for lyric and multimedia customization, authoring 5 applications (e.g., word processing programs, database programs, spreadsheet programs, or graphics programs) capable of generating documents or other electronic content; client applications (e.g., an Internet Service Provider (ISP) client, an e-mail client, or an instant messaging (IM) client) capable of communicating with other computer users, accessing various computer resources, and viewing, creating, or otherwise manipulating electronic content; and 3 browser applications (e.g., Microsoft's Internet Explorer) capable of rendering standard Internet content and other content formatted according to standard protocols such as the Hypertext Transfer Protocol (HTTP). One or more of the application programs can be installed on the internal or external storage of the general-purpose computer. Alternatively, in another embodiment, application programs can be externally stored in or performed by one or more 5 device(s) external to the general-purpose computer. In addition, client device, which may be a phone 200 may be or can include a landline phone, a wireless cell phone, a laptop computer or other mobile computing device, or any voice input device. The general-purpose computer may include a central processing unit (CPU) for executing instructions in response to commands, and a communication device for sending and receiving data. One example of the communication device is a modem. Other examples include a transceiver, a communication card, a satellite dish, an antenna, a network adapter, or some other mechanism capable of transmitting and receiving data over a communications link through a wired or wireless data pathway. 5 The general-purpose computer may also include an input/output interface that enables wired or wireless connection to various peripheral devices. Examples of peripheral devices include, but are not limited to, a mouse, a mobile phone, a personal digital assistant (PDA), a keyboard, a display monitor with or without a touch screen input, and an audiovisual input device. In another implementation, the peripheral devices may themselves include the ) functionality of the general-purpose computer. For example, the mobile phone or the PDA may include computing and networking capabilities and function as a general purpose computer by 8 accessing a network and communicating with other computer systems. Examples of a network, such as network 300, include the Internet, the World Wide Web, WANs, LANs, analog or digital wired and wireless telephone networks (e.g., Public Switched Telephone Network (PSTN), Integrated Services Digital Network (ISDN), and Digital Subscriber Line (xDSL)), radio, 5 television, cable, or satellite systems, and other delivery mechanisms for carrying data. A communications link can include communication pathways that enable communications through one or more networks. In one implementation, a processor-based system of the general-purpose computer can include a main memory, preferably random access memory (RAM), and can also include a secondary memory, which may be a tangible computer-readable medium 120. The secondary memory can include, for example, a hard disk drive or a removable storage drive, representing a floppy disk drive, a magnetic tape drive, an optical disk drive (Blu-Ray, DVD, CD drive), magnetic tape, paper tape, punched cards, standalone RAM disks, Iomega Zip drive, etc. The removable storage drive can read from or write to a removable storage medium. A removable storage medium can include a floppy disk, magnetic tape, optical disk (Blu-Ray disc, DVD, CD) a memory card (CompactFlash card, Secure Digital card, Memory Stick), paper data storage (punched card, punched tape), etc., which can be removed from the storage drive used to perform read and write operations. As will be appreciated, the removable storage medium can include computer software or data. In alternative embodiments, the secondary memory can include other similar means for allowing computer programs or other instructions to be loaded into a computer system. Such means can include, for example, a removable storage unit and an interface. Examples of such can include a program cartridge and cartridge interface (such as the found in video game devices), a removable memory chip (such as an EPROM or PROM) and associated socket, and 5 other removable storage units and interfaces, which allow software and data to be transferred from the removable storage unit to the computer system. Referring to FIG. 1, network 300 can also include a communications interface that allows software and data to be transferred between terminal 200, server 100, and the other components shown. The system components may also be stand-alone components that can communicate with each other, a centralized server 100, and/or the client device over network 300. Examples of communications interfaces can include a modem, a network interface (such as, for example, 9 an Ethernet card), a communications port, and a PCMCIA slot and card. Software and data transferred via a communications interface may be in the form of signals, which can be electronic, electromagnetic, optical or other signals capable of being received by a communications interface. These signals may be provided to a communications interface via a 5 channel capable of carrying signals and can be implemented using a wireless medium, wire or cable, fiber optics or other communications medium. Some examples of a channel can include a phone line, a cellular phone link, an RF link, a network interface, and other suitable communications channels. In this document, the terms "computer program medium" and "computer readable D medium" are generally used to refer to media such as a removable storage device, a disk capable of installation in a disk drive, and signals on a channel. These computer program products may provide software or program instructions to a computer system. Computer-readable media include both volatile and nonvolatile media, removable and non-removable media, and contemplate media readable by a database, a switch, and various 5 other network devices. Network switches, routers, and related components are conventional in nature, as are means of communicating with the same, By way of example, and not limitation, computer-readable media include computer-storage media and communications media. Computer-storage media, or machine-readable media, include media implemented in any method or technology for storing information. Examples of stored information include computer-useable instructions, data structures, program modules, and other data representations. Computer-storage media include, but are not limited to RAM, ROM, EEPROM, flash memory or other memory technology, CD-ROM, DVD, holographic media or other optical disc storage, magnetic cassettes, magnetic tape, magnetic disk storage, and other magnetic storage devices. These memory components can store data momentarily, temporarily, or permanently. 5 Communications media typically store computer-useable instructions - including data structures and program modules - in a modulated data signal. The term "modulated data signal" refers to a propagated signal that has one or more of its characteristics set or changed to encode information in the signal. An exemplary modulated data signal includes a carrier wave or other transport mechanism. Communications media include any information-delivery media. By way 0 of example but not limitation, communications media include wired media, such as a wired network or direct-wired connection, and wireless media such as acoustic, infrared, radio, 10 microwave, spread-spectrum, and other wireless media technologies. Combinations of the above are included within the scope of computer-readable media. Computer programs may be associated with applications, which may be stored in the main memory or secondary memory. Such computer programs can also be received via a 5 communications interface. Such computer programs, when executed, may enable the computer system to perform the features as discussed herein. In particular, the computer programs, when executed, may enable the processor to perform the described techniques. Accordingly, such computer programs may represent controllers of the computer system. In an embodiment where the elements are implemented using software, the software can ) be stored in, or transmitted via, a computer program product and loaded into a computer system using, for example, a removable storage drive, hard drive or communications interface, The control logic (software), when executed by the processor, may cause the processor to perform the functions of the techniques described herein. In another embodiment, the elements may be implemented primarily in hardware using, for example, hardware components such as PAL (Programmable Array Logic) devices, application specific integrated circuits (ASICs), or other suitable hardware components. Implementation of a hardware state machine so as to perform the functions described herein will be apparent to a person skilled in the relevant art(s). In yet another embodiment, elements may be implanted using a combination of both hardware and software. Referring to FIG. 1, the computer-based methods can be accessed or implemented over the World Wide Web by providing access via a Web Page to the methods described herein. Accordingly, the Web Page may be identified by a Universal Resource Locator (URL). The URL may denote both a server and a particular file or page on the server. One aspect of present invention provides a secure channel payment processing system 5 incorporating fraud screening and/or payment instrument authentication to the offline card not present channel (e.g., audio transaction request). FIG. I illustrates a system according to one embodiment of present invention. A payment server 100 includes a processor 110 and a tangible computer-readable medium 120, such as a disk drive or a flash memory system. The tangible computer-readable medium 120 stores programming which directs the processor and the payment server 100 to perform functions discussed below.
I I A telephone 200 communicates with a call center server 230 via a network 330. The phone 200 may be a landline telephone, cell phone, computer, or other voice-input or audio reproducing devices. Another example is a computer running a telephony app. In general, a telephone 200 is a device capable of inputting a transaction request via interactive voice response 5 (IVR) technology. A user inputs a voice transaction request via the telephone 200. The network 330 may be, e.g., the internet, public telephone network, and/or a computer network. The network 330 may also be a proprietary or local network. In this embodiment, the call center server 230 receives the voice transaction request via a telephone network (network 330), and uses interactive voice response (IVR) system to receive the voice transaction request. The payment server 100 communicates with the call center server 230 via a network 300 and receives the transaction request and transaction information. The transaction information includes, inter alia, the payment instrument (e.g. a credit card), and goods and services requested, and the amount of the transaction. The payment server 100 communicates with a fraud screening service provider server 210 via, e.g., a network 310. The network 310 may be, e.g., the internet a proprietary network, or a local network. The payment server 100 further communicates with an authentication service provider server 220, via a network 320. In a 3-D Secure@ authentication program, the authentication service provider server 220 may be the issuing bank of the payment instrument (e.g. credit card), or a service provider contracted by the issuing bank. The networks 300, 310, and/or 320 may be, e.g., the internet. The networks 300, 310, and/or 320 may also be a proprietary or local network. FIGS. 2(A) and 2(B) illustrate a flow diagram in accordance with an embodiment of present invention. The depicted flow processing may be associated with any fraud screening 5 engine, whether the engine be predictive or not. At 400, an offline user may input a voice transaction request (e.g., buying an airline ticket) using the telephone 200. At 410, the call center server 230 receives the voice transaction request via a telephone network (network 330) using interactive voice response (IVR) system. The call center server 230 then transmits the voice transaction request to the payment server 100 via the network 300.
12 At 420, the payment server 100, by the operation of the processor 110 and tangible computer-readable medium 120, receives request for a transaction (e.g., buying an airline ticket) and transaction information from the call center server 230 via the network 300. At 430, upon receiving the request for transaction, the payment server 100 verifies 5 whether the payment instrument for the enrolled transaction is enrolled in a payment instrument authentication program such as the 3-D Secure® authentication. In this embodiment, the payment server 100 transmits the transaction information (such as the credit card number) to the authentication service provider server 220, via a network 320. The authentication service provider server 220 responds with a result regarding whether the payment instrument is enrolled D in the authentication program. At 440, the payment server 100 performs the fraud screening by communicating with the fraud screening service provider server 210 via the network 310. Here, in particular, the payment server 100 performs the fraud screening by sending the requested transaction and transaction information to the fraud screen service provider server 210, and receives a result of 5 the fraud screening from the fraud screening service provider server 210. In another embodiment, the payment server 100 includes a fraud screening engine. The fraud screen engine determines the fraud screening result based on transaction information such as credit card number, amount paid, time of charge, and/or device used for the transaction (such as the IP address for the device). In an example airline ticket purchase, the transaction information may further include the destination, the particular flight, and the origin city. In the case of a non-predictive fraud screening, the fraud screening returns a result of allowing the transaction (470), rejecting the transaction (460), or requesting more information (480). Generally, the function of gather more information involves a request for more 5 information. Additional information on fraud screen is provided in opening "Fraud Screen System and Method" application. One aspect of present invention provides that the requesting more information function includes at least one of the features described below. For example, one aspect of present invention provides that the requesting more information function includes a payment instrument ) authentication such as 3D SecureT authentication, 13 The fraud screening service provider server 210 transmits a result of the fraud screening to the payment server 100, who will accept the transaction request, reject the transaction request, or gather more information. See FIG. 2B, for example, at 490, the payment determines the next action in requesting 5 more information function based on whether the payment instrument is enrolled in a payment authentication program (e.g. 3D SecureT")(see 430). In a case the payment instrument is not enrolled, the payment server 100 issues an allowance of the requested transaction (500). At 500, in a case the payment instrument is enrolled in a payment instrument authentication program, the payment server 100 generates an asynchronous processing. One D feature of asynchronous processing provides processing payment at a time later than the transaction request. The payment server 100 may further reserve the purchase of the requested transaction before the payment. E.g., in case of an airline ticket purchase, the flight is reserved. At 520, in a case the user does not provide an email address, the payment server 100 provides the time limit to the user via the call center 230 and telephone 200. At 550, the user fails to make payment within the time limit, and the system exits the requested transaction. E.g., the payment server cancels all the reservations relating to the requested transaction. At 520, the user completes the payment before the time limit, and the requested transaction is completed. One example of the payment is real-time, offline card present payment using EMV verification, which may include a face to face payment, At 530, the user provides an email address, and the payment server 100 provides the time limit and a link to the payment instrument authentication (e.g., 3D Secure TM) At 550, the user fails to make payment within the time limit, and the system exits the requested transaction. E.g., the payment server cancels all the reservations relating to the 5 requested transaction. The user enters the payment information and accesses payment instrument authentication (600). In one embodiment, the user performs the payment instrument authentication without involving the payment server 100, and the payment instrument authentication server provides the results to the payment server 100. In another embodiment, the payment instrument ) authentication was conducted via the payment server 100 and the payment instrument authentication server.
14 FIG. 3 illustrates a flow diagram when performing the payment instrument authentication. Based on a result from the fraud screen and transaction information (such as the value of the transaction), the payment server or the system selects one of these three responses after the payment instrument authentication. 5 At 600, payment instrument authentication (such as 3D SecureTM authentication) is performed. At 610, the requested transaction is allowed according to the result of the payment instrument authentication. At 620, the requested transaction is denied according to the result of the payment instrument authentication. At 630, more information is needed (requesting more information). In one embodiment, the requesting more information function 10 includes issuing a request for manual review. More information on fraud screen and payment instrument authentication can be found in co-pending application no. 13/786,497 titled "Fraud Decision Processing System and Method." While particular embodiments of the invention have been illustrated and described in detail herein, it should be understood that various changes and modifications might be made 15 to the invention without departing from the scope and intent of the invention. The embodiments described herein are intended in all respects to be illustrative rather than restrictive. Alternate embodiments will become apparent to those skilled in the art to which the present invention pertains without departing from its scope. From the foregoing it will be seen that this invention is one well adapted to attain all 20 the ends and objects set forth above, together with other advantages, which are obvious and inherent to the system and method. It will be understood that certain features and sub combinations are of utility and may be employed without reference to other features and sub-combinations. This is contemplated and within the scope of the appended claims. 25

Claims (21)

1. A processing system comprising: a first server of a call center, the first server including an interactive voice response system; and a second server in communication with the first server, the second server being a payment server; wherein the first server: receives a transaction request from a user using the interactive voice response system; and in response to receiving the transaction request, transmits the transaction request and transaction information to the second server, the transaction information defining a payment instrument, a good or service requested, and an amount of the transaction; and wherein the second server, in response to receiving the transaction request and the transaction information: verifies whether the payment instrument is enrolled in an authentication program by transmitting the transaction information to, and receiving a response from, an authentication service provider server; performs a fraud screening by transmitting the transaction request and the transaction information to, and receiving a fraud screening result from, a fraud screening service provider server, the fraud screening result including an instruction to accept the transaction request, reject the transaction request, or gather information; in response to the instruction being to gather information and the payment instrument being enrolled in the authentication program, reserves the good or service requested and provides a time limit to the user for providing the information; in response to the user providing the information before the time limit, completes the transaction; and in response to the user not providing the information before the time limit, cancels the reservation.
2. The processing system of claim 1, wherein the second server is further configured to: in response to the fraud screening result including the instruction to accept the transaction request, allow the requested transaction; and 16 in response to the fraud screening result including the instruction to reject the transaction request, reject the requested transaction.
3. The system of claim 1, wherein the second server is further configured to: in response to the user providing the information before the time limit, perform a fraud screen using the information.
4. The system of claim 1, wherein the second server reserves the good or service requested before a payment of the requested transaction.
5. The system of claim 1, wherein the system generates an asynchronous payment processing in response to receiving the fraud screening result from the fraud screening service provider server, and preferably wherein the system generates the asynchronous payment processing when the result of the fraud screening is to gather information.
6. The system of claim 1, wherein the second server is further configured to: in response to the fraud screening result including the instruction to gather more information, perform a payment instrument authentication.
7. The system of claim 6, wherein the system performs the payment instrument authentication based on a value determined by the fraud screening.
8. The system of claim 6, wherein the value determined by the fraud screening is a probability of fraud.
9. The system of claim 6, wherein the instruction to accept the transaction request or reject the transaction request is based on the payment instrument authentication.
10. The system of claim 6, wherein the instruction to accept the transaction request or gather information is based on the payment instrument authentication, and preferably, wherein the second server is further configured to: in response to the instruction being to gather information, perform the fraud screening with information from the payment instrument authentication. 17
11. A computer-implemented method for secure channel payment processing, the method comprising: receiving, by a first server including an interactive voice response system, a transaction request from a user by voice; in response to receiving the transaction request, transmitting, by the first server, the transaction request and transaction information to a second server, the transaction information defining a payment instrument, a good or service requested, and an amount of the transaction; in response to receiving the transaction request and the transaction information at the second server, verifying, by the second server, whether the payment instrument is enrolled in an authentication program by transmitting the transaction information to, and receiving a response from, an authentication service provider server; performing, by the second server, a fraud screening by transmitting the transaction request and the transaction information to, and receiving a fraud screening result from, a fraud screening service provider server, the fraud screening result including an instruction to accept the transaction request, reject the transaction request, or gather information; in response to the instruction being to gather information and the payment instrument being enrolled in the authentication program, reserving, by the second server, the good or service requested and providing, by the second server, a time limit to the user for providing the information; in response to the user providing the information before the time limit, completing, by the second server, the transaction; and in response to the user not providing the information before the time limit, canceling, by the second server, the reservation.
12. The computer-implemented method of claim 11 further comprising: in response to the fraud screening result including the instruction to accept the transaction request, allowing the requested transaction; and in response to the fraud screening result including the instruction to reject the transaction request, rejecting the requested transaction.
13. The computer-implemented method of claim 11 further comprising: in response to the user providing the information before the time limit, performing a fraud screen using the information. 18
14. The computer-implemented method of claim 11 wherein the reserving is performed before a payment of the requested transaction.
15. The computer-implemented method of claim 11 further comprising: generating, by the second server, an asynchronous payment processing in response to receiving the fraud screening result, preferably, wherein the asynchronous payment processing is only generated when the fraud screening result is the instruction to gather information.
16. The computer-implemented method of claim 11 further comprising: in response to the fraud screening result including the instruction to gather information, performing a payment instrument authentication.
17. The computer-implemented method of claim 16, wherein the payment instrument authentication is performed based on a value determined by the fraud screening, preferably wherein the value determined by the fraud screening is a probability of fraud.
18. The computer-implemented method of claim 16, wherein the instruction to accept the transaction request or reject the transaction request is based on the payment instrument authentication.
19. The computer-implemented method of claim 16, wherein the instruction to accept the transaction request or gather information is based on the payment instrument authentication, and preferably the method further comprises: in response to the instruction being to gather information, performing the fraud screening with information from the payment instrument authentication.
20. The computer-implemented system of claim 1, wherein completing the transaction includes real-time processing of a payment. 19
21. The computer-implemented method of claim 11 further comprising: processing a payment of the transaction in real-time. AMADEUS S.A.S WATERMARK PATENT AND TRADE MARKS ATTORNEYS P39048AU00
AU2014204560A 2013-07-23 2014-07-22 Secure channel payment processing system and method Ceased AU2014204560B2 (en)

Applications Claiming Priority (4)

Application Number Priority Date Filing Date Title
EP13290173.7 2013-07-23
EP13290173.7A EP2830014A1 (en) 2013-07-23 2013-07-23 Secure channel payment processing system and method
US13/949,019 US20150032617A1 (en) 2013-07-23 2013-07-23 Secure Channel Payment Processing System and Method
US13/949,019 2013-07-23

Publications (2)

Publication Number Publication Date
AU2014204560A1 AU2014204560A1 (en) 2015-02-12
AU2014204560B2 true AU2014204560B2 (en) 2015-08-27

Family

ID=52471022

Family Applications (1)

Application Number Title Priority Date Filing Date
AU2014204560A Ceased AU2014204560B2 (en) 2013-07-23 2014-07-22 Secure channel payment processing system and method

Country Status (3)

Country Link
KR (1) KR20150011757A (en)
AU (1) AU2014204560B2 (en)
CA (1) CA2857042A1 (en)

Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20040210476A1 (en) * 2001-03-31 2004-10-21 First Data Corporation Airline ticket payment and reservation system and methods

Patent Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20040210476A1 (en) * 2001-03-31 2004-10-21 First Data Corporation Airline ticket payment and reservation system and methods

Also Published As

Publication number Publication date
AU2014204560A1 (en) 2015-02-12
KR20150011757A (en) 2015-02-02
CA2857042A1 (en) 2015-01-23

Similar Documents

Publication Publication Date Title
US10956906B2 (en) Secure account creation
US20140258119A1 (en) Fraud Decision Processing System and Method
CA2945158A1 (en) Systems and methods for transacting at an atm using a mobile device
EP2966608A1 (en) Authorization of transactions based on automated validation of customer speech
US10223680B2 (en) Transaction decisioning by an automated device
US20160267438A1 (en) Scheduling an Appointment to Complete a Transaction
US9754257B1 (en) Authentication system and method
US20160292783A1 (en) Online marketplace interface having a network of qualified user offers
US11687934B1 (en) Dynamic risk assessment for security features
US20150032617A1 (en) Secure Channel Payment Processing System and Method
WO2017142864A1 (en) Methods and systems for browser-based mobile device and user authentication
US20160104152A1 (en) Methods and systems for secure online payment
US11775978B1 (en) Event-based authentication
US11900452B1 (en) Systems and methods for collateral deposit identification
EP2830014A1 (en) Secure channel payment processing system and method
US20160358141A1 (en) Transaction Decisioning by an Automated Device
US20220012746A1 (en) Real-time financial product selection
AU2014204560B2 (en) Secure channel payment processing system and method
EP2775440A1 (en) Fraud decision processing system and method
US20240185337A1 (en) Systems and methods for collateral deposit identification
AU2016201045A1 (en) Fraud decision processing system and method
Pólkowski et al. Online payment systems
CN106302619A (en) Transaction methods and system

Legal Events

Date Code Title Description
FGA Letters patent sealed or granted (standard patent)
MK14 Patent ceased section 143(a) (annual fees not paid) or expired