WO2014177694A1

WO2014177694A1 - System and method for merchant authentication

Info

Publication number: WO2014177694A1
Application number: PCT/EP2014/058991
Authority: WO
Inventors: David Martin
Original assignee: Paythru Limited
Priority date: 2013-05-02
Filing date: 2014-05-02
Publication date: 2014-11-06
Also published as: GB2513632A; GB201307946D0

Abstract

A merchant authentication system and method comprises a trading server 12 cooperating with a client verification server 18 to complete payment formalities using a card owned by a user. At initial sale completion at a trading server 12, a new client 10 user has a user identification tag generated by the trading server 12. The trading server 12 communicates with a client verification server 16 that excepts and stores the user identification tag and user card details, together with a trader identification tag. The trader will have previously established account details for charging and receiving monies. Thereafter, whenever the same user successfully logs into the same trading server 12, the user verification server, when the user confirms a purchase, automatically receives the user identification tag and the trader identification tag. The user identification tag is not known or shown to the user. Neither the user account details nor the trader account details are passed between servers, avoiding the possibility of interception. The client verification server 18 can incorporate with a fiscal service 16 to effect payments. The fiscal service 16 and the client verification server 18 can be combined. If a user wishes to check card details at the end of a purchase transaction, before allowing the transaction to receive, the invention permits the client verification server 18 to pass card details to the trading server 12 for displaying. Only if the user approves the card details seen by him does the transaction run to completion and payment.

Description

SYSTEM AND METHOD FOR MERCHANT AUTHENTICATION

Field of the Invention.

The present invention relates to a system and method for merchant authentication at a website point of sale.

The Prior Art

People use cards for many purposes. For example, cards are used not only for building and facility access and organization membership, but also as a means of identifying a customer and a bank or credit service to be accessed when a payment is made. Such point of sale transactions can occur online or at a retail establishment terminal in a shop or store. There is always a risk that credit or debit card numbers can be acquired and used by others. If a transaction is made online, keystroke recording malware can record the credit or debit card numbers and send them for use by others to a remote location. Similar transmission spyware can be used when the card is presented to a retail terminal where card numbers are sent to a financial institution site for verification. The present invention seeks to improve over such systems by providing a customer verification facility that does not require card numbers to be sent to another location. On a large website such as Amazon ® (trademark) or Tesco ® (trademark) , a customer logs in, chooses their goods, and then checks out. During the checkout process, they are able to choose to use card details that they had previously used. The website stores the details for the convenience of the customer. They are allowed to do so because they conform to, and have been audited against, the Payment Card Industry Data Security Standards (PCIDSS). Smaller websites cannot afford the overhead that PCIDSS entails and so cannot store the card details. So they either force the customer to enter their card details for every transaction (which customers hate) or they pass access to a third party to store the cards for payment (such as PayPal ® (trademark)). In this case the customer has to log in twice - initially to the website and then to the third party's site. Again customers hate this. The present invention seeks to minimise the amount of logging in customers are obliged to do even when not using a PCIDSS approved website.

Summary of the invention.

According to a first aspect, the present invention consists in system operable to cooperate to complete a sale transaction by a user employing a trading server, the system comprising: a trading server accessible by a user to make a transaction using a card held by the user; a client verification server operable to store user card details;

where

the trading server is operable to provide a user identification tag for to the client verification server in a client verification message;

the client verification server is operable to analyse the client verification message and, in response thereto, to retrieve the stored user card details;

and where

the client verification server is operable to employ the users card details to complete payment in the transaction.

According to a second aspect, the present invention consists in a method employable to complete a sale transaction by a user employing a trading server, the method comprising: a step of storing user card details in or accessible to a client verification server;

a step of the trading server creating a user identification tag for the user;

a step of the trading server providing the user identification tag to the client verification server in a client verification message;

a step of the client verification server analysing the client verification message and, in response thereto, retrieving the stored user card details; and

a step of the client verification server employing the user card details to complete payment in the transaction.

According to a third aspect, the present invention consists in a client verification server operable to provide user card details in response to receipt from a trading server of a recognised user identification tag.

According to a fourth aspect, the present invention consists in trading server operable to send a user identification tag to a client verification server, for the client verification serve operable to retrieve the user card details in response to receipt of the user identification tag; and for the client verification server to be operable to employ the user card details to complete payment for a transaction.

The invention further provides that the client verification server can issue a trading identification tag in response to access to the client verification server by the trading server; that the trading server can include the trading identification tag in the client verification message; and that the client verification server can reject any request to provide user card information that is not accompanied by a recognised trading identification tag. The invention further provides that the trading server can accept indication from the user whether or not the user desires to have the user's card details, retrieved from the client verification server, displayed to the user by the trading server; where if the user desires display of the user card details, the trading server can cause the users card details to be displayed and can continue to use of the user's card details to make payment only if the user approves of their use; and if the user does not desire to display the user card details, the trading server can immediately apply the user card details to complete payment in the transaction. The invention also provides that, in the event of the user not approving use of the user card details to complete payment, the trading server can return the user to a point where the user is then able manually to insert card details for use by the trading server.

Brief description of the drawings

The invention is further described and explained, by the following description to be read in conjunction with the appended drawings, in which:

Figure 1 shows a schematic diagram of a system for trader site payment as used in the prior art.

Figure 2 is a schematic diagram of an exemplary system involved in a first stage of potential trader site payment according to the present invention.

Figure 3 is a schematic diagram of an exemplary system involved in a second stage of potential trader site payment according to the present invention.

Figure 4 is a block diagram illustrating exemplary working contents of a client verification server shown in Figures 2 and 3. Figure 5 is an exemplary flow chart illustrating details that a new or returning user provides when setting up an account with the client verification server of figures 2, 3 and 4.

Figure 6 is an exemplary diagram illustrating content of the client verification message passed from the trading server to the client verification server when the user wishes to confirm purchase and payment. Figure 7 is an exemplary flow chart illustrating one way in which the client verification server responds to an approach from a trading server.

and

Figure 8 is an exemplary flow chart illustrating how a trading server responds to a user when completing a transaction.

Detailed description

Attention is first drawn to figure 1 , a schematic diagram exemplifying one prior art environment in which the present invention can be practised.

In the prior art solution for an Internet purchaser to pay a non PCIDSS approved Internet seller, one or more client devices 10 are bidirectionally connectable to a trading server 12 within a network 14 such as the Internet. A fiscal server 16 is bidirectionally connected to the trading server 12. The client device 10 couples with the trading server 12 with a view to purchasing an item or service. One of the options offered by the trading server 12 to a client device 10 is to employ a credit, debit or charge card to make payment.

The client devices 10 can be, but are not limited to, any static or portable device, including: 3G telephones; 3G tablets; 4G telephone; 4G tablets; Wi-Fi connected laptops and notebooks; and desktop personal computers. The coupling between the client device 10 and the trading server 12 can be by any appropriate means, including but not limited to; coaxial cable; 3G wireless link; 4G wireless link; and any method including at least one of Wi-Fi and fibre optics, or any combination thereof. In order to complete a transaction, a user of a client device 10 is normally required, in the prior art, to enter the number of a credit or debit or charge card for scrutiny and payment if the card proves to be genuine. The card number cannot be retained in the trading server for lack of registration. In the prior art the card number was passed to the fiscal server 16 for payment. That is to say, having received the card number, the trading server 12 checks with the fiscal server 16 to verify the validity of the number and to ensure that payment is made in favour of the operator of the trading server 12.

Attention is next drawn to Figure 2, a schematic diagram of an exemplary system involved in a first stage of potential trader site payment according to the present invention.

Figure 2 contains elements in common with figure 1 and the like elements have like numbers and like functions. The trading server 12 and the fiscal service 16 are still present in the network 14, as well as the client device 10 outside of the network as shown, only one client device 10 being here shown to simplify the explanation. In a first stage, the client device 10 connects to the trading server 12 and completes a sale transaction with that trading server 12 for the first time. As the client 10 attempts payment, the user is asked to create an account with the trading server 12. In creating the account, the trading server 12 creates for the user a user identification tag. The user identification tag is not passed to the user, but is instead the stored in the trading server 12. The next time that particular user successfully logs in to the trading server 12, the trading server retrieves the user identification tag. In the process of creating a trading server account, the user is requested to enter card details that can be used to make payment for the purchase transaction. The trading server 12 communicates with the client verification server 18 and passes the client user card details and the identification tag to the client verification server 18. The client verification server 18 stores the tag and the card details selected by the user. The trading server 12 also sends a trader identification tag, identifying the trader to whom payment should be made, to the client verification server 18. The client verification server 18 then contact see fiscal server 16 to complete payment. The user card details and trading server account details are passed just once to the client verification server. They're after, when that user completes a transaction with that particular server both the user card details and trading server account details remain secret.

Although only one client device 10 is here shown, it is to be understood that a plurality of client devices can connect at least once to the client verification server 18 prior to accessing and making payment to a trading server 12.

It is an option of the present invention that the client verification server 18 and the fiscal server 16 are combined to form a single entity thereby limiting exchange and accessibility of user identities and card numbers.

The client verification server 18 stores the users card details and maintains the PCIDSS accreditation necessary to do so. The client verification server 18 is also operable to store the trader identification tag and details of the trader account to which payment shall be made. The process described thus sets up an association between a particular user (and their cards) and the particular trading server (and their accounts) Attention is next drawn to figure 3, a schematic diagram of the exemplary system of figure 2 involved in a second stage of potential trader site 12 payment according to the present invention. Figure 3 contains elements in common with figure 1 and figure 2 and like elements have like numbers and like functions.

Having connected to a trading server 12, and having completed selection of goods or services part of a transaction with the trading server 12, a user of a client device 10 moves on to a payment phase. Unlike the prior art solution, the user merely requires to be authenticated by the trading server 12. If the user is a new user, the trading server 12 generates a unique tag that identifies the user. The trading server 12 then receives temporarily the card details of the user and passes those details to the client verification server together with the tag in a customer verification message . The users card details are only provided on one occasion, that is, on first purchase interaction with the trading server 12. The client verification server 18 notes and stores the tag and confirms that the users card details exist.

On subsequent user visits to the trader server 12, the trader server 12 merely passes the tag to the client verification server 18 and thereby automatically calls up, from the client verification server 18, the user's card details. The user never receives a copy of user identification the tag. The tag is known only to the trading server 12 and is stored for comparison in the client verification server 18. The user identification tag 56 (see figure 6) can be included in a client verification message 54 (see figure 6) together with a trader identification tag 58 (see figure 6) that can automatically identify the owner of the trading server 12 to whom payments should be made. As an alternative, the trading server can include the trader accounts identity with first loading of the tag as a customer verification message to be stored and used by the client verification server 18. Likewise, the trading server 12 no longer needs to receive the users card details. The overall first transaction with the client verification server 18 occurs only once per user initial sign-on.

In use, if the customer verification message identifies a known customer, the customer verification server 18 passes the users card details to the fiscal server 16 . The fiscal server 16 then uses the users card details to effect payment to the owner of the trading server 12. In a trading situation a user requires only to log in to one website, provided by the trading server 12 but still has the convenience of having their card details stored for re-use and recall from the client verification server 18 by the trading server 12. This has the benefit of allowing any trading server 12 site to take advantage of single login convenience to the client device 10 user while avoiding the user the necessity of entering personal and card details for a transaction. For those sites which employ PayPal ® (trademark) , or similar services, it also removes the necessity to login again at the PayPal ® (trademark) site, which is a feature even of eBay® (trademark) sales transactions. This feature allows a trading server 12 to provide a website that enjoys all of the privileges of a PCIDSS accredited website without finding the considerable fees necessary to obtain and maintain accreditation.

The client verification message 54 (see figure 6) is, for preference, user details made available in the trading server 12 in response to a user successfully logging in to the trading server 12. The client verification message 54 (see figure 6) contains sufficient information for the client verification server 18 unambiguously to identify a single user whose card details are known. In response to receipt of a user identifying client verification message, the client verification server 18 recalls the user's card details from storage in its memory and passes the users card details to the trading server 12 (if the user wishes to employ checking of card details before confirming sale) and directly to the fiscal server 16 if the user wishes to take the use the "same card as last time" option as described hereafter . The trading server 12 thus misses out the stage of a customer manually entering card details and allows the trading server to continue in its transaction with the fiscal server 16 to secure payment. The need for a user having to recall and provide a user identification tag to the trading server 12 is also avoided. If a client device 10 is lost or store stolen, another un-authorised user cannot then use a tag stored within the client device 10, since none exists.

During the checkout process, where a user has confirmed that they wish to pay for the goods or services, it is preferred that the trading server 12 can offer to show the user summary details of the card, so that the user can confirm that they desire to use that card prior to initiating payment.

Another alternative is that the user can, on the trading server 12 website, indicate that they desire to use the same card as they used on their previous instance of purchase confirmation. The trading server 12 then informs the client verification server 18 that the user wishes to employ the same card that the user employed in the previous transaction made with that trading server 12. The client verification server then passes the users card a number to the fiscal server 16 without the trading server showing the card details to the user. In this manner, the user does not see any pages from the claim verification server 18 and is not aware that anyone other than the merchant who operates the trading server 12 was involved in the transaction. This alternative provides a single logon-single click seamless purchase facility. Attention is next drawn to figure 4, a block diagram illustrating exemplary working contents of a client verification server 18. The client verification server 18 comprises a client verification processor 20 coupled to a trader site modem 22 providing communication with the trading server 12. The client verification server 18 also comprises a client modem 24 that couples the client verification processes 20 to one or more client devices 10. The client verification server 18 also comprises a user storage memory 26 wherein user profiles are stored together with the card details of each user. This can also include trading server 12 identities and account details for payments to be made to the particular trading server 12. The user storage memory 26 also stores verification messages that can be used by the trading server 12 to elicit provision of card details from the client verification server 18 to whichever trading server 12 is making a confirmed sale to user.

Attention is next drawn to Figure 5, an exemplary flow chart illustrating details that a new or returning user provides when setting up an account with the client verification server 18 of figures 2, 3 and 4. This can occur if a user requires to provide details to the client verification server 18. Another alternative is that the client verification server 18 can obtain user card details from the fiscal server 16.

From a start 28 a first test 30 waits for a client device 10 to access the client verification server 18. Once the first test 30 detects such access, control is passed to a second test 32 where it is determined whether or not the user is a new user ready to set up a new account or whether the user is an all the user who already has set up an account and desires inspection or change to that account.

If the user is an old user, the second test 32 passes control to a first operation 34 that allows the user to logon to the client verification server 18 using previously provided details. When logon is complete, the first operation 34 recalls the verified returning user's profile from the user storage memory 26 shown in figure 4.

A second operation 36 then shows the recalled profile details to the verified returning user. The second operation 36 allows the user to amend details provided in the profile. A third operation 38, once the amended profile is complete, verifies that any new card number given in the modified profile in fact works by checking the card number and other details against an appropriate card server. If a third test 40 finds that the card, indicated by the user given card number, does not work, the third test 40 passes control back to the second operation 36 for the user to amend their details. If the third test 40 finds that the card, indicated by the user given card number, does indeed work, control is passed to a fourth operation 42 that has the client verification server 18 store the amended user profile in the user storage memory 26 shown in figure 4. The fourth operation 42 then passes control back to the first test 30 to await a new access from a client device 10.

If the second test 32 finds that the user is a new user whose profile does not exist, as evidenced by the user not having logged in, and requesting account set up, a fifth operation 44 provides interface graphical screens to the user for the user to provide their profile to the client verification server 18. The user's profile must include sufficient card information such that, if presented for a transaction, the card would be accepted. Other details can also be provided in the profile.

The fifth operation 44, on completion of the profile, passes control to a sixth operation 46 that verifies the card by submitting it to an appropriate card authorising site. If a fourth test 48 finds that the card indicated by the number and other details provided in the profile does not working and is not accepted, the fourth test 48 returns control back to the fifth operation 44 for the user to amend their profile. If the fourth test 48 finds that the card indicated by the number and other details provided in the profile does work and is accepted, the fourth test 48 passes control to a seventh operation 50 that has the client verification server 18 store the profile in the user storage memory 26 shown in figure 4. Once details have been stored, the seventh operation 50 passes control back to the first test 30 to await approach from another client device 10.

Attention is next drawn to figure 6, an exemplary diagram illustrating content of the client verification message passed from the trading server 12 to the client verification server 18 when the user comes to the point of verifying purchase.

The client verification message 54 comprises the user identification tag 56 retrieved from storage within the trading server 12 when the user successfully logs on and providing unique identification for the user on that particular trading server 12. The trading server 12 then adds a trader identification tag 58 to the client verification message 54. The entire client verification message 54 is then sent to the client verification server to 18. The trader identification tag 58 need not be unique, providing an identification to be sent to one or more services. The trader identification tag 58 serves to identify the particular trader that is calling upon use of the client verification server 18. In order to use the services offered, a trader will, for example, have signed up with the client verification server 18 service and will have paid a subscription. Any subscription can be made, for example, as a lump annual sum, as a lump sum and a cost per transaction, or a simple cost per transaction. Whichever way payment by the trader (using the trading server 12) is made, payments by the trading server 12 to defer the cost of client verification server 18 upkeep and of maintaining PCIDSS accreditation. Provision of the trade identification tag 58 also allows the client verification server 18 to keep a count of transactions for that particular trader.

Attention is next drawn to Figure 7, showing an exemplary flow chart illustrating one way in which the client verification server 18 responds to an approach from a trading server 12.

From a beginning 60 a fifth test 62 waits to see if the client verification server 18 has received access from a trading server 12. Once access from a trading server 12 is achieved, a ninth operation 64 receives the client verification message 54 from the trading server 12. A sixth test 66 examines the client verification message 54 to see if the trader identification tag 58 denotes a trader known to and accepted by the client verification server 18. If the trader identification tag 56 is not identified, the sixth test 66 rejects the approach and returns control back to the fifth test 62 to await further access by a trading server 12.

If the sixth test 66 finds that the trader identification tag 58 is known to the client verification server 18, a seventh test 68 examines the user identification tag 56 in the client verification message 54 to ascertain whether or not the user identification tag 56 indicates a user known to that client verification server 18. If the user identification tag 56 does not designate a known user, the seventh test 68 rejects the approach and returns control back to the fifth test 62 to await a further approach from a trading server 12.

If the seventh test 68 finds that the user identification tag 56 does indeed designate a user known to the client verification server 18, a tenth operation 70 retrieves the user card details from the user storage memory 26 shown in figure 4, and an eleventh operation 72 sends the retrieved user card details and the trader details to the fiscal server 16 for payment to be made. The eleventh operation 72 then passes control back to the fifth test 62 to await approach by another trading server 12.

Attention is finally drawn to figure 8, showing an exemplary flow chart illustrating how a trading server responds to a user when completing a transaction. An entrance 74 occurs when the trading server 12, interacting with a user, reaches the stage where the user is ready to confirm purchase and to make payment. The entry 74 designates that the user wishes to avail himself of the services offered by the client verification server 18 rather than provide the trading server 12 with hand entered card details.

A twelfth operation 76 requests the user identification tag 56 from the user and receives the user identification tag 56 entered by the user. A thirteenth operation 78 then recalls and adds the trader identification tag 58 from storage within the trading server 12 to create the client verification message 54 (shown in figure 6). A fourteenth operation 80 next sends the client verification to the client verification 18.

An eighth test 84 then checks whether or not the user has indicated that he or she desires to use the same card that they used in the immediate the previous transaction with that trading server 12. It is another alternative within the invention as claimed that the direction to use the same card as before is stored within the profile of the client verification server 18.

If the eighth test 84 detects that the "same as before" option has been selected, the eight test 84 then passes control to a continuation 88 that allows the trading server 12 to continue in its normal software activity to elicit payment as described with reference to figure 1 .

If the eighth test 84 does not detect that the "same as before" option has been selected, the eighth test 84 passes control to a seventeenth operation 90 that has the trading server 12 displayed the card details, retrieved from the client verification server 18, to the user for approval. If a ninth test 92 detects that the user approves use of the displayed card details, the ninth test 92 passes control to continuation 88 allowing the trading server to proceed with software interactions as described with reference to figure 1. If the ninth test 92 finds that the user does not approve use of the displayed card details on this occasion to make a payment, the ninth test 92 passes control to a return operation 94 that sends control to a point before entrance 74 where the user can now manually enter other card details for use in making payment for the transaction. The invention has been described in relation to examples. The examples shown and described are merely illustrative of ways in which the invention, as claimed hereafter, can be variously embodied without departure from the invention as claimed. Those skilled in the art will be aware of many variations, alternative arrangements and other features that can be employed without deviation from the invention as claimed.

The invention is further clarified and explained by the appended following claims.

Claims

1 . A system operable to cooperate to complete a sale transaction by a user employing a trading server, the system comprising:

a trading server accessible by a user to make a transaction using a card held by the user; and

a client verification server operable to store user card details;

where

the trading server is operable to provide a user identification tag to the client verification server in a client verification message;

and where

2. The system of claim 1 wherein:

the client verification server is operable to issue a trader identification tag in response to access to the client verification server by the trading server;

the trading server is operable to include the trader identification tag in the client verification message; and

the client verification server is operable to reject any request to provide user card information that is not accompanied by a recognised trader identification tag.

3. The system of claim 1 or claim 2 where the trading server is operable to accept indication from the user whether or not the user desires to have the user's card details, retrieved from the client verification server, displayed to the user by the trading server;

where

if the user desires display of the user card details, the trading server is operable to cause the users card details to be received from the client verification server and displayed, the trading server being further operable to allow use of the user's card details to make payment only if the user approves of their use;

and

if the user does not desire to display the user card details, the client verification server immediately applies the user card details to complete payment in the transaction.

4. The system of claim 3 where in, in the event of the user not approving use of the user card details to complete payment, the trading server is operable to return the user to a point where the user is then able manually to insert card details for use by the trading server.

5. A client verification server operable to provide user card details in response to receipt from a trading server of a recognised user identification tag.

6. A trading server operable to receive a user identification tag, user; operable to send the user identification tag to a client verification server; and operable to permit the client verification server to employ the user card details to complete payment for a transaction.

7. A method employable to complete a sale transaction by a user employing a trading server, the method comprising:

a step of storing user card details in or accessible to a client verification server;

a step of the trading server creating a user identification tag for the user;

a step of the client verification server analysing the client verification message and, in response thereto, retrieving the stored user card details;

8. The method of claim 7 further comprising:

a step of the client verification server issuing a trader identification tag in response to access to the client verification server by the trading server;

a step of the trading server include the trader identification tag in the client verification message; and

a step of the client verification server rejecting any request to provide user card information that is not accompanied by a recognised trader identification tag.

9. The method of claim 7 or claim 8 including:

a step of the trading server accepting indication from the user whether or not the user desires to have the user's card details, retrieved from the client verification server, displayed to the user by the trading server;

if the user desires display of the user card details, a step of the trading server causing the user card details to be displayed with a further step of continuing to use of the user's card details to make payment only if the user approves of their use; and

if the user does not desire to display the user card details, a step of the client verification server immediately applying the user card details to complete payment in the transaction.

10. The method of claim 9 including, in the event of the user not approving use of the user card details to complete payment, a step of the trading server returning the user to a point where the user is then able manually to insert card details for use by the trading server.

1 1 . A system substantially as described with reference to the appended drawings.

12. A method substantially as described with reference to the appended drawings.

13. A client verification server substantially as described with reference to the appended drawings.

14 A trading server substantially as described with reference to the appended drawings.