A SYSTEM AND METHOD FOR SECURELY DELIVERING INFORMATION

Abstract

A computer-implemented method for correlating payment service submissions and data captured from a call stream is described herein. The method comprises receiving data captured from a call stream by a data capture device; receiving a payment service submission comprising an identifier; determining an association between the identifier and the call stream; and replacing the identifier in the payment service submission with the data captured from the call stream associated with the identifier.

Claims

1. A computer-implemented method for correlating payment service submissions and data captured from a call stream, the method comprising: receiving data captured from a call stream by a data capture device; receiving a payment service submission comprising an identifier; determining an association between the identifier and the call stream; and replacing the identifier in the payment service submission with the data captured from the call stream associated with the identifier.

2. The method of claim 1, wherein the identifier is a first identifier, or wherein the identifier is a second identifier generated from a first identifier.

3. The method of claim 2, further comprising generating the second identifier.

4. The method of any one of claims 1 to 3, wherein determining an association between the identifier and the call stream comprises using metadata for the call stream.

5. The method of claim 4, wherein the metadata is the identifier or one is algorithmically derivable from the other.

6. The method of claim 4 when dependent upon claim 2, wherein the identifier is the second identifier, and wherein the metadata is the first identifier or one is algorithmically derivable from the other.

7. The method of any one of claims 4 to 6, wherein determining an association between the identifier and the call stream comprises using a lookup table comprising metadata for each call stream of a plurality of call streams.

8. The method of any one of claims 1 to 7, further comprising forwarding the payment service submission with the data captured from the call stream associated with the identifier to an external system and/or storing the payment service submission in memory.

9. The method of any one of claims 2 to 8, wherein the first identifier and/or the metadata is derived from one or more of: a telephone number associated with a party to the call stream; an identifier present or injected into the call stream; current time; a random number; and a sequence number representing the number of times data has been captured from the call stream.

10. The method of any one of claims 2 to 9, wherein the call stream is associated with an agent and wherein the first identifier and/or the metadata is derived from an identification number for the agent and/or a telephone number associated with the agent.

11. The method of any one of claims 2 to 10, wherein the second identifier complies with a predetermined format.

12. The method of any one of the preceding claims, further comprising passing a capture identifier to the data capture device.

13. A computer-implemented method for preparing a payment service submission, the method comprising: receiving input data for a payment service submission; and sending a payment service submission to a server, the payment service submission comprising: the received input data, and an identifier associated with a call stream, optionally wherein the input data comprises said identifier.

14. The method of claim 13, wherein the identifier is a first identifier, or wherein the identifier is a second identifier generated from a first identifier.

15. The method of claim 14, further comprising generating the second identifier from the first identifier.

16. The method of claim 14 or claim 15, wherein the first identifier is derived from one or more of: a telephone number associated with a party to the call stream; an identifier present or injected into the call stream; current time; a random number; and a sequence number representing the number of times data has been captured from the call stream.

17. The method of any one of claims 14 to 16, wherein the call stream is associated with an agent and wherein the first identifier is derived from an identification number for the agent and/or a telephone number associated with the agent.

18. The method of claim 17, wherein the input data comprises data entered by the agent.

19. The method of any one of claims 13 to 18, wherein the input data comprises data received from a client management system.

20. The method of any one of claims 14 to 19, wherein the second identifier complies with a predetermined format.

21. The method of claim 20, wherein the payment service submission is sent to the server via a payment system, and wherein the predetermined format is imposed by said payment system.

22. The method of any one of claims 14 to 21, wherein the second identifier is generated prior to the receipt of input data for a payment service submission.

23. The method of any one of claims 14 to 22, wherein the second identifier is generated posterior to the receipt of input data for a payment service submission.

24. The method of any one of claims 13 to 23, further comprising passing a capture identifier to a data capture device.

25. A computer-implemented method for processing data captured from a call stream, the method comprising: performing the steps of claim 13; and performing the steps of claim 1, wherein: the call stream of claim 1 is the call stream of claim 13; the identifier of claim 1 is the identifier of claim 13, and the received payment service submission of claim 1 is the sent payment service submission of claim 13.

26. The method of claim 25, wherein the identifier of claims 1 and 13 is a first identifier, or wherein the identifier of claims 1 and 13 is a second identifier generated from a first identifier.

27. The method of claim 26, further comprising generating the second identifier.

28. The method of any one of claims 25 to 27, wherein determining an association between the identifier and the call stream comprises using metadata for the call stream.

29. The method of claim 28, wherein the metadata is the identifier or one is algorithmically derivable from the other.

30. The method of claim 28 when dependent upon claim 26, wherein the identifier is the second identifier, and wherein the metadata is the first identifier or one is algorithmically derivable from the other.

31. The method of any one of claims 28 to 30, wherein determining an association between the identifier and the call stream comprises using a lookup table comprising metadata for each call stream of a plurality of call streams.

32. The method of any one of claims 25 to 31, further comprising forwarding the payment service submission with the data captured from the call stream associated with the identifier to an external system and/or storing the payment service submission in memory.

33. The method of any one of claims 26 to 32, wherein the first identifier and/or the metadata is derived from one or more of: a telephone number associated with a party to the call stream; an identifier present or injected into the call stream; current time; a random number; and a sequence number representing the number of times data has been captured from the call stream.

34. The method of any one of claims 26 to 33, wherein the call stream is associated with an agent and wherein the first identifier and/or the metadata is derived from an identification number for the agent and/or a telephone number associated with the agent.

35. The method of claim 34, wherein the input data comprises data entered by the agent.

36. The method of any one of claims 25 to 35, wherein the input data comprises data received from a client management system.

37. The method of any one of claims 26 to 36, wherein the second identifier complies with a predetermined format.

38. The method of claim 37, wherein the payment service submission is sent to the server via a payment system, and wherein the predetermined format is imposed by said payment system.

39. The method of any one of claims 26 to 38, wherein the second identifier is generated prior to the receipt of input data for a payment service submission.

40. The method of any one of claims 26 to 39, wherein the second identifier is generated posterior to the receipt of input data for a payment service submission.

41. The method of any one of claims 25 to 40, further comprising passing a capture identifier to the data capture device.

42. The method of claim 12 when dependent on claim 2, the method of claim 24 when dependent on claim 14, or the method of claim 41 when dependent on claim 26, wherein the capture identifier is the first or second identifier.

43. The method of claim 12 when dependent on claim 2, the method of claim 24 when dependent on claim 14, or the method of claim 41 when dependent on claim 26, wherein the capture identifier is algorithmically derivable from the first or second identifier.

44. The method of claim 12 when dependent on claim 7, or the method of claim 41 when dependent on claim 31, wherein the capture identifier is derived from a lookup of the first or second identifier in the lookup table.

45. The method of claim 12, claim 24, claim 41 or any one of claims 42 to 44, wherein the capture identifier is passed as part of a command to modify or capture data from the call stream.

46. The method of claim 12, claim 24, claim 41 or any one of claims 42 to 45, wherein a command to modify or capture data from the call stream is sent to the data capture device separately from the capture identifier.

47. The method of claim 12, claim 24, claim 41 or any one of claims 42 to 46, wherein the call stream comprises a signalling stream, and wherein the command and/or capture identifier is passed to the data capture device via the signalling stream as a special message or a message that has been repurposed by special interpretation.

48. The method of claim 12, claim 24, claim 41 or any one of claims 42 to 47, wherein the call stream comprises an audio stream and wherein the command and/or capture identifier is passed to the device as DTMF tones in the audio stream.

49. The method of claim 48 further comprising selectively blocking the DTMF tones from being sent to another party present in the audio stream.

50. The method of claim 12, claim 24, claim 41 or any one of claims 42 to 49, wherein passing the command and/or capture identifier occurs in response to sending or receiving the payment service submission.

51. A server configured to execute the steps of any one of claims 1 to 12, or any one of claims 42 to 50 when dependent on claim 2.

52. An agent computer configured to execute the steps of any one of claims 13 to 24, or any one of claims 42 to 50 when dependent on claim 14.

53. A system comprising: a data capture device configured to capture data from a call stream; a server configured to execute the steps of any one of claims 1 to 12, or any one of claims 42 to 50 when dependent on claim 2; and an agent computer configured to execute the steps of any one of claims 13 to 24, or any one of claims 42 to 50 when dependent on claim 14.

54. The system of claim 53 when dependent on claim 2, claim 14, or claim 26, wherein the second identifier is constructed at the server and passed to the agent computer.

55. The system of claim 53 when dependent on claim 2, claim 14 or claim 26, wherein the second identifier is constructed at the agent computer.

56. The system of any one of claims 53 to 55, wherein the command is passed to the data capture device from the agent computer.

57. The system of any one of claims 53 to 55, wherein the command is passed to the data capture device from the server.

58. A computer-implemented method for capturing data in a call distribution system, the method comprising: receiving a call stream routed from a telephone network; sending call metadata associated with the call to a server; capturing data from the call stream; and transmitting the data captured from the call stream to the server.

59. The method of claim 58, comprising receiving an agent identification number and/or an agent telephone or extension number, wherein the call metadata optionally comprises the agent identification number and/or the agent telephone or extension number.

60. The method of claim 59, wherein the agent identification and/or an agent extension identification is received from an agent.

61. The method of any one of claims 58 to 60, wherein capturing data from the call comprises continuously capturing data from the call.

62. The method of any one of claims 58 to 61, wherein capturing data from the call comprises capturing data from the call when it is detected that a call has been put through to an agent.

63. The method of any one of claims 58 to 62, comprising storing the data captured from the call stream and transmitting the data captured from the call stream in response to receiving a capture identifier associated with the data captured from the call stream.

64. The method of any one of claims 58 to 63, comprising storing the data captured from the call stream and selectively transmitting the data captured from the call stream to the server based on a rule set comprising a combination of temporal and data content pattern matching.

65. The method of any one of claims 58 to 64 wherein capturing data from the call comprises capturing data from the call in response to receiving a capture command.

66. The method of claim 65, wherein the capture command comprises a call identifier associated with the data captured from the call stream, and wherein the call identifier optionally comprises an agent identification number, an agent telephone or extension number, and/or a globally unique identifier.

67. The method of any one of claims 58 to 66, wherein capturing data from the call comprises capturing DTMF data or capturing audio data using automatic speech recognition.

68. The method of any one of claims 58 to 67, wherein capturing data from the call comprises capturing data from call signalling or media stream of the call.

69. The method of any one of claims 58 to 68, wherein the data is captured from the call stream by means of digit pattern and temporal pattern recognition, optionally wherein received digits are queued before retransmission to allow discernment of patterns.

70. The method of any one of claims 58 to 69, wherein the metadata comprises a capture device identification.

71. A data capture device configured to execute the method of any one of claims 58 to 70.

72. A computer-readable storage medium containing instructions which, when executed by a processor, cause the processor to carry out the method of any one of claims 1 to 50 or 58 to 70.

Description

BRIEF DESCRIPTION OF THE FIGURES

[0067] Embodiments of the invention will be described, by way of example, with reference to the following figures, in which:

[0068] FIG. 1 illustrates a telephony system in which a computer of a contact centre agent is running a “call-aware” application, in accordance with an embodiment of the present invention;

[0069] FIG. 2 illustrates an exemplary exchange of messages by components of the system of FIG. 1, in accordance with an embodiment of the present invention;

[0070] FIG. 3 illustrates a telephony system, comprising a CTI system, in which the agent computer is running an application that is not, or need not be, “call-aware”, in accordance with an embodiment of the present invention;

[0071] FIG. 4 illustrates an exemplary exchange of messages by components of the system of FIG. 3, in accordance with an embodiment of the present invention;

[0072] FIG. 5 illustrates a sequence diagram for a method of processing a payment, in accordance with an embodiment of the present invention; and

[0073] FIG. 6 illustrates a sequence diagram for another method of processing a payment, in accordance with an embodiment of the present invention.

DETAILED DESCRIPTION

[0074] The following description refers to an embodiment of the invention shown with reference to FIGS. 1 and 2.

[0075] A call is passed from a telephone network 100 to a DTMF capture device 101 and is in turn routed to a private branch exchange/automatic call distributor (PBX/ACD) system 102. In some embodiments (not shown) the call may be passed via IVR system which may be prompt the caller for information which can be used by the PBX/ACD to direct the call to a suitable agent. Alternatively, the agent selection process may also involve other criteria such as the number of calls taken by each agent since the start of their shift, a particular agent's skill sets, the priority and position in the queue of the caller, information about the caller and or their previous interactions with the organisation (which may include interactions over non-voice channels) stored in a CRM and other techniques familiar to a person skilled in the art. In any event, once a suitable agent has become available the call is directed to the agent.

[0076] At some point during the call the DTMF capture device 101 sends call metadata to a server 106, which maintains a lookup table of call metadata and, optionally, a DTMF capture device ID (for example where there are several DTMF capture devices in a single organisation). Transmission of the call metadata to the server 106 will normally happen at the beginning of the call, but this is not essential and may take place when the call has been answered by an agent or at any other point in the call. In the latter case, the system may be capable of sending an agent ID or an agent's extension ID (such as the agent's extension number) after the call has been answered, using the call signalling messages. In a SIP system, this may typically happen via a reINVITE, UPDATE, SIP INFO or MESSAGE message.

[0077] In the embodiment shown in FIGS. 1 and 2, the agent is using an agent GUI including a “call aware” application 104. Accordingly, call metadata will be passed to the application as the call is directed to the agent. The application may include APIs to allow customised extensions to be added to it, and these extensions will typically have access to the call metadata. One such custom extension includes a token generator 105. Others (not shown) provide extensions to the agent GUI. The token generator 105 generates a token in a prescribed format which is designed to be acceptable to a payment system 108. Various algorithms may be used in this process, and inputs to these algorithms may include both call and agent metadata to help guarantee uniqueness in the context of the contact centre within an acceptable time window. For example, if the required token format is long enough, a random number generator may suffice as the sole input to the algorithm before processing the output to meet formatting requirements. Formatting requirements may, for instance, require that the token be 19 digits long and pass a mod 10 checksum (otherwise known as a Luhn check). Alternative or additional inputs to the algorithm may include an agent ID or an agent's extension ID (such as the agent's extension number) mentioned above. Alternatively or additionally, inputs to the algorithm may include a call sequence number or other unique identifier assigned either by a component of the telephony system or by the DTMF capture device 101 and added to the signalling message stream. Alternatively, or additionally, inputs to the algorithm may include the current system time and/or date.

[0078] It will be appreciated that because some systems may use identifiers which do not readily lend themselves to inclusion in the token by way of simple concatenation, it may be necessary to perform a transformation to facilitate their use. For instance, a telephone system may produce a unique call identifier which is 30 characters long and alphanumeric in form. In order to use such an identifier in a token it would be necessary to transform it into a shorter all numeric form while still preserving as much entropy as possible. This could be achieved by passing the identifier or concatenated combination of identifiers through a hashing algorithm. Care must be taken to choose a hashing algorithm that exhibits good dispersion across the key space. Examples of suitable algorithms are SHA-1 and SHA-256 (a member of the SHA-2 family). The outputs of these algorithms are digests of 160 and 256 bits respectively, which may be truncated to the required length if they are too long for any given token system. (It will be understood that because both of these particular algorithms produce good dispersion, it is perfectly practical to truncate their output as described with low risk of collisions.)

[0079] A particular example of the above technique according to the invention is now described. By using one, some or all of the aforementioned inputs to an algorithm, a telephony system may produce an identifier such as TAQEEPJECT6OR7P4025DMIAV7K000003. This identifier would not be suitable as a token for use in a system expecting bank card numbers since it does not have the correct format. The SHA-1 hash of this is string, expressed in hexadecimal form, is 3073980df17a9d12d786fe1e82ab53d0cee7818e. Taking the least significant 12 hex digits of the SHA-1 hash (i.e. 53d0cee7818e) and converting this truncation to decimal yields a string of numerical digits, 92156289581454. Prepending this string with a 0 and then appending a suitable check digit to make the resulting number pass a Luhn check yields the number 0921562895814544. This number would be an acceptable token format for most payment systems. As will be appreciated, the first digit of a Bank or Credit card number is known as the Major Industry Identifier or MII. The digit ‘0’ is currently reserved for future use by ISO/TC 68 and so by prepending the converted truncated hexadecimal SHA-1 hash with a 0, the resulting number is guaranteed not to clash with any card in issue. The usage of an unallocated MII is optional, but has the advantage of distinguishing the resulting token from regular Bank or Credit card numbers, but otherwise has no deleterious impact on the operation of the system.

[0080] It will be appreciated that the above example is simply one way of generating a suitable token of the correct format for use in a system expecting bank card numbers. For instance, it would also be perfectly possible to construct the token using an allocated MII, but the resulting token may no longer be distinguishable from a real card number unless the first digits had been deliberately been chosen from an unused BIN range. Moreover, any suitable technique can be used for generating a number which will satisfy the format of a Bank or Credit card numbers, once a suitable check digit has been appended to make the resulting number pass a Luhn check.

[0081] When the agent is ready to capture data from the voice or signalling stream, he issues a command from the agent GUI that is sent to the server 106. The command can be sent for example as an HTTP or HTTPS request, although other protocols are equally suitable. At the same time as sending the command, parameters are also sent to the server 106. These parameters include the generated token, but may also include additional call metadata, which is advantageous if the chosen token format does not allow the server to recover the information (i.e. the unique call ID) used for call correlation. For example, this metadata optionally sent with the command may include a GUID (globally unique identifier) which is present in the call signalling stream and thus known to the DTMF capture device 101.

[0082] On receipt of the command, server 106 uses the unique call ID extracted from the token and/or the call metadata either extracted from the token or from the command parameter to locate the correct DTMF capture device 101 and send it a command to capture data from the corresponding call. DTMF capture device 101 then proceeds to capture the data in question (namely, DTMF tone representing a caller's Bank or Credit card details, including a PAN and CV2) and sends the captured data to server 106, which forwards it optionally along with the generated token to an intermediate server 107 where it is stored in a lookup table for later use.

[0083] The HTTP or HTTPS request made by the extended agent GUI to initiate the data capture may block audio and/or data signals being sent downstream to the telephony system and onwards to the agent until the capture is complete. The request may return a status code to the GUI, or alternatively the exchange may be upgraded to a web socket that allows for fully duplex communication, allowing for the possibility of progress messages to be sent to the Agent GUI as the data is collected.

[0084] When the data capture has been successfully completed, the generated token is placed on the agent's clipboard ready to be pasted into a data entry field of an existing payment system. The payment system creates a submission payload, which includes the token and sends it to the intermediate server 107. The token may be located in place of other data (e.g. PAN) in the payload, or it may be added elsewhere (e.g. in a header).

[0085] On receipt of the submission payload, the intermediate server 107 extracts the captured caller's Bank or Credit card details corresponding to the received token from its lookup table, re-forms the submission payload appropriately incorporating the captured caller's Bank or Credit card details and forwards the re-formed submission to the PSP 109, returning the PSP response to the payment system as a response to the submission.

[0086] FIG. 2 shows the exchange of information as described above and operated by the system of FIG. 1.

[0087] The embodiment shown in FIGS. 3 and 4 operates in much the same way as the embodiment of FIGS. 1 and 2, with the following changes. In this embodiment, the agent is using an agent GUI which does not include a “call aware” application itself but instead uses call awareness that is embedded into their own applications using integration libraries provided by the PBX/ACD manufacturer. In this instance, the issuance of capture commands can be performed automatically in order to minimise disruption to the agent's workflow. For example, a capture command may be performed when the agent clicks in the PAN field in a form. Furthermore, in such examples, there would be no need to paste the generated token into a form as the application is able to perform this action by itself.

[0088] Note that the system has been described in terms of logical elements and may be implemented in different configurations. E.g. use of a microservices architecture may result in additional service layers. It is equally possible to collocate service elements on the same server For example, servers 106 and 107 could be implemented on the same physical server, which would result in a modified data flow between physical machines but would not cause the system or method to differ or fall outside of the scope of the present invention. Practical resilience considerations will also cause variations of implementation.

[0089] In the embodiment shown in FIG. 3, if the agent GUI application is not call aware, but the PBX/ACD manufacturer supports CTI clients (e.g. via a JTAPI interface), a CTI client 110 may be used to extract call metadata in much the same way as described above with reference to FIGS. 1 and 2, and send it to the server 106 to allow call correlation. In this embodiment, agent ID or an agent's extension ID (such as the agent's extension number) may be sent to the server 106 as a parameter to the command described previously in order to invoke DTMF capture. Alternatively, the token may be constructed in such a way as to allow direct recovery of the agent ID or an agent's extension ID (such as the agent's extension number) to allow the correlation to take place.

[0090] In some IP based telephony systems when the call is connected to an agent, extra messaging is sent towards the telephone network identifying the upstream systems of the agent's extension number. In a SIP-based system, this message normally takes the form of an UPDATE or reINVITE message with a new Contact header in it. Under these circumstances, and where the system otherwise operates as described previously, a CTI client is no longer necessary as the agent can send agent ID or an agent's extension ID (such as the agent's extension number) as the unique call identifier to initiate DTMF capture because DTMF capture device 101 will have already associated that agent ID or an agent's extension ID (such as the agent's extension number) with the call. By means of a lookup table, it is alternatively possible to use another identifier such as the agent's Windows logon name in place of the telephone extension number. This may be useful in scenarios where agents work in a ‘hot desk’ environment where their Windows profiles follow them but their phone extension number does not. In either of these scenarios it is also possible to have the system automatically enter a capture state when the DTMF capture device detects that the call has been connected to an agent. Temporal pattern matching can then be used to determine if detected data constitutes data that should be retained pending a submission request.

[0091] In this alternative embodiment, the DTMF capture device 101 will start listening for relevant data (which could be in DTMF or could be actual spoken data) as soon as it detects that the call has been put through to an agent. In order to decide if detected data should be retained or discarded, a pattern matching algorithm combining aspects of both data and temporal patterns can be employed. For instance, if a bank or credit card number is being captured, the rule set might be triggered by initial receipt of either of the digits ‘3’, ‘4’ or ‘5’ followed by further digits with a maximum interval between digits of 5 seconds. The expected number of digits could be determined by a BIN lookup using the first 6 digits. After the expected number of digits had been received, a final rule of passing a Luhn check could be applied. Failure to pass any of the rules would result in the stored digits being discarded and the ruleset state reset.

[0092] Selective audio blocking is disclosed in GB patent publication GB2526389, which may be used in combination with the above techniques.

[0093] In an alternative mode of operation, the system may exhibit automatic capture behaviour without having to detect if the call has been put through to an agent. For example, if rules similar to those described above are employed, a user navigating an IVR menu will not trigger capture mode because IVR menu structures are not typically deep enough to do so. Accordingly, automatic capture may begin instantly.

[0094] In another alternative mode of operation, the submission of a token may be used as a trigger to invoke DTMF capture. In such an embodiment, as described above, the agent GUI generates a token which is used by the payment system in the normal way, forming a submission payload which it sends to the intermediate server 107. When the intermediate server 107 receives the token as part of a submission payload, it extracts the appropriate call metadata from the token and forwards it to the server 106 and onwards to DTMF capture device 101 which finds the correct call and invokes data capture mode. The caller then inputs their Bank or Credit care details via DTMF, which is Luhn checked before being passed back to the server 107. If only a single piece of data is required to be captured (for example, if the transaction is a card transaction and the merchant uses only the PAN), the server 107 can make a suitable substitution of the PAN for the token and continues with its submission to the PSP, as described above. If multiple data captures are required (for example, if the transaction is a card transaction and the merchant is using CV2 in addition to the PAN), then the device 101 can play a prompt to the caller asking them to enter the required information before entering capture mode once again and returning the captured information to the server 107 to allow it to finish the submission. This embodiment completely removes the need for the agent to perform any additional actions beyond their normal workflow, and requires no modification to the Payment system 108 beyond a configuration change to the URL to point to intermediate server 107 in place of the PSP 109. In the cases described above, if visual live digit by digit feedback of the capture process to the agent is required it can be provided by a separate application.

[0095] If the merchant already has a stored PSP token and needs to capture a CV2 (without the PAN) in order to make a transaction with the PSP token then a much shorter temporary token will be required because the merchant's payment system CV2 field is likely to allow a maximum length of 4 digits. So long as the agent ID or an agent's extension ID (such as the agent's extension number) format does not exceed 4 digits this does not represent a problem as it should still be sufficient to uniquely identify a call. In the event that this condition cannot be met, the token can be sent in a header to the request.

Example 1 (with Reference to FIG. 5)

[0096] FIG. 5 shows a sequence diagram according to an embodiment of the invention.

[0097] As shown in FIG. 5, following a page request, all information from an agent is submitted to a PSP in a single request. Whilst the PSP receives a single request, there are multiple interactions between the proxy and the agent in order to allow control of the timing of the capture of the CV2 and to be able to provide visual feedback to the agent during the capture process. Configuring the system such that the agent is involved in triggering the capture of PAN and CV2 separately is desirable as it allows conversation to take place between the two events thus giving the opportunity for the agent to ‘hand hold’ the caller. This can be completely controlled by the proxy without any change to the agent's system or that of the PSP. Furthermore, the system is capable of informing the agent as to the issuing bank name (looked up from the BIN) as an extra measure to reduce fraud by cloning.

[0098] In the example shown in FIG. 5, the proxy will modify the payment screen code that it receives from the PSP on at least one count. Firstly, it will need to pre-populate the PAN and CV2 fields with dummy values in order to satisfy the javaScript validation code embedded in the page which would otherwise prevent the agent from submitting the form with this data missing. Pre-populating the PAN and CV2 fields is, in effect, generation of the token at the server side at the moment the system is operable and operated to take a payment (but before DTMF capture). Secondly, in some implementations, it may be beneficial for the proxy to add a field for the agent to enter their ‘End point ID’ or EPID, which could be done by means of a permanent cookie—for example set once on the machine by visiting a special page, which links the agent's workstation and their phone extension together.

[0099] An alternative approach to modifying the payment screen code received from the PSP is for the proxy to serve a payment screen which it generates itself (i.e. which is not generated by the PSP). This payment screen would be without PAN and CV2 field validation, but would contain the same fields as the original form for later submission to the PSP.

[0100] In either scenario there would be provision for the agent to enter a token in place of a card number, as described elsewhere herein, in which case the flow sequence would revert to conventional behavior and no capture process would take place.

[0101] In the embodiment of FIG. 5, the return URL is configurable as to whether it directs to the agent or via the proxy. An indirect result path via the proxy would allow determination, at the proxy, of the quantity of transactions rather than simply the quantity of calls, which may be beneficial for reporting reasons. In another embodiment, the merchant may wish to use a payment page served by the Payment Services Provider (aka PSP or Payment Gateway). Such arrangements are known as ‘Hosted Payment Pages’ (HPP) in the UK but may be known by other names elsewhere.

[0102] Referring to the systems described above in connection with FIGS. 1 to 4, in these cases, there will be an initial request from the agent to the PSP 109 via the intermediate server 107 for the payment page. In this request, the agent sends an identifier such as a unique call identifier, including their agent ID or an agent's extension ID (such as the agent's extension number). The intermediate server 107 may then fetch the page from the PSP on behalf of the agent, and modify the page by inserting a token into the form field which is intended for entry of the PAN. Because of form validation rules, as in the example described above with regard to the CRM, this token is preferably properly formatted so as to be acceptable to the system. This avoids the risk of page code changes made by the PSP, which would otherwise require ‘on-the-fly’ code modification. Further modification of the page may be performed to embed a control mechanism to initiate PAN and CV2 capture (e.g. by embedding ‘capture’ buttons in the page). The embedded token or dummy card number could be constructed from the data supplied by the agent during the original request or it could simply be either a suitable fixed or randomly generated number constructed to pass the validation rules. In the former case where the token or dummy card number entered into the form field is generated from call correlation data supplied by the agent, it would not be necessary to add any other data when the form is submitted for payment after capture since sufficient information would already be present in the request to identify the call directed to the agent.

[0103] In the second case where the token, or unique call identifier such as a dummy card number is generated without reference to data supplied from the agent side then the subsequent submission for payment usefully includes sufficient information to correlate the call. This information could either be supplied explicitly as parameters to the submission request or could be set in a web session cookie on the first request, which would result in the information being automatically available, for example by setting session affinity or stickiness in any load balancer in front of the server farm. The advantage of the token or unique call identifier being used as a session identifier is that it removes the need for a session-aware load balancer in an HA setup where there are multiple instances of intermediate server 107.

[0104] In another variation of the above, the page is not modified by insertion of a unique call identifier such as a dummy card number or token, but instead the identifier or token is sent to the agent's web browser by means of a side channel (such as a web socket) and inserted into the submission form by code, the original page request having been made to include sufficient information to enable the server to identify the call. In this instance, as above, the form of the unique call identifier such as a dummy card number or token must be chosen to pass validation rules in order to avoid the need to modify code in the page that could lead to fragility against changes which are outside the control of the merchant or system operator. Once again, call correlation information can be set either in the session or in the unique call identifier such as a dummy card number or token.

Example 2 (with Reference to FIG. 6)

[0105] FIG. 6 shows a diagram including a proxy for web-based payment requests, which integrates with PCI system.

[0106] Typically, a CRM supplier will display a payment page from a PSP in an iFrame in their (web based) CRM. This page is the same page that is used for e-commerce on a vendor's web site displayed in an iFrame. This arrangement leads to a two-stage transaction. The original GET requests to the PSP is made with all transaction data but not the actual card data. The PSP then stores this data and returns a form to display to the customer for card entry. This form contains several hidden fields that link the subsequent post to the original GET. When the form is submitted with the card data, the PSP performs the authorisation and then submits the result both to the browser and to the merchant's server via a separate POST for back-end reconciliation purposes.

[0107] This approach is something of a workaround because this mode of interaction is typically not intended for CNP (customer not present) transactions, and whilst it works adequately in the context of an iFrame in a CRM, improvements may be desired in other contexts.

[0108] The inventor has realised that most if not all PSPs support an additional mode of interaction by way of direct link (for example, Chase PaymentTech uses Orbital). Other PSPs provide a simpler form of direct method which simply involves a single POST to their server with the response coming back in a small XML structure. A proxy in a system according to the invention may therefore act as the front-end to the PSP, and serve its own web pages with forms to collect the data. These forms would also allow a direct POST or GET to allow for a program such as a CRM sending us the request, and then to trigger the card capture by receipt of separate requests (see FIG. 6). In this case, the proxy sends all data to the PSP via direct link and constructs the results page from the codes returned in the XML.

[0109] With this approach it is simple to support multiple merchant accounts across multiple PSPs, using a different servlet for each PSP and parameters in the original request to select the merchant and credentials to use.

[0110] Each merchant can have their own set of pages with their own branding if required. This approach also allows the system to be easily tailored as to which of the many optional fields to include on a per merchant/PSP combination basis.

[0111] The EPID can be held in a cookie in the agent's browser and can optionally be made available as a form field.

[0112] With a direct link there is typically no option from the PSP to post results to the merchant's server. It is therefore advantageous to provide this as part of the service. Given that the result format is normally set by the PSP, one way to do this is to provide this from within the servlet which is consistent with the idea of mapping the PSP to a web app.

Example 3 (with Reference to FIG. 1)

[0113] In this example, an agent is using a system which is call-aware and a payment application based in the contact centre running on the merchant's servers.

[0114] A caller makes an inbound call and the device 101 receives a unique call identifier (UCID) TAQEEPJECT6OR7P4025DMIAV7K000003 as a SIP header from the PBX 102 and forwards it along with the SIP call-Id to the server 106 which applies a transformation function as described above converting the UCID to 0921562895814544 which it stores in a lookup table against the SIP Call-Id

[0115] The agent wishes to securely take payment from the caller. A program 104 running on the agent's PC receives the same unique identifier from the PBX. A tokenisation module 105 transforms the identifier using the same transformation function as applied by the server 106 resulting in the string 0921562895814544 which passes the payment application's validation checks (for example being between 13 and 19 digits long and Luhn check passing). The agent's program sends this identifier or token to the server 106 along with a command to capture the PAN (long card number). This results in a signal being sent from the server 106 to the device 101 to enter capture mode and the PAN being sent from device 101 via server 106 to the intermediate server 107 along with the payment formatted identifier 0921562895814544.

[0116] When ready to take payment the agent enters the payment formatted identifier into agent facing interface of the payment system 108 which forms a submission payload comprising the payment formatted identifier and various other data relating to the required transaction (e.g. non-sensitive data such as amount, name, address, etc.). The payment system 108 then sends this payload to the intermediate server 107 for processing. The intermediate server 107 then preplaces the payment formatted identifier with the PAN entered by the customer before onward fording to the PSP for processing. When the PSP has completed processing the request it replies to the submission request with a result which intermediate server 107 uses in its reply to the original request from the payment system 108.

[0117] The information flows of card related data referred to above are further illustrated in FIG. 2.

[0118] It will be appreciated that the organisation of function between the various devices in this system are to some extent flexible. For instance, instead of server 106 applying the transformation function to the UCID received from device 101, it is perfectly possible for this function to be performed on device 101 itself. Other combinations are possible.

Example 4 (with Reference to FIG. 3)

[0119] In this example, an agent is using a system which is non call-aware and a payment application based in the contact centre running on the merchants servers.

[0120] A caller makes an inbound call and the device 101 receives a unique call identifier (UCID) FA08013016BB602AA25A as a SIP header from the PBX 102 and forwards it along with the SIP call-Id to the server 106.

[0121] When the call is connected to an agent CTI client 110 receives an event containing the UCID FA08013016BB602AA25A and the agent Id 12345

[0122] The agent wishes to securely take payment from the caller. A program 104 running on the agent's PC invokes the tokenisation module 105 passing in the agent Id 12345.

[0123] The tokenisation module constructs a 16 digit token by concatenating 09+an 8 digit random number+the agent Id to form the string 095636194812345. It then calculates the digit required to be appended to make the complete digit string pass a Luhn check. In this example, the result is ‘0’ so the final token is 0956361948123450 which passes the payment application's validation checks (for example being between 13 and 19 digits long and Luhn check passing). The agent's program sends this identifier or token to the server 106 along with a command to capture the PAN (long card number). This results in a signal being sent from the server 106 to the device 101 to enter capture mode and the PAN being sent from device 101 via server 106 to the intermediate server 107 along with the payment formatted identifier 0956361948123450.

[0124] From this point the flow continues exactly as in example 3, namely:

[0125] When ready to take payment the agent enters the payment formatted identifier into agent facing interface of the payment system 108 which forms a submission payload comprising the payment formatted identifier and various other data relating to the required transaction (e.g. non-sensitive data such as amount, name, address, etc.). The payment system 108 then sends this payload to the intermediate server 107 for processing. The intermediate server 107 then preplaces the payment formatted identifier with the PAN entered by the customer before onward fording to the PSP for processing. When the PSP has completed processing the request it replies to the submission request with a result which intermediate server 107 uses in its reply to the original request from the payment system 108.

[0126] Note that in the case where the random number above is replaced by a fixed digit string may not be necessary for the agent program to send the payment formatted identifier to server 106 along with the command to capture PAN as the payment formatted identifier can be calculated at server 106 from the agent Id alone. In this case, a given agent will always use a fixed payment formatted identifier to submit to the payment system, but the case can be further generalised where both the agent and server 106 have access to the same information. For instance, the callers telephone number could be used in such a scheme without the need to send anything more than the agent Id along with the command to capture as both ends of the system are capable of constructing the same payment formatted identifier from the information already in their possession.

[0127] Sensitive data may comprise payment card information such as a PAN and/or CV2 number as described herein, but may comprise other kinds of information including, but not limited to, national insurance or social security number data, bank account details, personal or private information such as customer names, addresses and/or contact details, medical information or any other kind of data for which confidentiality or secrecy is desired. As above, an agent may populate fields of a request form with non-sensitive data. Fields for the input of sensitive data may be pre-populated by the intermediate server with a token, which may be generated to meet predetermined constraints and which in some embodiments may be linked to a call stream. Alternatively, the agent may receive the token separately and use it to populate the request form. Alternatively, the agent application itself may generate the token and insert it into the request form. The completed request or at least some of the data therefrom may then be sent to the intermediate server, where the token or another identifier may be used to identify sensitive data captured from a call stream associated with the request, such as DTMF data captured from a call to which the agent is or was a party. The token or other identifier in the request may be replaced by the sensitive data. Alternatively, though similarly, the request may be replaced by a new request which is identical other than in the sensitive field, which contains the captured sensitive data (i.e. the data captured from a call stream) instead of the token or other identifier. In either case, the resultant request may be transmitted to another system or a service provider (e.g. a PSP), which may lie outside of the contact centre.

[0128] The term “comprising” encompasses “including” as well as “consisting” e.g. a composition “comprising” X may consist exclusively of X or may include something additional e.g. X+Y.

[0129] Unless otherwise indicated each embodiment as described herein may be combined with another embodiment as described herein.

[0130] The methods described herein may be performed by software in machine readable form on a tangible storage medium e.g. in the form of a computer program comprising computer program code means adapted to perform all the steps of any of the methods described herein when the program is run on a computer and where the computer program may be embodied on a computer readable medium. Examples of tangible (or non-transitory) storage media include disks, hard-drives, thumb drives, memory cards, etc. and do not include propagated signals. The software can be suitable for execution on a parallel processor or a serial processor such that the method steps may be carried out in any suitable order, or simultaneously. This acknowledges that firmware and software can be valuable, separately tradable commodities. It is intended to encompass software, which runs on or controls “dumb” or standard hardware, to carry out the desired functions. It is also intended to encompass software which “describes” or defines the configuration of hardware, such as HDL (hardware description language) software, as is used for designing silicon chips, or for configuring universal programmable chips, to carry out desired functions.

[0131] Those skilled in the art will realise that storage devices utilised to store program instructions can be distributed across a network. For example, a remote computer may store an example of the process described as software. A local or terminal computer may access the remote computer and download a part or all of the software to run the program. Alternatively, the local computer may download pieces of the software as needed, or execute some software instructions at the local terminal and some at the remote computer (or computer network). Those skilled in the art will also realise that by utilizing conventional techniques known to those skilled in the art that all, or a portion of the software instructions may be carried out by a dedicated circuit, such as a DSP (Digital Signal Processor), programmable logic array, or the like.

[0132] It will be understood that the benefits and advantages described above may relate to one embodiment or may relate to several embodiments. The embodiments are not limited to those that solve any or all of the stated problems or those that have any or all of the stated benefits and advantages.

[0133] The steps of the methods described herein may be carried out in any suitable order, or simultaneously where appropriate. Additionally, individual steps may be deleted from any of the methods without departing from the spirit and scope of the subject matter described herein. Aspects of any of the examples described above may be combined with aspects of any of the other examples described to form further examples without losing the effect sought. Any of the steps or processes described above may be implemented in hardware or software.

[0134] It will be understood that the above descriptions of preferred embodiments are given by way of example only and that various modifications may be made by those skilled in the art. Although various embodiments have been described above with a certain degree of particularity, or with reference to one or more individual embodiments, those skilled in the art could make numerous alterations to the disclosed embodiments without departing from the scope of this invention.