FR2867585A1 - Client terminal e.g. mobile telephone, and payment receiving server transacting method, involves transmitting authentication parameters to virtual card server which then calculates number of card and transmits it to recharging server - Google Patents

Abstract

The method involves transmitting authentication parameters by a recharging server to a dynamic virtual card server (20). A client terminal (10) selects an amount proposed by the recharging server that then requests a dynamic virtual card at the server (20). The server (20) calculates a number of the card and transmits it to the recharging server which then requests credit of prepaid account for the amount. The credit is then confirmed. An independent claim is also included for a transaction device.

Description

The technical field of the invention is that of the services of

  telecommunications and more particularly deals with transaction services.

  More specifically, the present invention relates to dynamic virtual cards (CVD), transaction systems in which a customer has the ability to download from his PC via a secure applet a dynamic virtual card, allowing the purchase of goods for sale remotely by entering the parameters of this card. The use of the virtual card for payment is completely transparent for the merchant who only sees the parameters of a conventional card (no specific kit is to be implemented by the merchant). CVD recovery via SMS, SVI, WAP and USSD is also possible.

  Designated as well by the generic terms Dynamic Virtual Card (CVD), Virtual Card, e-Card or the commercial term e-Carte Bleue, the card is called virtual, which means here non-physical. This designation not only denotes a 16-digit virtual credit card number whose characteristics verify the same cryptographic properties as a physical bank card number, but also the parameters associated with this number: surname, first name, date of end of validity and CW number (Value Verification Card). This group of parameters can be generated remotely by solicitation and prior authentication of the user by all channels related to remote sales (voice server, SMS, WAP, Internet and possibly Minitel or postal mail). This Virtual Card Number is valid only once for a fixed amount at the time of downloading this card.

  Such a dynamic virtual card is delivered by a dynamic virtual card server or SCVD, that is to say a server authorized to issue virtual card numbers. These servers are either linked to banking organizations technically and contractually, or directly hosted by these banking organizations.

  A virtual card number is obtained by the customer via his client terminal, which may be a mobile terminal, a PDA, a fixed telephone, etc.

  Thus the patent document ORBISCOM WO 99 49424 mentions the possibility for a user to download from his PC via a secure applet a dynamic virtual card, allowing the purchase of goods for sale remotely by entering the parameters of this card. The use of the virtual card for payment is completely transparent for the merchant who only sees the parameters of a conventional card (no specific kit is to be implemented by the merchant).

  The usual use of mobile CVD is not practical due to several browsing sessions to manage.

  The invention aims to provide an ergonomic improvement, and in particular to simplify the use of a CVD from a merchant for users on the move (purchase via PDAltelphone mobilelephone fixe). In addition, some merchants are not equipped with physical bank card readers, nor can they be paid by CVD. The invention enables these traders (mobile professionals) to accept CVDs.

  Finally, a consequence of the invention is that a CVD can be easily used to recharge a prepaid account at a given merchant (replacing a prepaid card in the case of a telephone operator).

  The use of such a CVD number guarantees the merchant (or operator) that the customer is duly registered and identified with the body authorized to issue CVDs. The risk of fraud is almost zero.

  These objects are achieved according to the invention by means of a transaction method between a client and a virtual payment card payment reception server, comprising a step of supplying a virtual payment card to the payment reception server, comprising in addition, the preliminary step of taking into account pre-established data sets from the client to a virtual card issuing server for the purpose of issuing a virtual card, characterized in that comprises the step of using a direct link between the virtual card server and the payment receiving server to provide this server with the virtual card issued by the virtual card server.

  Also provided according to the invention a transaction device comprising a payment reception server, a server issuing virtual payment cards, the virtual card server being able to provide a virtual payment card upon receipt of pre-established customer details and the payment receipt server being able to confirm a payment in exchange for the receipt of a virtual card, the device being characterized in that it further comprises means forming a direct link between the payment reception server and the virtual card server, the virtual card server incorporating means for issuing the virtual card on this direct link to the payment reception server.

  Other objects, features and advantages of the invention will appear on reading the detailed description which follows, with reference to the appended figures in which: - Figure 1 is a schematic view illustrating a first approach according to the invention; FIG. 2 illustrates a first variant of a functional assembly in accordance with the invention; FIG. 3 illustrates a second variant of a functional assembly 25 according to the invention; FIG. 4 is a schematic view illustrating a second approach according to the invention; FIG. 5 illustrates a third variant of a functional assembly in accordance with the invention; FIG. 6 illustrates a fourth variant of a functional assembly in accordance with the invention.

  The first embodiment of the invention relates to reloading a prepaid account, via any remote sales channel (IVR Interactive Voice Server, WAP, WEB, USSD, SMS, etc.), by means of a virtual card. for single use.

  The invention implicitly allows the merchant to be insured by a trusted third party (SCVD) that the customer is registered with this third party and therefore the risk of fraud around the card number used for payment are almost zero. The payment guarantee is possible.

  This embodiment also relates to reloading all types of prepaid accounts, especially prepaid telephone accounts.

  In Figures 1 and 2, there is shown a customer terminal under the reference 10. The client terminal is used as a conventional terminal (mobile, PDA, landline phone ...). The WAP, SMS, USSD functions are preferably present.

  An SCVD (dynamic virtual card server), referenced 20, is here provided apt, after an authentication client to generate at the request of the customer a CVD number that is sent to the merchant.

  A merchant server 30 plays the role of receiving the payment, as will be described later, this server serves as an intermediary between the mobile terminals of the customers, the SCVD and the banks, and manages the prepaid accounts of the customers.

  Reference 30 here refers to the merchant server which includes a reload server 35.

  A banking system 40 provides compensation between the various actors (customers, merchants) to debit / credit the accounts.

  In addition, an API 50 provides dialogs between the reloading server 30 and the SCVD 20, dialogs standardized by this API 50. The API defines the dialogues between the merchant server (s), such as the server 30 (including the server reloading 35) and the SCVD (s) such as SCVD 20.

  Previously, the customer has subscribed to the virtual card service via his bank 40 enabling him any purchase on sale remotely and can thus access this service via his client terminal 10.

  The server of the merchant 30 will offer as a means of payment the payment by virtual credit card.

  By selecting this means of payment, the customer 10 will be invited by the merchant 30 to enter an identifier code and his password. This code will be transmitted in background to the server 20 which, after authentication of the client 10, will calculate a virtual card number for this client and transmit it to the merchant server 30.

  The merchant server 30 then credits the customer's prepaid account with the amount associated with the virtual credit card and processes the virtual card number like any bank card number sold remotely.

  For this, the steps described now in detail will be implemented by the assembly shown in Figure 2.

  With reference to FIG. 2, a client, from his terminal 10 (mobile, PDA, fixed telephone, etc.), wishes to use the CVD system (server 20) to credit a prepaid account system managed by the site. merchant (merchant server 30).

  For this, the client 10 calls the merchant server 30 which is accredited with the SCVD server 20.

  He thus accesses the merchant reload server 35 (step 1) and selects the option to reload his prepaid account by CVD.

  Then he enters his authentication settings with the reload server 35 (step 2).

  Then the reloading server 35 transmits the authentication parameters to the SCVD 20 (step 3) and the SCVD (step 4) authenticates the client 10.

  The reload server 35 (step 5) then proposes different amounts for reloading.

  The client 10 then selects an amount (step 6).

  The reload server 35 then makes a CVD request to the SCVD 20 for the selected amount (step 7).

  Then the SCVD 20 calculates a CVD number and transmits it to the reload server 35 (step 8).

  The reloading server 35 then requests the credit of the user's prepaid account 10 for the amount chosen (step 9).

  The credit is then confirmed (step 10). The reload server 35 then stores the CVD number for future compensation (step 11). Then the reload server 35 confirms to the user 10 the reloading of the account, the amount of reloading and the CVD number used, by mini messages (step 12).

  At the end of the day, the merchant charging server 35 sends its transaction files to the banking system 40 which triggers the clearing procedures (step 13).

  The dialogs identified in references 3, 4, 7, 8 are preferably standardized to always have the same interface between the different reloading servers 35 and the SCVDs 20.

  This embodiment therefore modifies the payment system so that it can retrieve a virtual credit card number to recharge a prepaid account, all in a single session.

  Currently existing prepaid cards are often materialized by a physical medium. In addition, merchants, to distribute these cards, are obliged to resort to a network of paid salesmen. In this embodiment, the support no longer exists and the issuer of the prepaid card has no more royalties to pay, which is an additional advantage.

  According to another variant, as illustrated in FIG. 3, the client 10 accesses the charging server 35 of the merchant system 30 and selects the option enabling him to recharge his prepaid account with a CVD (step 1).

  Then the client 10 is redirected by the reload server 35 to the SCVD 20 for authentication without an intermediary (step 2).

  The SCVD 20 then authenticates the client 10 and then redirects the client 10 to the reloading server 35, specifying that the client is authenticated for the session (step 3). Then, steps similar to those described above are implemented. The reload server 35 offers different amounts for reloading (step 4). The user 10 then selects an amount (step 5).

  Then the reload server 35 makes a CVD request to the SCVD for the chosen amount (step 6).

  Then the SCVD 20 calculates a CVD number and transmits it to the reload server 35 (step 7). The reloading server 35 then requests the credit of the user's prepaid account 10 for the amount chosen (step 8). The credit is then confirmed (step 9).

  The reload server then stores the CVD number for future compensation (step 10).

  The reloading server 35 then confirms to the user 10 the reloading of the account, the amount of reloading and the CVD number used, by mini-messages (step 11).

  And at the end of the day, the merchant reload server 35 sends its transaction files to the banking system 40, which triggers the clearing procedures (step 12).

  The dialogs identified under references 2, 3, 6, 7 are preferably standardized to always have the same interface between the different reloading servers 35 and the SCVDs 20.

  In the two cases described above, the merchant server 30 is interfaced to the SCVD 20 by a specific interface 50 (API).

  In addition, the customer is registered in the virtual card service via his bank and can access this service via his mobile terminal 10 or 25 any remote access terminal (PC, PDA etc ...).

  After authentication of the client 10, the SCVD 20 calculates a CVD number that it transmits to the merchant 30 through this API.

  Operators or merchants seeking a secure solution for remote reloading, in particular via mobile terminal, are advantageously assisted by such a system. Indeed, the users being first registered with their bank to be able to use the virtual card service and secondly authenticated with t 4 2867585 SCVD, the risk of fraud related to the card number used are virtually zero.

  Another embodiment will now be described (FIGS. 4 and 5), still in accordance with the invention.

  This embodiment is aimed at systems requiring payment by certified credit card such as remote purchase via channels related to e-commerce, but also more specifically the proximity payment at merchants without a bank payment terminal ( home doctors, taxis, ...).

  Merchants who do not have payment terminals, especially itinerant professionals (taxis, doctors at home, delivery personnel, etc.), are therefore particularly concerned by this embodiment.

  The system is now organized as follows: the merchant has a mobile terminal (mobile, PDA, landline, ...) allowing him to dialogue with a merchant manager using conventional channels (WAP, SMS, USSD or Vocal ).

  The merchant manager server 36 is a merchant-accredited server for mediating between the merchant's mobile terminals, the SCVD and the banks. He manages the dialogue between him and the SCVD to retrieve the CVD number, and he also manages the dialogue between him and the merchant's terminal to have the merchant's acceptance.

  The merchant terminal 37 is used as a conventional terminal (mobile, PDA, landline).

  An API 50 provides and normalizes dialogues between the merchant (s) server (s) or merchant managers and the SCVD.

  In this embodiment, there is a client terminal 10, an SCVD 20, a merchant 30, a banking system 40, an API 50. Again, an interfacing of the merchant server with the SCVD is proposed.

  Here again, the customer is registered in the virtual card service via his bank 40 and can access this service via his client terminal 10.

  During the act of proximity payment, the client 10 connects this time to the SCVD 20 with its client terminal 10, authenticates, enters the amount of the transaction. The merchant manager may also retrieve the parameters for authentication and obtaining the CVD for the amount of property to be purchased and transmit them to SCVD 20.

  The SCVD 20 then calculates a CVD number, transmits it to the merchant manager server 36 to which the merchant 30 is registered, and the merchant manager server 36 records the characteristics of the transaction for later compensation. The SCVD 20 then acknowledges by mini-message the client 10 on the issue of the CVD number and the associated amount. The merchant manager 36 pays him, by minimessage merchant 30 on the credit card transaction.

  More precisely, the following steps are implemented (FIG. 5).

  First, client 10 connects to SCVD 20 to request a CVD number (step 1).

  Then the SCVD 20 asks the client 10 to authenticate (step 2).

  Then, the client 10 enters an alphanumeric access code (step 3). The SCVD 20 then requests the customer to enter the transaction amount, the merchant code and then calculate a CVD number for the amount entered (step 4).

  The SCVD 20 then transmits the CVD number to the merchant manager 36, whose address it finds using the merchant code (step 5). Then the merchant manager 36 sends a request for confirmation of the transaction to the merchant 30 (terminal 37) through a merchant MSISDNI database (step 6).

  The merchant 30 then validates the transaction (step 7). Then the merchant manager 36 confirms the transaction to the SCVD and stores the CVD number for the transaction (step 8).

  The SCVD 20 then sends the client 10 a mini message confirming the generation of the CVD number and the transaction (step 9).

  At the end of the day, the merchant manager 36 sends his transaction files to the banking system 40, which triggers the clearing procedure (step 11).

  Dialogues identified by references 5 and 8 are preferably standardized to always have the same interface between the different merchant management sites and the SCVDs.

  Note that in a variant corresponding to a remote sale, the example just described is also valid, insofar as the intermediary is replaced by a merchant server, which also plays the role of interface of choice of products. The use of a merchant manager also relieves the task of managing the payment of such a merchant server.

  In a variant, the following steps are implemented (FIG. 6): First, the client 10 chooses to pay a good per virtual card (step 1). Then the client 10 transmits its authentication parameters, the merchant code, the amount of the transaction with the merchant manager 36 (step 2).

  Then, after a control of the MSISDN / merchant code base, it is the merchant manager 36 which transmits to the SCVD 20 the authentication parameters (step 3).

  The SCVD 20 then authenticates the client 10 (step 4).

  The merchant manager 36 then makes a CVD request to the RVSS for the amount of the property (step 5). Then the SCVD 20 calculates a CVD number and communicates it to the merchant manager 36 (step 6).

  At this point, the merchant manager 36 sends a transaction confirmation request to the merchant 30 on his terminal (37) (step 7). The merchant 30 validates the transaction (step 8).

  The merchant manager 36 then stores the CVD number, the merchant code, for future clearing (step 9).

  Then the merchant manager 36 confirms to the customer 10 the delivery of the good, the amount and the CVD number used by mini-message 30 (step 10).

  At the end of the day, the merchant manager 36 sends his transaction files to the banking system 40, which triggers the clearing procedure (step 11).

  Finally, bank 40 credits the merchant account and debits the customer account (step 12).

  The dialogs referenced in references 3, 4, 5, 6 are preferably standardized to always have the same interface between the 5 different merchant management sites and the SCVDs.

  This example above provides the benefit of high payment reliability. In addition, it allows the merchant to delegate to a merchant manager to dialogue with the SCVD, an API then advantageously defining the dialogues between the merchant sites or the merchant management servers and the SCVDs.

  Contrary to some of the cases described above where customers and merchants are in direct contact, a merchant manager advantageously deals here links with the server SCVD and banks.

  This example is based on the fact that clients and merchants delegate to a proxy the links with the SCVD server and the banks.

  The examples described thus make it possible to overcome the fact that the current terminals can not manage two different sessions with satisfactory ergonomics (here the recovery of the CVD number and the payment).

Claims (1)

12 CLAIMS,   A method of transaction between a client terminal (10) and a payment reception server (30, 35, 36) by a virtual payment card, comprising a step of supplying a virtual payment card to the payment reception server (30, 35, 36), further comprising the preliminary step of taking into account pre-established coordinates from the client to a virtual card issuing server (20) for transmission a virtual card, characterized in that it comprises the step of using a direct link between the virtual card server (20) and the payment receiving server (30, 35, 36) to provide this server the virtual card issued by the virtual card server (20).   2. Method according to claim 1, characterized in that it comprises the step by which the payment reception server (30, 35, 36) requires from the client (10) the coordinates necessary to obtain a virtual card, then the step in which the payment reception server (30, 35, 36) itself transmits these coordinates to the virtual card server (20).   The method of claim 1, characterized in that it comprises the step of the payment receiving server setting up a direct link (50) between the client (10) and the virtual card server (20), the method further comprising the step of the client (10) then providing the virtual card server (20) with the coordinates necessary to issue a virtual card.   4. Method according to claim 1, characterized in that it comprises a step of connecting the virtual card server (20) with the payment receiving server (30, 35, 36) at the initiative of the customer ( 10), by means of an identification of the payment receiving server (30, 35, 36) delivered by the client (10) to the virtual card server (20).   5. Method according to any one of the preceding claims, characterized in that the payment reception server (30, 35, 36) is a product presentation entity.   6. Method according to any one of the preceding claims, characterized in that the payment reception server (30, 35, 36) is a server (35, 36) receiving payments on behalf of a presentation entity of products (30) which is distinct from this payment receiving server (35, 36).   7. Method according to claim 4, characterized in that it further comprises the step by which the virtual card server (20) informs the client (10) that a virtual card has been sent to the server of payment receipt (30, 35, 36) identified by the customer (10).   8. Method according to claim 4, characterized in that it uses a product presentation entity which is distinct from the payment reception server, and in that it further comprises the step by which the server of payment receipt (30, 35, 36) informs, by transmission of a message to a communication terminal (37) belonging to the product presentation entity, that it has actually received a payment by virtual card .   9. Method of crediting prepaid phone account by virtual payment card, characterized in that it includes the transaction method according to any one of the preceding claims.   10. Transaction device comprising a payment reception server (30, 35, 36), a server issuing virtual payment cards, the virtual card server (20) being able to provide a virtual payment card upon receipt of pre-established customer details and the payment receiving server (30, 35, 36) being able to confirm a payment in exchange for the receipt of a virtual card, the device being characterized in that it further comprises means forming a direct link (50) between the payment reception server (30, 35, 36) and the virtual card server (20), the virtual card server (20) incorporating means for transmitting the virtual card on this direct link to the payment receiving server (30, 35, 36).   11. Device according to claim 10, characterized in that the payment reception server (30, 35, 36) comprises means for dialogue with a client terminal (10) and means for initiating, during a session of dialogue with the client, a direct relationship between this client (10) and the virtual card server (20), for direct delivery from the client terminal to the virtual card server (20) pre-established coordinates necessary for the issuing a virtual card.   12. Device according to claim 10, characterized in that the payment reception server (30, 35, 36) includes dialogue means with a client terminal, able to require the client terminal (10) the provision of pre-established coordinates necessary to issue a virtual card, and able to transmit these coordinates to the virtual card server (20).   Device according to claim 10, characterized in that the virtual card server comprises means for receiving, from the client (10), payment reception server identification details (30, 35, 36). , and set up a direct link between the virtual card server and the payment reception server thus identified.   14. Device according to any one of claims 10 to 13, characterized in that the payment reception server (30, 35, 36) is a product presentation entity (30).   15. Device according to any one of claims 10 to 13, characterized in that it comprises a product presentation entity (30) and in that the payment reception server (35, 36) is distinct from this entity but receiving payments on behalf of that entity.   16. Device according to any one of claims 10 to 15, characterized in that the virtual card server (20) comprises means for transmitting a message to a client terminal (10), indicating that a virtual card was sent to the payment receiving server.   Device according to claim 13, characterized in that it comprises a product presentation entity (30), a payment reception server (35, 36) which is distinct from this product presentation entity (30) but receiving payments for that entity, the payment receiving server (35, 36) including means for transmitting a message to a communication terminal (37) belonging to the product presentation entity, message indicating that a virtual card has been received by the payment receiving server (30, 35, 36) 18. Device according to any one of claims 10 to 17, characterized in that the payment receiving server (30, 35, 36 ) is a prepaid phone account reload server.