GB2539899A - Secure payment method and system for a voice telephony based payment system implemented over a telecommunications network - Google Patents
Secure payment method and system for a voice telephony based payment system implemented over a telecommunications network Download PDFInfo
- Publication number
- GB2539899A GB2539899A GB1511388.9A GB201511388A GB2539899A GB 2539899 A GB2539899 A GB 2539899A GB 201511388 A GB201511388 A GB 201511388A GB 2539899 A GB2539899 A GB 2539899A
- Authority
- GB
- United Kingdom
- Prior art keywords
- party
- authentication
- voice
- call identifier
- secure 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.)
- Withdrawn
Links
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04M—TELEPHONIC COMMUNICATION
- H04M3/00—Automatic or semi-automatic exchanges
- H04M3/42—Systems providing special services or facilities to subscribers
- H04M3/42025—Calling or Called party identification service
- H04M3/42034—Calling party identification service
- H04M3/42059—Making use of the calling party identifier
-
- G—PHYSICS
- G06—COMPUTING OR CALCULATING; COUNTING
- G06Q—INFORMATION 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/00—Payment architectures, schemes or protocols
- G06Q20/08—Payment architectures
- G06Q20/10—Payment architectures specially adapted for electronic funds transfer [EFT] systems; specially adapted for home banking systems
- G06Q20/108—Remote banking, e.g. home banking
-
- G—PHYSICS
- G06—COMPUTING OR CALCULATING; COUNTING
- G06Q—INFORMATION 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/00—Payment architectures, schemes or protocols
- G06Q20/08—Payment architectures
- G06Q20/12—Payment architectures specially adapted for electronic shopping systems
-
- G—PHYSICS
- G06—COMPUTING OR CALCULATING; COUNTING
- G06Q—INFORMATION 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/00—Payment architectures, schemes or protocols
- G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
- G06Q20/305—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using wired telephone networks
-
- G—PHYSICS
- G06—COMPUTING OR CALCULATING; COUNTING
- G06Q—INFORMATION 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/00—Payment architectures, schemes or protocols
- G06Q20/38—Payment protocols; Details thereof
- G06Q20/40—Authorisation, 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/401—Transaction verification
- G06Q20/4014—Identity check for transactions
- G06Q20/40145—Biometric identity checks
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
- H04L63/0876—Network architectures or network communication protocols for network security for authentication of entities based on the identity of the terminal or configuration, e.g. MAC address, hardware or software configuration or device fingerprint
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04M—TELEPHONIC COMMUNICATION
- H04M1/00—Substation equipment, e.g. for use by subscribers
- H04M1/57—Arrangements for indicating or recording the number of the calling subscriber at the called subscriber's set
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04M—TELEPHONIC COMMUNICATION
- H04M2201/00—Electronic components, circuits, software, systems or apparatus used in telephone systems
- H04M2201/41—Electronic components, circuits, software, systems or apparatus used in telephone systems using speaker recognition
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04M—TELEPHONIC COMMUNICATION
- H04M2203/00—Aspects of automatic or semi-automatic exchanges
- H04M2203/10—Aspects of automatic or semi-automatic exchanges related to the purpose or context of the telephonic communication
- H04M2203/105—Financial transactions and auctions, e.g. bidding
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04M—TELEPHONIC COMMUNICATION
- H04M2203/00—Aspects of automatic or semi-automatic exchanges
- H04M2203/60—Aspects of automatic or semi-automatic exchanges related to security aspects in telephonic communication systems
- H04M2203/6054—Biometric subscriber identification
Landscapes
- Business, Economics & Management (AREA)
- Engineering & Computer Science (AREA)
- Accounting & Taxation (AREA)
- General Physics & Mathematics (AREA)
- Theoretical Computer Science (AREA)
- Strategic Management (AREA)
- Physics & Mathematics (AREA)
- General Business, Economics & Management (AREA)
- Finance (AREA)
- Signal Processing (AREA)
- Computer Networks & Wireless Communication (AREA)
- Computer Security & Cryptography (AREA)
- Power Engineering (AREA)
- Computer Hardware Design (AREA)
- Computing Systems (AREA)
- General Engineering & Computer Science (AREA)
- Development Economics (AREA)
- Economics (AREA)
- Telephonic Communication Services (AREA)
Abstract
The method comprising the steps of: establishing a network voice connection 0 between a first party and a second party for initiating a payment transaction; identifying a unique call identifier (CLI) of the first party for the connection and/or recording at least part of a voice signal generated by the first party over the connection; authenticating the unique call identifier against one or more registered unique call identifier(s) associated with the first party and/or authenticating the voice signal against pre-determined voice biometric data of said first party; authenticating the identity of the first party if the unique call identifier and the voice signal authentication succeeds. The invention enables multi-factor security authentication to be implemented in remote payment systems that involve one or more elements of voice telephony where sensitive information is passed from one party to another as a voice signal over the telephone network. The invention finds particular application where the payment transaction is a card based payment transaction. Card-Not-Present transactions may be processed with multi-factor authentication where voice telephony is used in the payment cycle. This has particular advantage in improving fraud detection when a fraudulent remote payment transaction is being attempted over the telephone network.
Description
SECURE PAYMENT METHOD AND SYSTEM FOR A VOICE TELEPHONY BASED PAYMENT SYSTEM IMPLEMENTED OVER A TELECOMMUNICATIONS NETWORK
This invention relates to a secure payment method and system for a voice telephony based payment system implemented over a communications network. In particular the invention concerns a secure telephony based method and system for processing card payments for remote payment transactions.
The supply of goods and services conducted electronically over the internet (e-commerce) often involves payment by payment cards such as credit, debit and charge cards. Card-Not-Present transactions are generally accepted by the payment card industry in order to facilitate online and telephone payments. Secure infrastructure and methodologies have been developed and implemented at various points in the payment cycle to reduce the risk of fraudulent transactions. The payment cycle typically comprises the exchange of information between the parties in the transaction, including the cardholder, merchant, acquirer, card scheme and issuer, typically by data transmission over a telecommunications network. 3-D Secure (RTM) is one system that has been developed and implemented by a card scheme to facilitate secure online payment transactions. 3-D secure is a protocol which adds an additional layer of security for online Card-Not-Present transactions. This system was developed by one of the major card service providers (VISA (RTM)) and is implemented as the “Verified by Visa” and other proprietary card scheme services. 3-D secure is the de-facto standard for online payments and is currently implemented by all the other major card schemes under different brands. 3-D Secure is the only standard that provides second factor authentication for online payments. A revised second generation protocol, known as 3-D Secure (2), is currently being developed. 3-D Secure (2) is intended to be an open standard. Cardholders are invited to enrol and set a password which is then associated with the cardholders card and account. 3-D Secure adds another authentication step for online payments in the card payment cycle. This and other services provide security for Card-Not-Present transactions where there is no voice telephony in the payment cycle. In many situations however a cardholder may be asked to provide payment details over the telephone, either directly to the merchant or an operator at a call service centre associated with the merchant. This is recognised as a security weakness in the card payment cycle. Semafone Limited has developed technology for improving the security at this point in the payment cycle. UK patent GB2473376 (Semafone) discloses a system that separates sensitive and non-sensitive information provided by the cardholder to a call service centre operative. Non-sensitive payment information is recorded and available to the call service centre operator. Sensitive payment information is not made available to the operator. Card payment account number and other sensitive data such as CVV data and the like may be transmitted as a data signal by the cardholder over the PSTN (Public Service Telephone Network) using DTMF transmission. The system identifies such DTMF data signals as sensitive information and prevents operator and call service centre access to such data.
Dual-tone multi-frequency signalling (DTMF) is an in-band telecommunication signalling system using the voice-frequency band over telephone lines between telephone equipment and other communications devices and switching centres. PCI DSS (Payment Card Industry Data Security Standard) is a card industry information security standard for organisations that handle cardholder information for major card services.
Voice transmissions by the cardholder over the PSTN are generally considered to be PCI DSS compliant when systems such as that disclosed in GB2473376 are implemented. At the present time, however, there is no existing protocol for implementing second factor authentication in (ΜΟΤΟ) Mail Order Telephone Order (ΜΟΤΟ) transactions. Fraudulent ΜΟΤΟ transactions may go undetected when a cardholder’s card details have been fraudulently obtained and used in an unauthorised transaction. Internal or external fraud can go undetected when the fraudster has access to the cardholder’s card details, for example by theft or loss of the cardholder’s card or if the cardholder’s card details have been obtained at a point in the payment cycle in a previous transaction, for example by a dishonest merchant or call centre operator. There remains a requirement, therefore, for a secure card payment system that provides multi factor security authentication for Card-Not-Present transactions involving a voice telephony element in the payment cycle, in a ΜΟΤΟ transaction for example.
According to an aspect of the present invention there is provided a secure payment method for a voice telephony based payment system implemented over a communications network; said method comprising the steps: establishing a network voice connection between a first party and a second party for initiating a payment transaction; identifying a unique call identifier of said first party for said connection; recording at least part of a voice signal generated by said first party over said connection; authenticating said unique call identifier against one or more registered unique call identifier(s) associated with said first party; authenticating said voice signal against pre-determined voice biometric data of said first party; authenticating the identity of the first party if said unique call identifier and said voice signal authentication succeeds.
The above aspect of the invention readily enables multi-factor security authentication to be implemented in remote payment systems that involve one or more elements of voice telephony where sensitive information is passed from one party to another as a voice signal over the telephone network.
In preferred embodiments the payment transaction is a card based payment transaction. Thus, Card-Not-Present transactions may be processed with multi-factor authentication where voice telephony is used in the payment cycle. This has particular advantage in improving fraud detection when a fraudulent remote payment transaction is being attempted over the telephone network.
The identity of the first party is authenticated as the cardholder if the unique call identifier and voice signal authentication succeeds. In embodiments where the call identifier is the CLI (Call Line Identity) of the caller, the cardholder’s identity is authenticated when the CLI is authenticated as one registered against the cardholder’s payment card and account, and elements of the callers voice, obtained from the voice signal, match voice biometric data parameters of the cardholder’s voice previously obtained and stored during a registration/enrolment process of the cardholder associating the cardholder’s voice with the cardholder and cardholders account.
With existing arrangements, merchants taking telephone payments over the phone are liable for chargebacks on fraudulent purchases. In addition. Merchants pay higher transaction fees because there is no second factor authentication available for telephone payments in existing payment systems. By implementing trusted 3D secure architecture combined with an authentication method according to the above aspect of the invention, that would work seamlessly for telephone payments, merchants may face lower transaction fees and a reversal of liability for chargebacks. Also, it is anticipated that consumers would benefit from using their cards in a more secure environment where their card details cannot be stolen, nor fraud committed with their stolen card details.
The above aspect of the invention may further comprise the step of the first party transmitting card identification and/or authentication data over the network connection as a voice signal and/or a data signal in response to a request from the second party. The cardholder may be required to transmit sensitive account information which may be provided as a voice signal or a data signal, for example a DTMF signal, in a secure payment transaction.
Preferably, the unique call identifier comprises the call line identity (CLI) of the subscriber line of the first party for initiating the network connection. In a VoIP call the identifier may be the IP address of the originating VoIP call. The unique call identifier utilised by the method and system of embodiments of the present invention may be therefore the caller id or the calling id, i.e the CLI of the caller or the number called. In this way if the call is initiated by the second party, calling the first party, the calling id is used by the system for authentication purposes.
In preferred embodiments, if the call line identity (CLI) authentication fails the method may further comprise the steps of transmitting data to the first party for retransmission as a data signal to the second party for authentication.
The step of transmitting data to the first party may comprise transmitting data comprising a unique code as an SMS or like data signal to a telephone device associated with the subscriber line number of the first party used to initiate the network connection. The step of retransmission as a data signal to the second party for authentication may then comprise the step of retransmitting the unique code as a DTMF data signal. In this way a numeric code may be sent to the caller’s mobile telephone as an SMS message for retransmission over the phone network as a data signal using DTMF functionality on the caller’s mobile phone device.
The above aspect of the invention also contemplates the additional step of first party enrolment.
The first party may be invited to enrol for secure payment identification and authentication if not previously enrolled.
Enrolment may comprise the steps of identifying the unique call identifier, for example the CLI, for the network connection initiated by the first party, authenticating the unique call line identifier or CLI against know unique call line identifier or CLI associated with the first party and proceeding with enrolment if the authentication succeeds. In this way enrolment may proceed only if there is a match between the unique call identifier or CLI of the first party (cardholder) and the unique call identifier(s) or CLI(s) already known to the card issuer for that cardholder. As this is information that the card issuer already has, enrolment may proceed seamlessly by authenticating the unique call identifier or CLI of the first party (cardholder) used for enrolment and proceeding with enrolment only if there is a match with the previously registered information held by the card issuer.
Preferably, the unique call identifier comprises the call line identity (CLI) of the subscriber line number utilised by the first party for initiating the network connection. The method may further comprise spoofing detection steps to identify and reject enrolment when a false call line identity is detected. CLI spoofing is a well-known practice that is often implemented when a caller wishes to hide their true identity. Thus, if CLI spoofing is detected by the payment system during enrolment or authentication a fraudulent attempt at enrolment or authentication may be indicated. CLI spoofing can be readily detected by various proprietary systems including, for example, systems available from Pindrop Security /yyw. psndroDsecuntv.com/.
Enrolment may comprise or further comprises the steps of recording at least part of a voice signal generated by the first party over the network connection, determining voice biometric parameters of said first party from the recording and associating those biometric parameters with the first party and storing that association for subsequent retrieval and authentication of the identity of the first party. A
Aspects of the present invention therefore comprise speaker recognition technology and methodologies. Speaker recognition is the identification of a person from characteristics of their voice (voice biometrics). It is also known as voice recognition.
Speaker recognition systems generally have two phases: Enrolment and verification. During enrolment, the speaker's voice is recorded and typically a number of features are extracted to form a “Voiceprint”, template, or model. In the verification phase, a speech sample or "utterance" is compared against a previously created voice print
Speaker recognition systems fall into two categories: text-dependent or active systems and text-independent or passive systems.
In an active voice biometric system, the person being enrolled is required to recite specific words or phrases, which are then used to establish a unique personal voiceprint. This type of enrolment is considered “active” because the user must submit a specific phrase or phase that will be used for future authentication purposes. The user’s voiceprint is then compared to their enrolment voiceprint each time they call the organisation they have enrolled with.
Passive voice biometric identity verification also requires a user to enrol by submitting a unique voiceprint during initial registration. Unlike active voice biometric enrolment, however, passive enrolment does not require the person to recite specific words or phrases. Passive enrolment involves the recording of a user’s unique voiceprint during an initial conversation, typically about 45 seconds. The user’s voiceprint can be compared to their enrolment voiceprint each time they call the organisation they have enrolled with.
Aspects of the present invention contemplate embodiments having either passive or active voice biometric systems.
Voice biometric systems with speaker recognition have been developed by Nuance for users such as Barclays Wealth to verify the identity of telephone customers within 30 seconds of normal conversation. A verified voiceprint is used to identify callers to the system. Barclays Wealth was the first financial services firm to deploy voice biometrics as the primary means to authenticate customers to their call centres. http://www.nLiance.com/!ndex.,htm.
In preferred embodiments, the communications network comprises the Public Service Telephone Network (PSTN), or a network comprising elements of the PSTN, private network(s), VPN(s) or other voice and/or data networks.
Element(s) of the communications network may comprise data packet network(s), for example an Internet Protocol network
According to another aspect of the present invention there is provided a secure payment system for voice telephony payments implemented over a telecommunications network; said system comprising: means for identifying a unique call identifier of a first party establishing a network voice connection with a second party for initiating a payment transaction; means for recording at least part of a voice signal generated by said first party over said connection; means for authenticating said unique call identifier against one or more registered unique call identifier(s) (caller or calling id) associated with said first party; means for authenticating said voice signal against pre-determined voice biometric data of said first party; and means for authenticating the identity of the first party if said unique call identifier and said voice signal authentication is successful.
According to another aspect of the invention there is provided a secure payment method for a voice telephony based payment system implemented over a communications network; said method comprising the steps of: establishing a network voice connection between a first party and a second party for initiating a payment transaction; recording at least part of a voice signal generated by the first party over said connection; authenticating said voice signal against pre-determined voice biometric data of the first party; authenticating the identity of the first party if the voice signal authentication succeeds. Aspects of the present invention therefore contemplate embodiments where the voice biometrics of the caller are analysed and authenticated against previously obtained voice biometric parameters of the caller, for example during enrolment. The step of authenticating the unique call identifier against one or more registered unique call-identifier(s) associated with the first party, may be optional in such embodiments.
According to another aspect of the invention there is provided a secure payment method for a voice telephony based payment system implemented over a communications network; said method comprising the steps of: establishing a network voice connection between a first party and a second party for initiating a payment transaction; identifying a unique call identifier of the first party for the connection; authenticating the unique call identifier against one or more registered unique call-identifier(s) associated with the first party; authenticating the identity of the first party if the unique call identifier authentication succeeds.
An embodiment of the present invention will now be more particularly described, by way of example only, with reference to the accompanying drawings, in which:
Figure 1 is schematic representation of a known implementation of a secure payment method and system for remote card payment transactions over a telecommunications network, namely 3D Secure as defined in the VISA application;
Figure 2 is a flowchart of 3D Secure as defined in the VISA application;
Figure 3 is a flowchart of Step 3 of 3D Secure as defined in the VISA application;
Figure 4 is a flowchart of Step 8 of 3D Secure as defined in the VISA application;
Figure 5 is a screenshot of a Verified by Visa Password Entry Screen Figure 6 is schematic representation of an implementation of a voice telephony based secure payment method and system for remote card payment transactions over a telecommunications network according to an embodiment of the present invention, namely 3D Secure as amended for Telephone Payments according to an embodiment of the present invention;
Figure 7 is a flowchart of 3D Secure as amended for Telephone Payments;
Figure 8 is a flowchart of an enrolment process for an embodiment of the present invention;
Figure 9 is a flowchart of enrolment process for an embodiment of the present invention.
Referring to Figure 1, which shows, schematically, an online payment system that implements “3D Secure” (RTM), as defined by the VISA (RTM) card payment system. Figure 1 is included herein for background information to assist understanding of the present invention. Figure 1 and the description that follows reproduces relevant content from the Verified by Visa Acquirer and Merchant Implementation Guide.
After enrolment in the 3D secure system, a cardholder may use the Verified by Visa (RTM) secure payment system at any participating merchant.
Figure 1 illustrates the purchase transaction flow in the 3D secure system. The purchase transaction flow is further represented by the flowchart of Figures 2 to 4. step 1: Cardholder Finalizes Purchase
The cardholder browses online at a participating merchant’s website, adds items to the shopping cart, provides information required for checkout (by key entering data or by using an electronic wallet, a merchant one click service, or some other form-fill method), then clicks “Buy”. The merchant now has all necessary data, including Primary Account Number (PAN) of the card presented for the purchase.
Steps 2-7 that follow are invisible to the cardholder.
Step 2: Merchant Server Plug-in Initiates 3-D Secure Processing
When the cardholder clicks Buy, the Merchant Server Plug-in (MPI) is activated. The MPI sends the PAN and other information to the Visa Directory Server to determine whether the card is in a participating range.
Step 3: Visa Directory Server Processes Request
The Visa Directory Server authenticates the merchant, by means of a digital certificate of the like.
If merchant authentication is successful, the Visa Directory Server forwards the merchant query to the appropriate Access Control Server (ACS) to determine whether authentication (or proof of authentication attempt) is available for the card PAN.
If merchant authentication fails, the Directory Server returns an Error and the Verified by Visa transaction is terminated. If no appropriate ACS is available or the cardholder is not participating in Verified by Visa, the Visa Directory Server routes the request to the Visa Attempts Service which will process the authentication on behalf of the issuer.
In the case of where a Commercial card issuer is participating in Verified by Visa, the transaction will be routed to the issuer ACS. If the Commercial cardholder is enrolled in Verified by Visa, the cardholder will be authenticated and an ECl 5 transaction returned. If the Commercial cardholder is not enrolled, the ACS will return an attempted authentication response which the merchant will submit in the Authorization Request. In the Authorization Response, the CAW Results Code value of B indicates that the transaction does not qualify for chargeback protection. If the Directory Server identifies a Commercial card or anonymous Prepaid card with no assigned issued ACS, a Verify Enrolment Response of U will be returned to indicate that these cards are not subject to Verified by Visa business rules related to attempted authentications.
Step 4. ACS Responds to Visa Directory Server
The issuer ACS, or Visa Attempts Service if an issuer ACS is not available, determines whether authentication is available for the card’s PAN, prepares a response, and sends it to the Visa Directory Server.
Step 5: Visa Directory Server Returns Response
The Visa Directory Server returns the ACS response (or its own) to the MPI.
If authentication is available, the response includes the URL of the Visa Transaction Routing Service and the issuer ACS to which the merchant will send the Payer Authentication Request.
Step 6: MPI Sends Payer Authentication Request
If authentication (or proof of an attempted authentication) is not available, then the MPI advises the merchant commerce server that authentication is not available, and processing continues with Step 12.
The MPI sends the Payer Authentication Request to the ACS via the Visa Transaction Routing Service via the cardholder’s device (PC browser or other device), using the URL received in Step 5. The Payer Authentication Request contains information about the purchase transaction.
Step 7: ACS Receives Payer Authentication Request
The Visa Transaction Routing Service receives the Payer Authentication Request and forwards it to the appropriate issuer ACS.
Step 8: ACS Authenticates Cardholder
The ACS formats an authentication request for the cardholder. The authentication request is returned via the Visa Transaction Routing Service to the cardholder’s browser. The cardholder may be authenticated using processes applicable to the PAN (password, Activation During Shopping, etc.). For authentication by password, an example Verified by Visa password screen is shown in Figure 2: • After clicking Buy in Step 1, the cardholder sees a window that contains purchase details and that prompts the cardholder to provide his or her Verified by Visa password. • The cardholder enters their password and clicks Submit. • The ACS determines whether the provided password is correct.
The ACS formats a Payer Authentication Response with appropriate values, including authentication status and, if applicable. Electronic Commerce Indicator (ECl) and Cardholder
Authentication Verification Value (CAW). The CAW is used to confirm that an authentication, or proof of an attempted authentication, was conducted.
The ACS signs the Payer Authentication Response with the issuer’s Verified by Visa Signature Key. This key allows the merchant to verify that the response originated from a valid participating issuer and that the message was not tampered with on route.
Step 9: ACS Returns Authentication Results
The ACS returns the signed Payer Authentication Response to the Visa Transaction Routing Service which forwards the response to the MPI via the cardholder’s device. • Step 9A: Whether or not authentication was successful, the ACS sends a copy of the Payer Authentication Response, including related data, to the Authentication History Server. • Step 9B: The Authentication History Server provides an acknowledgment response that the Payer Authentication Response transaction data was received.
The Authentication History Server serves as the database of record for dispute resolution.
Step 10: MPI Receives Payer Authentication Response
The cardholder’s device forwards the signed Payer Authentication Response to the MPI.
Step 11: MPI Processes Response
The MPI validates the signature on the Payer Authentication Response along with other data in the response.
The MPI, then, passes the results of the authentication attempt to the merchant commerce server.
Step 12: Authorization Processing
Based on the data received from the MPI, the merchant commerce server determines whether to proceed with authorization, as described in Chapter 5, Authorization Processing.
If the merchant commerce server advises the MPI that authentication failed, the merchant should request another form of payment from the shopper.
If authorization is appropriate: • The merchant commerce server sends an authorization request to the merchant’s acquirer or merchant payment processor. The authorization request includes the Electronic Commerce Indicator (ECl) appropriate to the authentication status and the CAW, when required. • The acquirer sends the authorization request, including Verified by Visa authentication information, to the issuer via VisaNet. • The issuer receives and processes the authorization request. When the CAW is passed in BASE I, either the issuer or Visa on the issuer’s behalf, will perform CAW verification. The issuer returns an authorization response. The issuer may choose to approve or to decline the authorization request for reasons unrelated to the Verified by Visa authentication (e.g., insufficient funds, closed account, etc.). • If the issuer authorizes the transaction, the merchant displays an order confirmation as usual, providing the cardholder with details about the order, delivery, and the merchant’s customer service.
Referring now to Figure 6, which shows schematically, a payment system and method that implements “3D Secure” (RTM), as defined by the VISA (RTM) card payment system with an additional layer of security for a voice telephony based payment system. The purchase transaction flow of Figure is further represented by the flowchart of Figure 7.
The system and method of Figures 6 and 7 implements 3D Secure as described above in relation to Figures 1 to 5 modified with additional functionality for processing telephone payments.
Changes to the method and system of Figure 1 include:
Step 0: Cardholder connects to contact/call centre agent.
Either the contact centre has phoned the cardholder or vice versa. In either case, the telephone call is routed through the Telephony Environment which will record the call (either in its entirety or in part).
Step 1: Cardholder Finalizes Purchase
Step 1 of Figure 1 is replaced with the following:
In the system and method of Figure 3, the contact centre agent, not the cardholder uses the participating merchant’s payment interface. Card details are communicated over the phone to the agent who fills in the payment form, then clicks ‘buy’ (or similar). The merchant now has all necessary data, including Primary Account Number (PAN) of the card presented for the purchase.
It is common for the payment interface and merchant plugin to be hosted by a third party Payment Service Provider. This does not fundamentally change the design of the system and method of the illustrated embodiment of the present invention.
Alternatively, Instead of reading the card details out over the phone, a DTMF suppression technology may be deployed through the Telephony Environment - where the card data is entered via their telephone keypad, for example in a system implementing functionality referred to in the Semafone patent mentioned above. In this scenario, the card details are transmitted to the merchant plugin via the Telephony Environment instead of being via the merchants payment interface.
Step 2: Merchant Server Plug-in Initiates 3-D Secure Processing
When the cardholder clicks Buy, the Merchant Server Plug-in (MPI) is activated. The MPI sends the PAN and other information to the Visa Directory Server to determine whether the card is in a participating range.
Additionally, as part of the request information sent, there is included a flag to state that the transaction requires second factor authentication for a Telephone Payment. Also, a unique reference to the telephone call is passed.
Steps 4 To 7 remains the same as described above in relation to Figure 1.
Step 8: ACS Authenticates Cardholder
The ACS formats an authentication request for the cardholder. The authentication request is returned via the Visa Transaction Routing Service to the cardholder’s browser.
In step 8b, the issuer Access Control Server checks the flag to see whether 3D secure for Telephone Payments is required.
If so, then the Issuer will fetch the telephone numbers registered to the cardholder and pass them onto the Telephone 2nd Factor Authentication System - along with a unique reference to the cardholder (or card) and the unique call reference (described in step 2).
In step 8c, the Telephone 2nd Factor Authentication System will check to see whether there is a Voiceprint, comprising voice biometric parameters, registered to the unique cardholder (or card) reference. If there is, then a request is made to the Telephony Environment to request a portion of the call recording. This ‘snippet’ of call recording is then run through a Voice Biometrics solution in order to confirm whether the call recording snippet matches the Voiceprint.
The result is returned to the ACS with the result of this authentication.
During this time, the call centre agent views a screen saying that ‘Authentication is in process’ or similar.
The ACS formats a Payer Authentication Response with appropriate values, including authentication status and, if applicable. Electronic Commerce Indicator (ECl) and Cardholder
Authentication Verification Value (CAW). The CAW is used to confirm that an authentication, or proof of an attempted authentication, was conducted.
The ACS signs the Payer Authentication Response with the issuer’s Verified by Visa Signature Key. This key allows the merchant to verify that the response originated from a valid participating issuer and that the message was not tampered with on route.
Steps 9-12 remain the same as those described above in relation to Figure 1 with the following exceptions: 1. Enrolment
In step 8c, If there is no Voiceprint registered with the cardholder / card, then an enrolment process must begin. a. The Telephony 2nd Factor Authentication System requests the CLI (telephone number) from the telephony Environment given the unique call reference. b. If this CLI matches one of the registered phone numbers, passed by the issuer in Step 2, then this can be assumed to provide a second factor of authentication and a Voiceprint is created and stored against the unique cardholder/card reference and a successful result is passed back via the 3D secure system. 2. Alternative Authentication
If the CLI described above does not match the registered telephone of the user, then an SMS could be sent to the mobile number of the registered cardholder with a onetime use time sensitive code. The cardholder can then type this code into their telephone keypad to progress and the Telephony 2nd Factor Authentication System. The DTMF tones entered would then pass through the telephony environment and be forwarded onto the Telephony 2nd Factor Authentication System for verification. Alternatively, the issuer may have an App that the cardholder can use to confirm authentication requests. In this case, the Telephony 2nd Factor Authentication System will be integrated to this solution. 3. Additional Security • At Step 8, the Voice biometric approach, coupled with the telephone number check could be employed for added security. • A anti-telephone number spoofing technology (for example as designed by PinDrop securities http://www.pindropsecurity.com/) could be deployed at point 8 or in Enrolment to ensure that the telephone numbers are not being spoofed. • An anti-fraud technology as described by http://www.pindropsecurity.com/ could be added during the whole call to add further security.
Claims (15)
1. A secure payment method for a voice telephony based payment system implemented over a communications network; said method comprising the steps: establishing a network voice connection between a first party and a second party for initiating a payment transaction; identifying a unique call identifier of said first party for said connection, and/or recording at least part of a voice signal generated by said first party over said connection; authenticating said unique call identifier against one or more registered unique call identifier(s) associated with said first party, and/or authenticating said voice signal against pre-determined voice biometric data of said first party; authenticating the identity of the first party if said unique call identifier and/or said voice signal authentication succeeds.
2. A secure payment method as claimed in Claim 1 wherein said payment transaction is a card based payment transaction.
3. A secure payment method as claimed in Claim 2 wherein the identity of said first party is authenticated as the cardholder if said unique call identifier and said voice signal authentication succeeds.
4. A secure payment method as claimed in Claim 2 or Claim 3 further comprising the step of the first party transmitting card identification and/or authentication data over said network connection as a voice signal or a data signal in response to a request from said second party.
5. A secure payment method as claimed in any preceding claim wherein said unique call identifier comprises the call line identity (CLI) of the subscriber line of the first party used for initiating the network connection.
6. A secure payment method as claimed in Claim 5 wherein if said call line identity authentication fails the method further comprises the steps of transmitting data to the first party for retransmission as a data signal to the second party for authentication.
7. A secure payment method as claimed in Claim 6 wherein the step of transmitting data to the first party comprises transmitting data comprising a unique code as an SMS signal to a telephone device associated with the said subscriber line of the first party used to initiate the network connection; and the step of retransmission as a data signal to the second party for authentication comprises the step of retransmitting said unique code as a DTMF data signal.
8. A secure payment method as claimed in any preceding claim further comprising the step of first party enrolment.
9. A secure payment method as claimed in Claim 8 wherein said first party is invited to enrol for secure payment identification and authentication if not previously enrolled.
10. A secure payment method as claimed in claim 9 wherein enrolment comprises the steps of identifying the unique call identifier for the network connection initiated by the first party, and authenticating said unique call identifier against one or more registered unique call identifier(s) associated with said first party previously obtained for subsequent retrieval and authentication of the identity of said first party.
11. A secure payment method as claimed in Claim 10 wherein the unique call identifier comprises the call line identity of the subscriber line utilised by the first party for initiating the network connection and the method further comprises anti spoofing steps to identify and reject enrolment when a false call line identity is detected.
12. A secure payment method as claimed in Claim 9, Claim 10 or Claim 11 wherein enrolment comprises or further comprises the steps of recording at least part of a voice signal generated by said first party over said network connection, determining voice biometric parameters of said first party from said recording and associating said biometric parameters with said first party and storing that association for subsequent retrieval and authentication of the identity of said first party.
13. A secure payment method as claimed in any previous claim wherein said communications network is the telephone network
14. A secure payment method as claimed in any previous claim wherein said communications network is an Internet Protocol network
15. A secure payment system for voice telephony payments implemented over a telecommunications network; said system comprising: means for identifying a unique call identifier of a first party establishing a network voice connection with a second party for initiating a payment transaction and/or means for recording at least part of a voice signal generated by said first party over said connection, and/or means for authenticating said unique call identifier against one or more registered unique call identifier(s) associated with said first party; means for authenticating said voice signal against pre-determined voice biometric data of said first party, and/or means for authenticating the identity of the first party if said unique call identifier and said voice signal authentication is successful.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| GB1511388.9A GB2539899A (en) | 2015-06-29 | 2015-06-29 | Secure payment method and system for a voice telephony based payment system implemented over a telecommunications network |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| GB1511388.9A GB2539899A (en) | 2015-06-29 | 2015-06-29 | Secure payment method and system for a voice telephony based payment system implemented over a telecommunications network |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| GB201511388D0 GB201511388D0 (en) | 2015-08-12 |
| GB2539899A true GB2539899A (en) | 2017-01-04 |
Family
ID=53872380
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| GB1511388.9A Withdrawn GB2539899A (en) | 2015-06-29 | 2015-06-29 | Secure payment method and system for a voice telephony based payment system implemented over a telecommunications network |
Country Status (1)
| Country | Link |
|---|---|
| GB (1) | GB2539899A (en) |
Families Citing this family (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN114819980A (en) * | 2022-07-04 | 2022-07-29 | 广州番禺职业技术学院 | Payment transaction risk control method and device, electronic equipment and storage medium |
Citations (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| WO2003046784A1 (en) * | 2001-11-29 | 2003-06-05 | Niel Eben Viljoen | Method and system for operating a banking service |
| US20080152099A1 (en) * | 2006-12-22 | 2008-06-26 | Mobileaxept As | Efficient authentication of a user for conduct of a transaction initiated via mobile telephone |
| US20080177661A1 (en) * | 2007-01-22 | 2008-07-24 | Divya Mehra | System and methods for phone-based payments |
| US20150127538A1 (en) * | 2008-05-09 | 2015-05-07 | Semafone Limited | Signal detection and blocking for voice processing equipment |
-
2015
- 2015-06-29 GB GB1511388.9A patent/GB2539899A/en not_active Withdrawn
Patent Citations (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| WO2003046784A1 (en) * | 2001-11-29 | 2003-06-05 | Niel Eben Viljoen | Method and system for operating a banking service |
| US20080152099A1 (en) * | 2006-12-22 | 2008-06-26 | Mobileaxept As | Efficient authentication of a user for conduct of a transaction initiated via mobile telephone |
| US20080177661A1 (en) * | 2007-01-22 | 2008-07-24 | Divya Mehra | System and methods for phone-based payments |
| US20150127538A1 (en) * | 2008-05-09 | 2015-05-07 | Semafone Limited | Signal detection and blocking for voice processing equipment |
Also Published As
| Publication number | Publication date |
|---|---|
| GB201511388D0 (en) | 2015-08-12 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US10467621B2 (en) | Secure authentication and payment system | |
| RU2438172C2 (en) | Method and system for performing two-factor authentication in mail order and telephone order transactions | |
| US8322602B2 (en) | Secure and portable payment system | |
| US9596237B2 (en) | System and method for initiating transactions on a mobile device | |
| US9183549B2 (en) | System and method of secure payment transactions | |
| US20060173776A1 (en) | A Method of Authentication | |
| US20170109752A1 (en) | Utilizing enhanced cardholder authentication token | |
| US20100179906A1 (en) | Payment authorization method and apparatus | |
| US20120150748A1 (en) | System and method for authenticating transactions through a mobile device | |
| US20190213585A1 (en) | Systems, methods and computer program products for otp based authorization of electronic payment transactions | |
| TW201314600A (en) | Transaction payment method and system | |
| EP2652688A1 (en) | Authenticating transactions using a mobile device identifier | |
| WO2010140876A1 (en) | Method, system and secure server for multi-factor transaction authentication | |
| CN102906776A (en) | A method for mutual authentication of a user and service provider | |
| WO2003047208A1 (en) | Credit card payment by mobile phone | |
| CN102184497A (en) | Electronic transaction system and payment method with telegraph number as account number | |
| EP1134707A1 (en) | Payment authorisation method and apparatus | |
| CN104541311A (en) | Quick payment system and corresponding method | |
| GB2539899A (en) | Secure payment method and system for a voice telephony based payment system implemented over a telecommunications network | |
| KR20160149596A (en) | Method for providing financial service using virtual account | |
| GB2438284A (en) | Payment authorisation using voice biometric | |
| KR101604656B1 (en) | System for consenting settlement and automacic transfer | |
| KR100818793B1 (en) | Auto call system using telephone and financial transaction method using the system | |
| EP1615183A1 (en) | Internet payment verification method and system | |
| US12542670B2 (en) | Processing system using secret linked to multiple accounts |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| WAP | Application withdrawn, taken to be withdrawn or refused ** after publication under section 16(1) |