WO2008142377A1

WO2008142377A1 - Third party service provision

Info

Publication number: WO2008142377A1
Application number: PCT/GB2008/001684
Authority: WO
Inventors: John Kiely
Original assignee: Fexco; Rees, David, Christopher
Priority date: 2007-05-22
Filing date: 2008-05-16
Publication date: 2008-11-27
Also published as: GB0709818D0

Abstract

A method of providing or offering a service in connection with a transaction between a client computer and a first server computer using a second server computer is provided such that processes occurring at the first server computer in relation to the transaction need not be modified, or require only minimal modification. The transaction may be a payment transaction and the service may include Dynamic Currency Conversion. Server and client computers and computer systems implementing the method as well as corresponding computer programs are also provided.

Description

THIRD PARTY SERVICE PROVISION

The present invention relates to methods, server and client computers and computer systems and programmes for providing a service in connection with a transaction between a client computer and a first server computer. In particular, although not exclusively, the invention relates to the provision of Dynamic Currency Conversion (DCC) services in relation to transactions carried out between a merchant's service computer and a customer's client computer.

The advent of the Internet has led to a proliferation of merchants offering their goods or services for sale via this delivery channel in what is commonly called the eCommerce environment. The Internet allows the end customer (cardholder) to interact with an eCommerce merchant using the Internet. Goods or services offered for sale are displayed on the merchant's website and the end customer can view these using a browser running on their personal computer connected to the Internet.

The internet has evolved into a borderless state where end customers from a variety of countries and territories can access a merchant's website thus facilitating cross border trade in commodities and services such as (but not limited to) airline tickets, hotel bookings, books, etc.

Before the advent of DCC in the eCommerce environment, the end customer could only purchase goods or services in the price nominated by the merchant. So, for example, a British retailer selling their products on the internet typically priced in Pounds Sterling. This meant that a European end-customer (whose credit or debit card currency is Euro) paid for their purchases in Pounds Sterling and their credit or debit card issuer applied a transaction exchange rate to convert the completed transaction from Pounds Sterling to Euro. With the advent of DCC in the eCommerce environment, merchants can now integrate a DCC service to their server infrastructure to determine the currency of the card presented for payment. Once the card currency has been determined the merchant can either apply an exchange rate calculation on its servers or receive a calculated amount from a DCC service provider, and display a new or refreshed web page to offer the cardholder the opportunity to pay in their own currency. If the cardholder wishes to pay in their own currency, the conversion from the merchant's currency to the cardholder's currency takes place (this is effectively the DCC service). Implementing DCC takes the conversion away from the card schemes and the issuing banks and realises a new revenue stream for the merchant and/or service providers.

Implementing DCC on an eCommerce website requires a level of integration with the merchant's server and payment infrastructure which can represent quite a significant effort and cost. This effort may cause merchants to balk at the idea of implementing DCC, because of the impact to their systems and the drain on their own resources to complete such an implementation. This is also the case for other services which may be provided in connection with an eCommerce or other transaction or, more generally, any transaction between a server computer and a client computer.

In known systems, systems changes to such transactions require changes to be applied to the server computer and corresponding processes, including payment processes and the services of PSP' s (Payment Service Providers). Accordingly, it would be desirable to be able to change or add to these transactions without the investment required to change the server computer. The invention is set out in the independent claims. Further, optional features are set out in the remaining, dependent claims.

Advantageously, in one embodiment, by establishing direct connectivity between, for example, an end customer's client computer and, for example, a

DCC provider's server computer apparatus, there is no need for a merchant, for example, to modify its server computer to provide, for example, DCC. In one embodiment, this connectivity may be achieved by means of, for example, a

Java Script module running in an interface, for example, a browser, of the end customer's computer.

Advantageously, the Java Script or other computer code may pick up the relevant details from an interface such as a payment page and transmit them, via the internet, directly to the DCC or other service provider's apparatus. This method only requires the merchant's eCommerce apparatus to distribute the Java Script module along with the payment page. Once distributed, the Java Script will run automatically, or run when triggered by certain events, in the browser window of the cardholder's computer (client side) and perform the necessary functions necessary to offer the DCC or other service.

In the following detailed description, numerous specific details are set forth to provide a thorough understanding of claimed subject matter. However, it will be understood by those skilled in the art that claimed subject matter may be practiced without these specific details. In other instances, well-known methods, procedures, components and/or circuits have not been described in detail.

Some portions of the detailed description that follow are presented in terms of algorithms and/or symbolic representations of operations on data bits and/or binary digital signals stored within a computing system, such as within a computer and/or computing system memory. These algorithmic descriptions and/or representations are the techniques used by those of ordinary skill in the data processing arts to convey the substance of their work to others skilled in the art. An algorithm is here, and generally, considered to be, a self-consistent sequence of operations and/or similar processing leading to a desired result. The operations and/or processing may involve physical manipulations of physical quantities. Typically, although not necessarily, these quantities may take the form of electrical and/or magnetic signals capable of being stored, transferred, combined, compared and/or otherwise manipulated. It has proven convenient, at times, principally for reasons of common usage, to refer to these signals as bits, messages, data, values, elements, symbols, characters, terms, numbers, numerals and/or the like. It should be understood, however, that all of these and similar terms are to be associated with appropriate physical quantities and are merely convenient labels.

Unless specifically stated otherwise, as apparent from the following discussion, it is appreciated that throughout this specification, discussions utilizing terms such as "processing", "computing", "calculating", "determining" and/or the like refer to the actions and/or processes of a computing platform, such as a computer or a similar electronic computing or messaging device (such as but not limited to a mobile phone or PDA), that manipulates and/or transforms or transfers data represented as physical electronic and/or magnetic quantities and/or other physical quantities within the computing platform's processors, memories, registers, and/or other information storage, transmission, and/or input and display devices.

For the avoidance of doubt, it is understood that references to a computer, server, client or a computer platform or apparatus are not intended to be limited to a single physical entity or piece of equipment but equally include a distributed computer system, for example of networked components.

Embodiments of the invention are now described by way of example only and with reference to the accompanying drawings in which:

Figure 1, schematically depicts server and client computers in accordance with an embodiment of the invention;

Figure 2, depicts a flow diagram of a method in accordance with an embodiment of the invention; and

Figure 3, depicts a flow diagram of end - of — day processing in accordance with an embodiment of the invention.

With reference to Figure 1, a server computer 2 is in communication via a network 4, such as the Internet, with a client computer 6, to sell products or services via an interface, such as a webpage displayed in the client computer in a browser, to provide a service or sell a product. The corresponding transaction may include a request for payment by the user of the client computer, for example by serving a payment page to the client computer 6, requesting transaction detail such as payment detail to be entered by the user of the client computer 6. The client computer 6 is in direct communication via the communication network 4 (or a separate network) with a second server computer 8. The second server computer 8 provides an additional service in connection with the transaction between the first server computer 2 and the client computer 6, for example dynamic currency conversion to allow the user of the client computer 6 to pay the merchant providing the service or goods in his own currency. The second server computer may be owned by a third party or, alternatively, may be owned by the merchant. In the former case, the merchant outsources the additional service to the third party, while in the latter case, it may still be advantageous to provide the additional service using a separate, second server rather than to change the first server and associated processes to provide the service.

With reference to Figure 2, a method of providing the additional service, for example dynamic currency conversion, is now described. At step 10 after a customer has selected goods or services provided by a merchant using an interface such as a web browser on the client computer 6 (in Figure 1) and has indicated his intention to pay for them (for example "proceed to checkout"), the merchant server 2 (in Figure 1) sends a payment webpage to the client computer which is displayed in the web browser on the client computer 6 (in Figure 1) to request the user to provide payment details such as a credit or debit card number. Together with the payment web page, a Java Script module is distributed by sending it directly from the merchant server 2 (in Figure 1) or causing it to be downloaded from a separate location. The module could also be pre-installed on the client computer 6 (in Figure 1).

The Java Script module implements the method of providing or offering the additional service on the client computer 6 (in Figure 1). At step 12, as the payment web page is displayed on the client computer 6 (in Figure 1), the Java Script module runs and listens for a credit or debit card number being entered on the payment web page by the user of the client computer 6 (in Figure 1). Listening can be facilitated in a number of ways but in general entails the Java Script, or other computer code running in the browser window for the purpose of providing the additional service, pausing or waiting for a trigger event such as, but not limited to, a specific number of keystrokes or a tab from one field to another or more specifically triggered by the entering of specific data or ranges of data to a certain data field or fields on the displayed page. The user enters his credit or debit card number at step 14 and the Java Script captures the first n, for example n = 6, digits of the credit or debit card at step 16 and transmits them to the service provider's server for processing. It is understood that the Java Script will transmit sufficient information to provide the additional service, for example a sufficiently large number of digits of the credit or debit card number to be able to identify the currency and other characteristics of the credit or debit card. However, additional information, such as the entire credit or debit card number and/or the merchants pricing currency, expiry date, card issue number may equally be transmitted.

At step 18 the digits or other information received from the client computer are processed at the additional service provider's server 8 (Figure 1), in the first instance to determine whether the credit or debit card is eligible for Dynamic Currency Conversion or any other service. This may involve determining the currency in which the credit or debit card is issued based on the received digits, as described in International patent application PCT/AU2005/000983, published as WO 2006/005104 with title "Direct Currency Conversion" and having the same Assignee as the present application, herewith incorporated herein by reference. Subsequently, service provider server 8 (as per Figure 1) transmits service data such as an indication whether the credit or debit card corresponding to the entered card number is eligible for Dynamic Currency Conversion and a financial exchange rate and other ancillary data necessary to deliver the service to the Java Script on the client computer. The service data may simply include the currency determined for the credit or debit card (in which case the determination of whether the credit or debit card is in a currency different from the merchant's currency and eligible for the service can be made at the client computer) and/or the service data may include a flag set by the service provider server 8, indicating whether the credit or debit card is eligible or not. If, at step 20, the Java Script running on the client computer determines (by reference to the card's currency or flag sent from the server 8) that the card is not eligible for the service, the Java Script terminates, and once payment details have been completed on the payment web page and transmitted to the merchant server 2, card authorisation proceeds in a normal fashion at the merchant server 2 at step 22 and, following successful authorisation, settlement data including a transaction ID is stored at the merchant server 2 at step 24 for data processing. A confirmation page, including a further Java Script module and the transaction ID is transmitted to the client computer 6, step 26, following which the process at the merchant server terminates.

If, at step 20, the Java Script determines that the credit or debit card is eligible for the service, it prompts the user at step 28 as to whether the user wants to use the service, for example whether the user wants to pay in his own currency of the credit or debit card. For example, the Java Script could modify the payment web page to provide the prompt. If, at step 30, it is determined that this is the case, the Java Script will store a session cookie on the client computer 6 at step 32, including an indication that the user has accepted the service. For example, the session cookie may include the credit or debit card number, the amount to be charged and an indication of the currency in which it is to be charged to the credit or debit card or any other relevant information.

Once the payment details have been completed, either before or after the user has been prompted regarding the additional service at step 28, transaction details including payment details are transmitted to the merchant server 8 for card authorisation at step 22 in the same manner as when the credit or debit card has been determined not to be eligible. The subsequent processing in steps 24 and 26 is also the same irrespective of whether the card has been found to be eligible or not and, therefore, the provision of the additional service by the service provider 8 server, for example by a third party, does not require the processes at the merchant server 8 to be modified in any way.

As mentioned above, at step 26, the merchant server 2 sends a confirmation web page confirming successful completion of the transaction and providing a transaction ID (which may or not be visible to the user) to the client computer 6 where it is received at step 34. As mentioned above, the confirmation web page is distributed together with a further Java Script module and as soon as it is received at step 34, the Java Script module checks for the presence of the session cookie or other temporary storage method as an indication of whether the transaction is to be converted to the card's own currency. If no cookie is found, the confirmation page is displayed as it is received from the merchant server 2 and the process terminates at the client computer.

If, on the other hand, a session cookie is detected, the information stored in it is used by the Java Script module to modify the confirmation page to show the currency in which a transaction has been carried out and to comply with any other requirements of the particular credit or debit card scheme in relation to DCC. At step 40, the modified confirmation page is then displayed to the user. Further transaction information, including at least the transaction identifier or other data which can be used to identify the transaction and the currency details, are transmitted to the service provider at the server 8 and stored there at step 42, at which stage the process terminates both at the client's terminal computer and the service provider server.

In an alternative embodiment, if at step 20 or 30 it is determined that the credit or debit card is not eligible for the service or that the user declines the service, the session cookie is still stored including the information such as the transaction data and possibly the currency of the transaction at step 32. In this case, step 36 is modified to check not whether the cookie is present but whether it contains an indication that a credit or debit card is eligible for the service and the additional service has been accepted for example by checking a specific flag set in the stored data. Steps 38 and 40 proceed as described above, with the further option of providing the data from the session cookie to the service provider, even if currency conversion has not been applied. This would enable the merchant to confirm not only transactions for which currency conversion has been applied, but also those for which it has not been applied, with data provided from the merchant server 2 at a later stage, as described in more detail below.

It will be understood by a skilled person that any appropriate communication protocol can be used in the processes described above, but in one particular embodiment, communication is via a secure communication protocol such as https. Similarly, Java Script is merely one option for implementing the computer interactions which handle the process described above at the client computer and alternative script languages or computer languages in general may be used, in particular if an interface other than a web browser and web page is used on the client computer 4.

It will be understood that the order of the steps above can be modified, for example, steps 28 and 30 can be skipped and the service provided without prompting the user. Similarly, the server 8 could store currency data before step 42 in which case it would not need to be re-transmitted.

With reference to Figure 3, the merchant, (or the merchant's payment server provider or another 3 ^rd party processor) assembles settlement records stored at step 24 (Figure 2) into a settlement file 50, this may take place on server computer 2 (Figure 1) or another linked server computer. This data file will normally be transmitted to a settlement service provider at the end of each day to settle the card transactions and credit the merchant's accounts. In accordance with an embodiment of the invention, the settlement data is instead sent to the DCC or other service provider. The data is then compared with the stored transaction ID and currency details (or other unique data or flag identifying individual transactions) 54 previously stored at step 42 (Figure 2), to flag transactions as being DCC or non-DCC at step 60, the point at which the DCC or other service provider generates the bank settlement files. These files are then forwarded to a settlement service provider for processing in the usual way at step 66 to credit the merchant's accounts.

It will, of course, be understood that, although particular embodiments have just been described, the claimed subject matter is not limited in scope to a particular embodiment or implementation. For example, one embodiment may be in hardware, such as implemented to operate on a device or combination of devices, for example, whereas another embodiment may be in software. Likewise, an embodiment may be implemented in firmware, or as any combination of hardware, software, and/or firmware, for example. Likewise, although claimed subject matter is not limited in scope in this respect, one embodiment may comprise one or more articles, such as a carrier or storage medium or storage media. The storage media, such as, one or more CD-ROMs solid state memory, magneto-optical disk and/or magnetic disks or tapes, for example, may have stored thereon instructions, that when executed by a system, such as a computer system, computing platform, or other system, for example, may result in an embodiment of a method in accordance with claimed subject matter being executed, such as one of the embodiments previously described, for example. One embodiment may comprise a carrier signal on a telecommunications medium, for example a telecommunications network. Examples of suitable carrier signals include a radio frequency signal, an optical signal, and/or an electronic signal.

As one potential example, a computing platform or computer may include one or more processing units or processors, one or more input/output devices, such as a display, a keyboard and/or a mouse, and/or one or more memories, such as static random access memory, dynamic random access memory, flash memory, and/or a hard drive.

In the preceding description, various aspects of claimed subject matter have been described. For purposes of explanation, specific numbers, systems and/or configurations were set forth to provide a thorough understanding of claimed subject matter. However, it should be apparent to one skilled in the art having the benefit of this disclosure that claimed subject matter may be practiced without the specific details. In other instances, well-known features were omitted and/or simplified so as not to obscure the claimed subject matter. While certain features have been illustrated and/or described herein, many modifications, substitutions, changes and/or equivalents will now occur to those skilled in the art. It is, therefore, to be understood that the appended claims are intended to cover all such modifications and/or changes as fall within the scope of claimed subject matter.

Claims

1. A method of providing a service in connection with a transaction between a client computer and a first server computer using a second server computer which includes: receiving transaction data, entered at the client computer using an interface provided by the first server computer, at the second server computer; in response to receiving the transaction data, transmitting service data from the second server computer to the client computer to cause the interface to be modified to provide another service.

2. A method as claimed in claim 1, in which the interaction between the first server computer and the client computer is the same whether the service is provided or not.

3. A method as claimed in claim 1 or claim 2, including analysing the transaction data at the second server computer to determine if the transaction is eligible for the service and only sending the service data if it is.

4. A method as claimed in any preceding claim in which confirmation data indicative of the transaction being completed successfully, which has been sent from first server computer to the client computer, is received by the second server computer from the client computer and stored.

5. A method as claimed in any preceding claim in which the interface is modified to offer the service to a user of the client computer and which includes receiving and storing at the second server computer an indication of whether the offer has been accepted.

6. A method as claimed in any preceding claim in which a transaction record uniquely identifying the transaction is received at the second server computer and compared to a stored transaction record stored at the second server computer to provide the service.

7. A method as claimed in claim 6 in which the service is only provided if the stored transaction record indicates that a user at a client computer has accepted the service.

8. A method of providing a service in connection with a transaction between a client computer and a first server computer which includes: sending transaction data entered at the client computer using an interface provided by the first server computer to a second server computer.

9. A method as claimed in claim 8 which further includes: receiving service data based on the transaction data from the second server computer; and modifying the interface based on the service data to provide the service.

10. A method as claimed in claim 8 or 9 in which the interaction between the first server computer and a client computer is the same whether the service is provided or not.

11. A method as claimed in claim 8, claim 9 or claim 10 which includes modifying the interface to offer the service to a user of the client computer and to store a session record indicative of whether the service has been accepted on the client computer.

12. A method as claimed in any of claims 8 to 11 which includes storing a session record representative of at least some of the service data on the client computer.

13. A method as claimed in claim 12 which includes modifying a transaction receipt or order confirmation received from the first server computer based on the session record.

14. A method as claimed in any preceding claim in which the interface is modified using a program loaded onto the client with the interface received from the first server computer.

15. A method as claimed in claim 14 in which the program is received together with the interface.

16. A method as claimed in claim 14 or 15 in which the program includes a Java Script or similar scripted or coded module capable or running on a client with or without a browser.

17. A method as claimed in any preceding claim in which the interface includes a web page.

18. A server computer arranged to implement a method as claimed in any one of claims 1 to 7.

19. A client computer arranged to implement a method as claimed in any one of claims 8 to 16.

20. A computer program including coded instructions which, when run on a computer, implement a method as claimed in any one of claims 1 to 17.

21. A physical data carrier encoding a computer program as claimed in claim 20.

22. A data signal encoding a computer program as claimed in claim 20.

23. A method of offering a service in connection with a transaction between a client computer and a first server computer using a second server computer including distributing a computer program as claimed in claim

21 with a transaction interface to offer the service to the client and receiving and processing a transaction record from the client computer in the same way whether or not the service is provided.

24. A method as claimed in claim 23 that further includes sending at least some of the transaction record from the first server computer to the second server computer for processing.

25. A server computer arranged to implement a method as claimed in claim 23 or claim 24.

26. A method, client or server computer program as claimed in any preceding claim in which the transaction includes a payment transaction.

27. A method, client or server computer or computer program as claimed in any preceding claim in which the service includes currency conversion.

28. A method, client or server computer or computer program as claimed in any preceding claim in which the transaction data includes a credit card or debit card number.

29. A computer system including a first server computer as claimed in claim 25, a second server computer as claimed in claim 18 and a client computer as claimed in claim 19.

30. A method, server or client computer program as described hereinbefore with reference to the accompanying drawings.