Patent Application
20170161741
Embodiments of the disclosure herein describe methods and devices for protecting customer information in cardholder-not-present transactions, including transactions involving contact centers and web-based transactions.
Companies often collect, store or otherwise process information concerning individuals in order to provide services and products. Many countries have enacted laws that regulate how such information is to be treated or may be used. In addition, some industry bodies prescribe codes of conduct and standards with which their members must comply. One such industry body is the Payment Card Industry Security Standards Council (PCI SSC). It administers the Data Security Standard (PCI DSS), a framework for the secure handling of cardholder data. PCI DSS compliance requirements apply to all system components that are included in, or connected to, the cardholder data environment (i.e. that part of the network which stores, processes or transmits cardholder data), including network components, servers and applications. These compliance requirements apply to communications for card-present transactions (when the payment card is presented at a point of sale (POS) terminal at a merchant premises), as well as cardholder-not-present transactions (when a transaction is made online or over the telephone via a web payment portal or a call center assistant).
Consequently, in recent years, a common goal for contact center or interactive voice response (IVR) operators has been to remove sensitive data, such as credit card data, from their environment. By doing so, the potential for contact center agent fraud is removed, and a company's security or compliance costs are reduced.
In order to ensure that the contact center is PCI DSS compliant and tackle fraud and security concerns, the contact center industry presently uses specialist products, including approaches defined in prior art such as patents GB2478916 and U.S. Pat. No. 9,178,974 (Eckoh), patent application GB2497940 (Eckoh) and patent GB2473376 (Semafone). Methods such as these may partially or fully remove sensitive data from a contact center or IVR system, but each requires some level of configuration or integration with the contact center IT or payment systems. In some cases, an existing contact center payment system must be replaced entirely.
Further, in outsourcing environments, it is possible that no existing approach may be able to completely remove sensitive data from the contact center environment. A common approach in the contact center industry is for third-party ‘outsourcers’ to collect sensitive data on behalf of the ultimate merchant company. In such situations, customers pass sensitive data (such as their credit card details) to the intermediary ‘outsourcer’, who then pass it on the merchant.
Many merchants require their paid outsourcer to adopt and utilize the merchant's ordering or payment systems. The outsourcer has no control over the ordering or payment system, and cannot change it in any way. Further, some merchants establish a proprietary secure data link between the merchant and outsourcer systems, to protect the customer's sensitive data in transit.
To remove all sensitive data from its environment, an outsourcer may require a merchant to alter the merchant's payment or ordering systems, or communications protocols. This can be very difficult, and sometimes impossible, to achieve.
Merchants typically outsource to multiple providers at the same time, and can be reluctant to make changes specific to any one outsourcer. Conversely, any outsourcer may serve multiple merchants, and may wish to find a single approach for removing sensitive data, without having to engage all their merchant clients to accomplish this.
As a result of these difficulties, contact center operators, and particularly those which act as outsourcing providers, can presently struggle with internal fraud and compliance concerns.
Hence a generic approach is needed; one which does not require integration with or changes to existing contact center IT or payment processes, and one which can be implemented at an outsourcer without recourse to each of its paying merchants. Such an approach would reduce fraud and compliance costs for the contact center and IVR operator.
An embodiment of the present invention relates to a method of processing signals in a payment transaction. At a processor, telephonic signals conveying sensitive and non-sensitive information are received. The processor detects sensitive information conveyed by the received telephonic signals and sends the sensitive information to a token service provider. The token service provider is communicatively coupled to a payment transaction entity and configured to generate surrogate information for the sensitive information. The processor receives surrogate information from the token service provider, the surrogate information having been generated by the token service provider. The processor then outputs the received surrogate information to a transaction handling center such that the sensitive information is not provided to the transaction handling center. At the transaction handling center, the surrogate information is included in a transaction request message and the transaction request message is sent to the payment transaction entity. At the payment transaction entity, the surrogate information comprised within the transaction request message is sent to the token service provider. Finally, the sensitive information is received at the payment transaction entity for use in the payment transaction, the sensitive information having been retrieved by the token service provider upon receipt of the surrogate information.
Another embodiment of the present invention comprises a further method of processing signals in a payment transaction, in which the signals originate from a customer device and are addressed to a transaction handling center. Signals originating from the customer device are redirected to an address of a processor. The signals convey sensitive and non-sensitive information. At the processor, the redirected signals are received. The processor detects sensitive information conveyed by the received signals and sends the sensitive information to a token service provider. The token service provider is communicatively coupled to a payment transaction entity and configured to generate surrogate information for the sensitive information. The processor receives surrogate information from the token service provider, the surrogate information having been generated by the token service provider. The processor then outputs the received surrogate information to a transaction handling center such that the sensitive information is not provided to the transaction handling center. At the transaction handling center, the surrogate information is included in a transaction request message and the transaction request message is sent to the payment transaction entity. At the payment transaction entity, the surrogate information comprised within the transaction request message is sent to the token service provider. Finally, the sensitive information is received at the payment transaction entity for use in the payment transaction, the sensitive information having been retrieved by the token service provider upon receipt of the surrogate information.
An additional embodiment of the present invention relates to a processor for processing signals in a payment transaction. The processor comprises signal monitoring means operable to receive telephonic signals conveying sensitive and non-sensitive information and detect sensitive information conveyed by the received telephonic signals. The processor also comprises a token service provider interface operable to send the sensitive information to a token service provider, the token service provider being communicatively coupled to a payment transaction entity and configured to generate surrogate information for the sensitive information. The token service provider interface receives surrogate information from the token service provider, the surrogate information having been generated by the token service provider. In addition, the processor comprises signal outputting means operable to output the received surrogate information to a transaction handing center such that the sensitive information is not provided to the transaction handling center, the transaction handling center being operable to include the surrogate information in a transaction request message and send the transaction request message to the payment transaction entity. The payment transaction entity to which the transaction request message is sent is operable to send the surrogate information comprised within the transaction request message to the token service provider and receive the sensitive information for use in the payment transaction, the sensitive information having been retrieved by the token service provider upon receipt of the surrogate information.
A further embodiment of the present invention relates to a processor for processing signals in a payment transaction in which the signals originate from a customer device and are addressed to a transaction handling center. The processor comprises signal monitoring means operable to receive signals originating from the customer device and having been redirected to an address of the processor prior to receipt, the signals conveying sensitive and non-sensitive information. The signal monitoring means is also operable to detect sensitive information conveyed by the received signals. The processor also comprises a token service provider interface operable to send the sensitive information to a token service provider, the token service provider being communicatively coupled to a payment transaction entity and configured to generate surrogate information for the sensitive information. The token service provider interface receives surrogate information from the token service provider, the surrogate information having been generated by the token service provider. In addition, the processor comprises signal outputting means operable to output the received surrogate information to a transaction handing center such that the sensitive information is not provided to the transaction handling center, the transaction handling center being operable to include the surrogate information in a transaction request message and send the transaction request message to the payment transaction entity. The payment transaction entity to which the transaction request message is sent is operable to send the surrogate information comprised within the transaction request message to the token service provider and receive the sensitive information for use in the payment transaction, the sensitive information having been retrieved by the token service provider upon receipt of the surrogate information.
Specific embodiments will now be described, by way of example only and with reference to the accompanying drawings having the figure numbers as listed above.
A schematic diagram of a known contact center environment 100 is shown in
The sensitive information is then relayed, using a payment service provider (PSP) 120, to an acquirer 130. The PSP 120 provides a single interface to the merchant, enabling the merchant to accept a variety of different payment methods, for example credit cards, digital wallets, and alternative payment methods such as bank transfers and direct debits. The PSP 120 may be able to collect payments intended for the merchant and streamline these payments for simplified management. The PSP 120 may further be able to contract with the acquirer 130 used by the merchant. Alternatively, the merchant may contract directly with the acquirer 130.
The role of the acquirer 130 is to process transactions on behalf of the merchant. In effect, the acquirer 130 manages the merchant's bank account. The acquirer 130 passes sensitive information, via a payment network 140, to a card issuer 150 for authorization and arranges payment for the merchant. As described above, these payments may be collected by the PSP 120 for streamlined payment to the merchant.
The payment network 140 manages and controls the operation and clearing of transactions. The payment network 140 passes sensitive information from the acquirer 130 to the card issuer 150 and passes payments back to the acquirer 130 so that the merchant can receive payment. Payment networks 140 include Visa, MasterCard and American Express, among others, and may also include networks processing so-called “on us” transactions where the acquirer 130 and card issuer 150 are the same entity.
The card issuer 150 provides a payment card to the cardholder on behalf of the payment network 140. Therefore, the sensitive information provided by the customer 102 is the information relating to the card issued by the card issuer 150. The card issuer 150 is responsible for transactions made using the card issued to the customer 102. The card issuer 150 can generate an authorization response either authorizing or declining a transaction initiated by the customer 102 and can debit the customer's account accordingly.
The authorization response from the card issuer 150 is passed back, via the payment network 140, acquirer 130 and PSP 120, to the contact center agent's computer terminal 118. The contact center agent 116 then informs the customer 102 of whether payment has been made successfully. The exchange between the customer 102 and contact center agent 116 may be recorded, for training purposes. Alternatively, the functions of the PBX 112, phone 114, contact center agent 116 and agent's computer terminal 118 may be performed by an IVR system (not shown).
As stated above, difficulties in compliance with PCI DSS requirements are exacerbated in outsourcing environments. Such a known contact center outsourcing environment 200 is shown in
As noted above, customer information may be stored within a contact center environment in recordings of transactions carried out by a contact center agent or IVR system in communication with a customer. In a ‘cardholder-not-present’ (CNP) transaction, the sensitive data provided by the customer falls into two categories as defined under the PCI DSS. The first category is cardholder data, which may include the PAN and expiry date. The customer's PAN may be stored within a contact center environment after authorization of the transaction on the condition that this information is encrypted. The second category of sensitive data is sensitive authentication data (SAD), which may include the CV2 data printed on the reverse of the customer's card. This data may also be termed CVV2, CVC2, CID, CAV2, or CSC data; however the term CV2 data will be used herein to refer to any of the foregoing validation information. SAD must not be stored after authorization. While encryption of the PAN and prohibiting storage of the CV2 data reduce the risk of external access to a customer's sensitive information, it leaves open the possibility of this information being recorded by a contact center agent or otherwise misused by personnel operating within the contact center environment.
Therefore, there is a need to maintain the security of cardholder information in CNP transactions, such as the transactions outlined above in
Tokenization in payment transactions has recently become a viable approach to protecting customer card data to provide increased protection against fraud. Tokenization has arisen out of a need to minimize unauthorized use of cardholder account data. The EMVCo Payment Tokenization Specification provides a detailed technical specification for payment tokenization solutions and defines the requirements of a token service provider (TSP). Embodiments of the present invention are described below with reference to the requirements detailed in the EMVCo Payment Tokenization Specification. However, it will be appreciated by persons skilled in the art that these embodiments may be equally applicable to other standards and specifications defining the requirements of tokenization in payment transactions. Additionally, the capabilities of certain entities in embodiments described below may not be consistent with present requirements of current standards; however it will be appreciated by persons skilled in the art that developments in the field of payment tokenization solutions may result in the introduction of alternative standards and requirements in the future.
The EMVCo Payment Tokenization Specification defines that a token may be requested from a TSP by an entity referred to as a token requestor. A token requestor is required to register with a TSP and comply with requirements, systems and processes defined by the TSP. Upon successful registration, a token requestor is assigned a token requestor ID. The TSP implements a secure method of interaction with registered token requestors.
A payment token, as defined in the EMVCo Payment Tokenization Specification, is a surrogate value for a customer's primary account number (PAN) that complies with the same validation requirements as the customer's PAN. That is, a payment token may have the same structure as the PAN to which it corresponds. For example, the payment token may be a numerical value which is 12 to 19 digits in length. Further validation requirements may include the inclusion of the Luhn check digit. As a payment token complies with the same validation requirements as its corresponding PAN, the payment token may be processed in the same way as the PAN by any entities handling the payment token. Consequently, a payment token must not have the same value as a PAN or conflict with a PAN. In order to avoid conflicts with customer PANs, the payment tokens are generated within a token issuer identification number (IIN) range. The IIN of a customer's PAN may be the leading 6 digits of the PAN. Therefore, the token IIN range is designated so as not to conflict with a IIN range of a customer's PAN. The last four digits of a payment token may be the same as the last four digits of the customer PAN to which it corresponds, for the purpose of issuing a receipt to the customer, by which the customer can verify that their sensitive information was used in the transaction.
A payment token issued by the TSP may be specified for use in a particular domain. For example, the payment token may be restricted to a particular type of transaction, such as online transactions, transactions initiated by a particular application running on a mobile device, or phone-based transactions. The payment token may also be restricted for use in specific retail sectors, to prevent wider misuse of the customer's details. Further, the payment token may be subject to a geographical restriction, such as use within the United Kingdom.
The EMVCo Payment Tokenization Specification is applicable to both ‘cardholder-present’ and ‘cardholder-not-present’ (CNP) transactions. A CNP transaction is one in which a transaction is completed, for example, by phone or over the Internet. Since CNP transactions cannot use the physical security devices built into a card, exposure to fraud is higher in CNP transactions.
Telephone-Based Transactions
As noted above, exposure to fraud is higher in CNP transactions than in ‘cardholder-present’ transactions. Further, current solutions to ensure compliance with PCI DSS requirements may not be practical for implementation in outsourcing environments. Consequently, there exists a need for a solution to ensure compliance with PCI DSS requirements and reduce exposure to fraud in CNP transactions. Any such solution should also be compatible with merchant centers in outsourcing environments.
A call is initiated by the customer 302. As a result of a prior arrangement between the contact center 310 and the proprietor of the call processor 380, customer calls intended for receipt at the contact center 310 are redirected via the call processor 380. This may be achieved by the contact center 310 having updated their telephony supplier to redirect customer calls to the call processor 380, which may make an additional call to the contact center 310.
Following initiation of a customer call, the contact center agent 316 or IVR system (not shown) requests sensitive information from the customer 302. The call processor 380 receives signals from the customer 302, intended for receipt at the contact center 310, and monitors the received signals for sensitive data. The sensitive data may be input by the customer 302 using a telephone keypad, in which case the call processor 380 may intercept the sensitive data by monitoring the received signals for predetermined patterns of DTMF tones. Alternatively, the call processor 380 may include speech recognition software, in which case the call processor 380 may monitor the received signals for sensitive data spoken by the customer 302. As a further alternative, the sensitive data may be provided by an application running on a mobile phone, or by any other third party application authorized by the customer 302 to provide sensitive information to the contact center agent 316 or IVR system. Sensitive data provided by a mobile application or other third party application may be conveyed in response to a command or prompt issued by the contact center agent 316 or computer terminal 318 or IVR system. The call processor 380 prevents the sensitive information from being received at the contact center 310.
Upon detection of the PAN and card expiry date provided by the customer 302, the call processor 380 requests a payment token from the TSP 370. The call processor 380 may be required to provide certain minimum requirements in order to receive a payment token corresponding to a customer's. PAN. The minimum requirements may, for example, include the token requestor ID, the PAN, and the card expiry date.
Upon receipt of the token requestor ID, the PAN, and the card expiry date, the TSP 370 generates a payment token and a payment token expiry date. The TSP 370 may also generate a token assurance level, which is initially assigned a value of 00. The token assurance level is used in the identification and verification (ID&V) method as defined in the EMVCo Payment Tokenization Specification, and enables validation of the cardholder and their account in order to establish a confidence level for authentication of the cardholder. The value of the token assurance level is initially set to 00 as no ID&V process is carried out at this stage. The generated payment token, payment token expiry date and token assurance level are stored at the TSP 370 and passed to the call processor 380. In addition, the TSP 370 stores the PAN, token requestor ID and card expiry date. The call processor 380 may also store the received data for later use.
The call processor 380 sends the payment token to the phone 314 and/or computer terminal 318 of the contact center agent 316, or to the IVR system. The call processor 380 may output the payment token to the phone 314 and/or computer terminal 318 of the contact center agent 316, or to the IVR system, in a number of different formats. For example, the call processor 380 may convert the payment token to DTMF tones, which are then output to the phone 314 of the contact center agent 316. The call processor 380 may further be operable to output the payment token directly to the computer terminal 318 of the contact center agent 316. The payment token may be output by the call processor 380 in numerical format, or masked by the call processor 380 to prevent the payment token being visible to the contact center agent 316. Alternatively, a converter may be used to convert the DTMF tones received to numerical format and input the numerical data at the computer terminal 318.
Alternatively, in a contact center 310 using IVR systems, the IVR system may be able to convert the DTMF tones output by the call processor 380 to numerical data which is entered into a computer (not shown).
Alternatively, the call processor 380 may convert the payment token to spoken text, which is then relayed to the phone 314 of the contact center agent 316. The contact center agent 316 may then enter the spoken text output by the call processor 380 at the computer terminal 318. As above, the spoken text received from the call processor 380 may be processed by an IVR system for the purpose of data entry.
As a further alternative, the call processor 380 may output the payment token directly to the computer terminal 318 of the contact center agent 316 or IVR system, without outputting the payment token in an audible format.
As stated above, the call processor 380 may also output the card expiry date. This may be output to the phone 314 and/or computer terminal 318 of the contact center agent 316, or to the IVR system, using the same mechanisms as described above.
Once the payment token and card expiry date have been input to the computer terminal 318, the contact center agent 316 or IVR system asks the customer 302 to provide their CV2 data. Again, the call processor 380 receives signals from the customer 302 and monitors the received signals for sensitive data, which may be input by the customer 302 using any of the methods described above for providing their PAN.
Upon detection of the customer's CV2 data, the call processor 380 sends a request to the TSP 370 for an updated token assurance level to be assigned to the payment token. The call processor 380 sends the payment token, token requestor ID and CV2 data to the TSP 370. The CV2 data is classified under the EMVCo token specification as an ‘optional cardholder data element’. Optional cardholder data elements may, for example, also include the customer's billing address and post code. Persons skilled in the art will appreciate that any of the foregoing information may be used to provide additional validation of the cardholder. However, as contact centers are specifically prohibited from storing the CV2, the following paragraphs will make particular reference to validation information in the form of CV2 data.
In adherence to the EMVCo Payment Tokenization Specification, the TSP 370 forwards the received payment token, token requestor ID and CV2 data to the card issuer 350 and requests identification and verification (ID&V) of the cardholder data. The ID&V method is performed by the card issuer 350 on the basis of the received information, and an updated token assurance level is generated and sent to the TSP 370. The TSP 370 then stores the updated token assurance level and sends the updated token assurance level to the call processor 380.
The call processor 380 may optionally perform a determination upon receipt of the updated token assurance level. The call processor 380 may check whether the updated token assurance level is greater than a predetermined threshold and may proceed with the transaction if this threshold is exceeded. If the updated token assurance level fails to meet the predetermined threshold, the transaction may be terminated, and the call processor 380 may notify the contact center agent 316 or IVR system so that the customer 302 can be informed that the transaction has not been successful.
The call processor 380 optionally generates a “random” three- or four-digit number which will be referred to as dummy CV2 data. The optional dummy CV2 data may be required to comply with certain requirements. One such requirement may be that each digit in a particular position in the string of digits comprising the dummy CV2 data must have a different numerical value to the digit in the corresponding position in the customer's CV2 data. For example, the second digit of the dummy CV2 data may be required to have a different value to the second digit of the CV2 data. The call processor 380 may output the dummy CV2 data to the phone 314 and/or computer terminal 318 of the contact center agent 316 or to the IVR system using the same mechanisms as for output of the payment token.
Following input of the payment token, card expiry date and, optionally, dummy CV2 data at the computer terminal 318, the transaction may proceed. The payment token, dummy CV2 data and card expiry date are passed, using the PSP 320, to the acquirer 330. This information is then transferred by the acquirer 330 over the payment network 340. As the payment token complies with the same formatting and validation rules as the customer's PAN, the transaction proceeds as if the customer's PAN, card expiry date and CV2 data had been input at the computer terminal 318.
The payment network 340 recognizes that the customer information, received from the contact center 310 via the PSP 320 and acquirer 330, is tokenized, and therefore interfaces with the TSP 370 to detokenize the payment token. The payment network 340 sends the payment token to the TSP 370 along with any other data required by the TSP 370 to ensure that the request for detokenization is from a trusted source and to enable the TSP 370 to retrieve the customer's PAN. Upon receipt of the payment token and other information, the TSP 370 retrieves the customer PAN and updated token assurance level associated with the payment token and passes this information to the payment network 340.
The TSP 370 may additionally retrieve the token requestor ID and pass this information to the payment network 340. Upon receipt of the token requestor ID, the payment network 340 may perform a domain restriction check.
Upon inspection of the updated token assurance level, the payment network 340 determines that the token assurance level has been updated following a request for ID&V from the TSP 370. The payment network 340 therefore discards any dummy CV2 data. The payment network 340 then sends the customer's PAN and card expiry date to the card issuer 350, along with the updated token assurance level, and adds an indicator conveying to the card issuer 350 that an ‘on-behalf-of’ validation has already been performed upon request from the TSP 370.
Upon receipt of the customer's PAN and card expiry date, the updated token assurance level and the ‘on-behalf-of’ validation indicator, the card issuer 350 issues an authorization response indicating whether the transaction is accepted or declined. The card issuer 350 may determine whether to accept or decline the transaction on the basis of the updated token assurance level. The card issuer 350 includes the customer's PAN in the authorization response and sends the authorization response to the payment network 340. Upon receipt of the authorization response, the payment network 340 sends the PAN to the TSP 370 to be re-exchanged with its associated payment token. The TSP 370 then sends the payment token to the payment network 340. The payment network 340 sends the payment token to the acquirer 330 for onward sending to the PSP 320 and contact center 310.
Upon receipt of the payment token and authorization response at the contact center 310, the contact center agent 316 or IVR system advises the customer 302 of whether the transaction has been accepted or declined by the card issuer 350.
Therefore, the call processor 380 shown in
After the authorization response has been received at the contact center 310 and the customer 302 has been informed of the success or failure of the transaction, the call processor 380 may request deletion of the payment token and associated customer information. The request for deletion may be triggered by a notification from the contact center 310 that payment has been either authorized or declined. The call processor 380 may be operable to detect whether the customer 302 has been informed of the success or failure of payment, and request deletion thereafter. Alternatively, or in addition, the call processor 380 may wait until a predefined period of time has passed before requesting deletion of the payment token and associated customer information.
In order to request deletion of the payment token, the call processor 380 may send a request to the TSP 370 for the payment token, customer PAN and any other information stored at the TSP 370 in relation to the customer PAN to payment token mapping to be deleted. The TSP 370 may then delete the customer information associated with the payment token and confirm deletion to the call processor 380.
Telephone-Based Transactions Involving TSPs with CV2 Storage Capability
The first aspect of the first embodiment, as described above, includes the step of ID&V being carried out on request from the TSP 370. ID&V is carried out because the TSP 370 is not capable of storing CV2 data associated with a particular payment token or generating and storing a ‘CV2 token’ or other surrogate value corresponding to the CV2 data. Therefore, the TSP 370 receives CV2 data and requests an update of the token assurance level, which is presented to the card issuer 350 with the detokenized customer PAN for authorization. This ensures that the CV2 data need not be presented to the card issuer 350 in order for the transaction to be authorized or declined.
Alternatively, in a second aspect of the first embodiment, the TSP 370 may be capable of storing CV2 data associated with a particular payment token or token requestor ID. The TSP 370 may further be operable to generate a CV2 validator, which may be used in the payment transaction in place of the customer's CV2 data. The CV2 validator may use the same formatting as the CV2 data (that is, the CV2 validator may be a three- or four-digit number). In addition, the CV2 validator may be required to comply with additional requirements, such as those described above with respect to the dummy CV2 data.
In an environment in which the TSP 370 is capable of storing a customer's CV2 data and associated CV2 validator for the duration of the payment transaction, it may not be necessary for the ID&V process to be requested by the TSP 370 upon receipt of the customer's CV2 data. Accordingly, the token assurance level may not be updated.
In the second aspect of the first embodiment, the call processor 380 receives signals from the customer 302 and monitors these signals as in the first aspect. The call processor 380 monitors the received signals for the customer PAN and requests, receives and outputs a payment token as described above. Upon detection of the customer's CV2 data, the call processor 380 sends a request to the TSP 370 for a CV2 validator to be returned in place of the customer's CV2 data. Upon receipt of the request, the TSP 370 generates a CV2 validator and verifies that the generated CV2 validator is compliant with the formatting requirements noted above.
It will be appreciated that the request for a CV2 validator may be comprised within the request for a payment token to be returned in place of the customer's PAN, and thus the CV2 validator and payment token may be returned to the call processor 380 at the same time. Alternatively, if the request for a CV2 validator is separate to the request for a payment token, the call processor 380 may be required to provide additional information to the TSP 370, in the same way as for requesting the payment token. The additional information may, for example, comprise the token requestor ID and the payment token.
The call processor 380 may output the CV2 validator to the phone 314 and/or computer terminal 318 of the contact center agent 316 or IVR system using the same mechanisms as for output of the payment token.
Following input of the payment token, card expiry date and CV2 validator, at the computer terminal 318, the transaction may proceed. The payment token, CV2 validator and card expiry date are passed, using the PSP 320, to the acquirer 330. The acquirer 330 transfers this information over the payment network 340. As both the payment token and the CV2 validator comply with the same validation and formatting rules as the customer's PAN and CV2 data, respectively, the transaction proceeds as if the customer's PAN, card expiry date and CV2 data had been input at the computer terminal 318.
The payment network 340 interfaces with the TSP 370 to detokenize the payment token, as described above. In addition, the payment network 340 sends the CV2 validator to the TSP 370. Upon receipt of the CV2 validator, the TSP 370 retrieves the customer's CV2 data and passes this information to the payment network 340. The TSP 370 may also validate that the CV2 validator received from the payment network 340 corresponds to the CV2 data stored at the TSP 370.
The TSP 370 may additionally retrieve the token requestor ID and pass this information to the payment network 340. Upon receipt of the token requestor ID, the payment network 340 may perform a domain restriction check.
The payment network 340 then sends the customer PAN, card expiry date and CV2 data to the card issuer 350. Upon receipt, the card issuer 350 issues an authorization response indicating whether the transaction is accepted or declined. The payment network re-tokenizes the customer's PAN included in the authorization response as described above.
The CV2 data is not included in the authorization response and therefore no subsequent re-tokenization of the CV2 data is necessary. Upon receipt of the payment token and authorization response at the contact center 310, the contact center agent 316 or IVR system advises the customer 302 whether the transaction has been accepted or declined by the card issuer 350.
Immediately after the payment network 340 has received the authorization response from the card issuer 350, the payment network 340 may instruct the TSP 370 to delete the CV2 data and CV2 validator stored at the TSP 370. Alternatively, or in addition, the payment network 340 may instruct the TSP 370 to delete the CV2 data and CV2 validator stored at the TSP 370 upon expiry of a predetermined period of time. Alternatively, or in addition, the deletion of the CV2 data and CV2 validator may be instigated by the TSP 370, following the process of retrieving the CV2 validator. As explained above, deletion of the CV2 data is necessary as it is classified as sensitive authentication data (SAD), which must not be stored after authorization of the payment transaction, in accordance with PCI DSS requirements.
After the customer 302 has been informed of the success or failure of the transaction, the call processor 380 may request deletion of the payment token and associated customer information as described in the first aspect of the first embodiment.
Subsequent Telephone-Based Transactions by the Same Customer
Some contact centers may store a payment token associated with a particular transaction, so that a customer can initiate subsequent transactions without providing their PAN and card expiry date. For ease of reference, these will be referred to as ‘repeat’ transactions. While any subsequent transaction must necessarily be initiated by the same customer, there is no requirement for the subsequent transaction to be identical to any preceding transactions.
In a third aspect of the first embodiment, a repeat transaction may be initiated if the TSP 370 is capable of storing CV2 data and generating a CV2 validator. Upon initiation of a repeat transaction, the contact center agent 316 asks the customer 302 to provide their CV2 data. The call processor 380 monitors signals received from the customer 302 in order to detect CV2 data, as described above. Upon detection of the customer's CV2 data, the call processor 380 sends a request for a CV2 validator, comprising the token requestor ID and the CV2 data, to the TSP 370.
The TSP 370 generates a CV2 validator and stores the CV2 validator, along with the CV2 data and the token requestor ID, in a table which is separate from the table containing the payment token and customer PAN. Storage in a separate table is necessary as the call processor 380 does not have access to the payment token. Therefore, the call processor 380 is not capable of establishing a direct relational link between the customer's PAN and CV2 data. Instead, the customer's CV2 data and the CV2 validator are mapped to the token requestor ID.
The call processor 380 may output the CV2 validator to the contact center 310 as described in the second aspect of the first embodiment.
Following input of the CV2 validator, the payment token is retrieved from storage within the contact center 310. The card expiry date may also have been stored within the contact center 310, and may be retrieved if necessary. Following retrieval of the relevant information, the transaction proceeds as described in the second aspect of the first embodiment. Again, the payment network 340 interfaces with the TSP 370 to detokenize the payment token.
The TSP 370 returns the customer PAN, along with the token requestor ID, which is stored in the table mapping the payment token to the customer's PAN. The payment network 340 then sends a request, comprising the CV2 validator and token requestor ID, to the TSP 370 for return of the customer's CV2 data. As described above, the token requestor ID is stored in the table mapping the CV2 data to the CV2 validator and thus the TSP 370 is able to authenticate the request and return the customer's CV2 data.
As described above, the payment network 340 may also perform a domain restriction check.
Authorization by the card issuer 350, issuance of an authentication response, tokenization of any sensitive information comprised within the authentication response, and deletion of the CV2 data and CV2 validator are carried out by the relevant entities as described in the second aspect of the first embodiment.
In addition, the call processor 380 may request deletion of the payment token stored at the TSP 370, as described above. Alternatively, the payment token may be stored within the contact center 310 for future transactions, if necessary.
Alternative Telephone-Based Transaction Environments
As noted above with reference to
In the contact center environment 400, the customer's sensitive data is tokenized using the methods as described above with respect to the first embodiment illustrated in
The call processor shown in
Call Processor for Use in Telephone-Based Transactions
The call processor 780 may further comprise a TSP interface 794, operable to request a payment token from a TSP and receive tokenized information. The TSP interface 794 may further be operable to send CV2 data to the TSP and request updating of a token assurance level associated with the payment token. The call processor 780 may further comprise a surrogate validation information generator 792, operable to generate a three- or four-digit random number for use as dummy CV2 data.
Additionally, the TSP interface 794 may further be operable to request deletion of the payment token stored at the TSP. The TSP interface 794 may send such a request upon receipt of a notification from the contact center that payment has either been authorized or declined. Therefore, the signal monitoring means 782 may further be operable to monitor signals received from the contact center for indications conveying the success or failure of the transaction. Alternatively, or in addition, the TSP interface 794 may send the request for deletion of the payment token upon expiry of a predetermined time period.
As noted above, the call processor 780 may interface with a TSP which is capable of generating a CV2 validator in response to receiving CV2 data, and storing the CV2 validator and associated CV2 data. In this case, the TSP interface 794 may be operable to send a request for a CV2 validator to the TSP along with a customer's CV2 data, and receive a CV2 validator in return.
In addition, the call processor 780 may comprise signal converting means 784. The signal converting means 784 may be operable to convert any payment tokens and CV2 validators received from the TSP or dummy CV2 data generated by the surrogate validation information generator 792 to a format suitable for output to the contact center. As described above, this information may be output as DTMF tones or spoken text, and/or may be output directly to the computer terminal of the contact center agent. Therefore, the signal converting means 784 may be operable to convert the tokenized, validator, or dummy information to DTMF tones or spoken text and to output this information in an audible format to the phone of the contact center agent. Additionally, the signal converting means 784 may be operable to output the data directly to the computer terminal of the contact center agent.
In order to facilitate the monitoring of signals, request for tokenized information, and subsequent conversion for output in a suitable format, the call processor 780 may comprise buffering means 786, operable to store a portion of the signals so that the monitoring, requesting and converting do not need to be carried out instantaneously.
The call processor 780 may optionally comprise a token assurance level determiner 790, operable to compare a received updated token assurance level against a predetermined threshold and determine whether a transaction may proceed.
Web-Based Transactions
Sensitive information may alternatively be provided by a customer in a web-based transaction. As stated above, web-based transactions are also classed as CNP transactions. A schematic diagram of the entities involved in such a known transaction 800 is shown in
Information input at the customer terminal 910 may be routed to the intermediary processor 980 acting as a proxy. This is achieved as a result of a prior arrangement between the merchant system 962 and the proprietor of the intermediary processor 980. For example, the merchant system 962 with domain name www.merchant.com at IP address 1.2.3.4. may update the DNS lookup to configure communications addressed to www.merchant.com to be routed to the IP address of the intermediary processor 980, for example 5.5.5.5. The intermediary processor 980 at IP address 5.5.5.5. then initiates a connection with the merchant system 962 at IP address 1.2.3.4.
Alternatively, only a sub-domain of the merchant system 962 may be proxied to the intermediary processor 980. For example, if the customer 902 accesses the domain name www.merchant.com and selects products intended for purchase, the customer 902 may be redirected to cart.merchant.com upon initiating a command to proceed to a payment page. The subdomain cart.merchant.com may be located at a different IP address to the merchant system 962 and communications addressed to the subdomain may be routed to the IP address of the intermediary processor 980 as described above.
As a further alternative, the URL accessed from the customer terminal 910 may be changed in order to redirect the connection from the customer terminal 910 to the intermediary processor 980. For example, the customer 902 requesting a connection to www.merchant.com may be redirected to a different URL, such as merchant.processor.com.
The sensitive information may be input as numerical data by the customer 902 at the customer terminal 910. Alternatively, the sensitive information may be provided by an application running on a mobile device, or by any other third party application authorized by the customer 902 to provide sensitive information to merchant system 962.
Upon detection of the PAN and card expiry date provided by the customer 902, the intermediary processor 980 requests a payment token from the TSP 970, in a similar way as described above with respect to the first embodiment, illustrated in
CV2 data input at the customer terminal 910 may also be detected by the intermediary processor 980. The intermediary processor may generate ‘dummy’ CV2 data and request an updated token assurance level in the same way as described in the first aspect of the first embodiment.
The intermediary processor 980 may then send the payment token and dummy CV2 data to the merchant system 962. As described above, the protected information can be output using a number of different methods enabling verification of entry of information. However, in a web-based transaction, it may not be necessary to employ IVR systems or contact center agents. Therefore, the protected information may be output directly to the merchant system 962. The protected information may then be passed to the payment network 940 as described in the first embodiment. As the payment token complies with the same formatting and validation rules as the customer's PAN, the transaction proceeds as if the customer's PAN and card expiry date had been input at the customer terminal 910.
Detokenization of the protected information, authorization by the card issuer and subsequent re-tokenization of the customer PAN are carried out in the same way as described in the first aspect of the first embodiment, illustrated in
Upon receipt of the authorization message, the merchant system 962 may send a notification to the customer terminal 910 relaying the success or failure of the transaction. The intermediary processor 980 may optionally be operable to send a request to the TSP 970 for deletion of the payment token and associated customer information, on the basis of any message sent from the merchant system 962 to the customer terminal 910, and/or after expiry of a predetermined period of time.
Web-Based Transactions Involving TSPs with CV2 Storage Capability
As described in the second aspect of the first embodiment illustrated in
The intermediary processor 980 may then send protected information, comprising the payment token and CV2 validator to the merchant system 962. The protected information may then be passed to the payment network 940 as in the second aspect of the first embodiment, illustrated in
Detokenization of the payment token, retrieval of the CV2 data, authorization by the card issuer and subsequent re-tokenization of the customer PAN are carried out in the same way as in the second aspect of the first embodiment, illustrated in
As described in the second aspect of the first embodiment, the payment network 940 and/or the TSP 970 may instigate deletion of the CV2 data stored at the TSP 970. In addition, the intermediary processor 980 may request deletion of the payment token and customer PAN stored at the TSP 970.
Subsequent Web-Based Transactions by the Same Customer
As noted with respect to the third aspect of the first embodiment, some merchant systems may store a payment token associated with a particular transaction, so that a customer can make ‘repeat’ transactions without providing their PAN and card expiry date. Therefore, in a third aspect of the fifth embodiment illustrated in
The CV2 validator is then sent to the merchant system 962, which retrieves the payment token from storage. Following retrieval of the relevant information, the transaction proceeds as described in the third aspect of the first embodiment, illustrated in
Alternative Web-Based Transaction Environments
Locating the intermediary processor 1080 within the merchant center 1060 does not affect the processes described above with reference to the fifth embodiment, illustrated in
Intermediary Processor for Use in Web-Based Transactions
The intermediary processor 1180 may comprise a TSP interface 1194, surrogate validation information generator 1192 and token assurance level determiner 1190, each having the same functionality as the equivalent components of the call processor shown in
Exemplary Processes
The first part of the method is shown in
In step 1214, the contact center agent asks the customer to enter their CV2 data, which the customer enters in step 1216. In step 1218, the call processor sends the CV2 data to the TSP with a request for the token assurance level to be updated. After passing the PAN and CV2 to the card issuer, which generates an updated token assurance level in step 1220, the TSP returns an updated token assurance level in step 1222. In step 1224, the call processor may optionally check that the updated token assurance level exceeds a predetermined threshold before permitting the transaction to proceed. In step 1226, the call processor generates random 3-digit ‘dummy’ CV2 data and, in step 1228, outputs the dummy CV2 data to the contact center for input at the contact center agent's computer terminal.
In step 1230, the contact center agent submits the surrogate information input at the computer terminal, which is then routed to the payment network in step 1232. In step 1234, the payment network recognizes that the information routed from the contact center is tokenized and consequently requests detokenization of the payment token.
The remainder of the method is illustrated in
In step 1240, the payment network sends the customer's PAN and other transaction details to the card issuer, along with the ‘on-behalf-of’ validation indicator. In step 1242, the card issuer either authorizes or declines the transaction, and sends an authorization response back to the payment network in step 1244. In step 1246, the payment network sends a request to the TSP for re-tokenization of any sensitive information contained within the authorization response. The TSP returns the payment token in step 1248, which the payment network then includes in the authorization response in place of the sensitive information. In step 1250, the authorization response is routed to the contact center. In step 1252, the contact center agent advises the customer whether the transaction has been authorized or declined.
Optionally, in step 1254, the call processor waits for a predetermined time period and/or for confirmation from the contact center that the transaction has been authorized or declined. Upon expiry of the time period and/or receipt of confirmation, the call processor, in step 1256, sends a request to the TSP for deletion of the payment token and associated sensitive customer information. In step 1258, the TSP deletes this information as instructed and notifies the call processor of the outcome in step 1260.
The first part of the method is shown in
In step 1310, the customer enters their CV2 data. In steps 1312 to 1322, the intermediary processor requests that the token assurance level be updated and generates ‘dummy’ CV2 data in the same way as in steps 1218 to 1228 of
In step 1324, the merchant system submits the protected information. In steps 1326 to 1332 of
In steps 1348 to 1354, the intermediary processor may optionally request deletion of the payment token and associated customer information as in steps 1254 to 1260 of
The first part of the method is shown in
In step 1418, the call processor sends the CV2 data to the TSP with a request for a CV2 validator to be returned. The TSP generates a CV2 validator and stores the mapping of the customer's CV2 data to the CV2 validator, in step 1420. The CV2 validator is then returned to the call processor. In step 1422, the call processor outputs the CV2 validator to the contact center for input at the contact center agent's computer terminal.
In steps 1424 to 1428, the transaction proceeds as in steps 1230 to 1234 of
The remainder of the method is illustrated in
After the payment network has routed the authorization response to the contact center, the payment network sends a request to the TSP for deletion of the CV2 data and CV2 validator stored at the TSP, in step 1446. In step 1448, the TSP deletes the CV2 data and CV2 validator.
The first part of the method is shown in
In step 1510, the customer enters their CV2 data. In steps 1512 to 1516, the intermediary processor requests, receives and outputs a CV2 validator as in steps 1418 to 1422 of
In step 1544, the merchant system sends a notification to the customer indicating whether the transaction has been authorized or declined. Steps 1546 to 1552 of
The first part of the method is shown in
In step 1610, the payment token is retrieved from storage at the contact center. In step 1612, the contact center agent submits the retrieved information and CV2 validator input at the computer terminal. In steps 1614 and 1616, the transaction proceeds as in steps 1426 and 1428 of
In steps 1624 to 1628 of
The first part of the method is shown in
In step 1708, the payment token is retrieved from storage at the merchant system. In step 1710, the merchant system submits the retrieved information and CV2 validator output by the intermediary processor. In steps 1712 to 1730 of
In step 1738, the merchant system sends a notification to the customer indicating whether the transaction has been authorized or declined. In step 1740, the payment token is stored within the merchant system for future transactions, if appropriate.
Alternative Embodiments
In the first to sixth embodiments and associated exemplary processes, illustrated in
Alternatively, in a seventh embodiment, the TSP may be located at, or comprised within, the call processor. This embodiment is shown in
Alternatively, the surrogate information generator 1872 may not have the capability for CV2 validator generation and the surrogate information vault 1874 may not have the capability for CV2 validator storage. In this case, the surrogate information generator 1872 passes only the generated token, via the TSP interface 1894, to the signal converting means 1884. Further, the assurance level requestor 1878 may be operable to request an updated token assurance level from a card issuer on the basis of CV2 information received from the TSP interface 1894 and send the updated token assurance level via the TSP interface 1894.
After the surrogate information has passed through the contact center, any entity may request detokenization of the payment token. The surrogate information vault 1874 may further be operable to store details of entities authorized to request detokenization of the protected information. Upon detokenization, the surrogate information generator 1872 may further be operable to validate the CV2 validator received from the payment network against the CV2 validator stored in the surrogate information vault 1872.
The entity requesting detokenization may receive the sensitive customer information from the call processor 1880 on the condition that the entity is authorized to do so. The detokenization authenticator 1876 may compare credentials received from the entity with those stored in the token vault and may send the sensitive customer information to that entity if the authorization criteria are met.
An eighth embodiment of the present invention is illustrated in
The invention has been described above with reference to specific embodiments. Persons skilled in the art, however, will understand that various modifications and changes may be made thereto without departing from the broader scope of the invention as set forth in the appended claims. The foregoing description and drawings are, accordingly, to be regarded in an illustrative rather than a restrictive sense.
| Number | Date | Country | Kind |
|---|---|---|---|
| 1521304.4 | Dec 2015 | GB | national |
