WO2005101336A1 - Transaction device with improved efficiency - Google Patents

Transaction device with improved efficiency Download PDF

Info

Publication number
WO2005101336A1
WO2005101336A1 PCT/FR2005/000602 FR2005000602W WO2005101336A1 WO 2005101336 A1 WO2005101336 A1 WO 2005101336A1 FR 2005000602 W FR2005000602 W FR 2005000602W WO 2005101336 A1 WO2005101336 A1 WO 2005101336A1
Authority
WO
WIPO (PCT)
Prior art keywords
server
payment
virtual card
virtual
client
Prior art date
Application number
PCT/FR2005/000602
Other languages
French (fr)
Inventor
Laurent Feurer
Original Assignee
France Telecom
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by France Telecom filed Critical France Telecom
Publication of WO2005101336A1 publication Critical patent/WO2005101336A1/en

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/385—Payment protocols; Details thereof using an alias or single-use codes
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/02—Payment architectures, schemes or protocols involving a neutral party, e.g. certification authority, notary or trusted third party [TTP]
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/22—Payment schemes or models
    • G06Q20/28—Pre-payment schemes, e.g. "pay before"
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/34—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using cards, e.g. integrated circuit [IC] cards or magnetic cards
    • G06Q20/342—Cards defining paid or billed services or quantities
    • G—PHYSICS
    • G07—CHECKING-DEVICES
    • G07F—COIN-FREED OR LIKE APPARATUS
    • G07F7/00—Mechanisms actuated by objects other than coins to free or to actuate vending, hiring, coin or paper currency dispensing or refunding apparatus
    • G07F7/02—Mechanisms actuated by objects other than coins to free or to actuate vending, hiring, coin or paper currency dispensing or refunding apparatus by keys or other credit registering devices
    • G07F7/025—Mechanisms actuated by objects other than coins to free or to actuate vending, hiring, coin or paper currency dispensing or refunding apparatus by keys or other credit registering devices by means, e.g. cards, providing billing information at the time of purchase, e.g. identification of seller or purchaser, quantity of goods delivered or to be delivered

Definitions

  • the technical field of the invention is that of telecommunications services and more particularly relates to transaction services. More specifically, the present invention relates to dynamic virtual cards (CVD), transaction systems according to which a customer can download from his PC via a secure appiet a dynamic virtual card, allowing the purchase of goods for sale remotely by entry of parameters for this card.
  • CVD dynamic virtual cards
  • the use of the virtual card for payment is completely transparent for the merchant who only sees the parameters of a “classic” card (no specific kit is to be implemented by the merchant).
  • CVD recovery via SMS, SVI, WAP and USSD is also possible.
  • CVD Dynamic Virtual Card
  • e-Card e-Card
  • e-Blue Card the card is qualified as virtual, which means here not physical .
  • This designation designates not only a 16-digit virtual bank card number whose characteristics verify the same properties, notably cryptographic, as a physical bank card number, but also the parameters associated with this number: surname, first name, expiry date and CW number (Value Verification Card).
  • This group of parameters can be generated remotely by solicitation and prior authentication of the user by all the channels linked to distance selling (Voice server, SMS, WAP, Internet and possibly Minitel or even postal mail).
  • This "Virtual Card Number” is only valid once for an amount fixed at the time of downloading this card.
  • Such a dynamic virtual card is issued by a dynamic virtual card server or SCVD, that is to say a server authorized to issue virtual card numbers.
  • SCVD dynamic virtual card server
  • 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 client via his client terminal, which can be a mobile terminal, a PDA, a landline telephone, etc.
  • the patent document ORBISCOM WO 9949424 states the possibility for a user to download a dynamic virtual card from their PC via a secure app, allowing the purchase of goods for sale at a distance 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 “classic” card (no specific kit is to be implemented by the merchant).
  • CVD cardiovascular disease
  • the usual use of CVD in mobility 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 with a merchant for users on the move (purchase via PDA / mobile telephone / landline telephone).
  • some merchants are not equipped with physical bank card readers, and cannot be paid by CVD either.
  • the invention allows these traders (mobile professionals) to accept CVDs.
  • 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.
  • a transaction method between a client and a server for receiving payment by virtual payment card comprising a step of supplying a virtual payment card to the server for receiving payment, comprising in addition the preliminary step of taking into account pre-established coordinates from the client to a virtual card issuing server with a view to issuing a virtual card, characterized in that it comprises the step of using a direct link between the card server and the payment receiving server to provide this server with the virtual card issued by the virtual card server.
  • a transaction device is also proposed according to the invention comprising a payment reception server, a server issuing virtual payment cards, the virtual card server being able to supply a virtual payment card upon reception of pre-established customer details.
  • 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 transmitting the virtual card on this direct link to the payment reception server.
  • FIG. 1 is a schematic view illustrating a first approach according to the invention
  • - Figure 2 illustrates a first variant of functional assembly according to the invention
  • - Figure 3 illustrates a second variant of functional assembly according to the invention
  • - Figure 4 is a schematic view illustrating a second approach according to the invention
  • - Figure 5 illustrates a third variant of functional assembly according to the invention
  • - Figure 6 illustrates a fourth variant of a functional assembly according to the invention.
  • the first embodiment of the invention relates to the recharging of a prepaid account, via any distance selling channel (SVl Interactive Voice Server, WAP, WEB, USSD, SMS, etc.), using a single-use virtual card.
  • the invention implicitly allows the merchant to be assured by a trusted third party (SCVD) that the customer is registered with this third party and therefore that the risk of fraud around the card number used for payment is almost zero. Payment guarantee is possible.
  • This embodiment also relates to the recharging of all types of prepaid accounts, in particular prepaid telephone accounts.
  • a client terminal has been represented under the reference 10.
  • the client terminal is used like a conventional terminal (mobile, PDA, landline telephone, etc.).
  • the WAP, SMS, USSD functions are preferably present.
  • An SCVD dynamic virtual card server
  • a server 30 of the merchant plays the role of receiving 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.
  • the reference 30 here relates to the merchant server which includes a reload server 35.
  • a banking system 40 provides compensation between the different actors (customers, merchants) for debiting / crediting the accounts.
  • an API 50 provides the dialogs between the reload server 30 and the SCVD 20, dialogs standardized by this API 50.
  • the API defines the dialogs between the merchant server (s), such as the server 30 (including the server 35) and the SCVD (s) such as the SCVD 20.
  • the customer Beforehand, the customer has registered for the “virtual card” service via his bank 40 allowing him to make any purchase for distance selling and can thus access this service via his client terminal 10.
  • the merchant's server 30 will offer payment by virtual bank 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 the 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 prepaid account of the client with the associated amount to the virtual bank card and treats the virtual card number like any distance selling bank card number.
  • the steps now described in detail will be implemented by the assembly shown in Figure 2.
  • a customer from his terminal 10 (mobile, PDA, landline, etc. .), wishes to use the CVD system (server 20) to credit a prepaid account system managed by the merchant site (merchant server 30).
  • the client 10 calls the merchant server 30 which is accredited to the SCVD server 20. He thus accesses the server 35 (step 1) for recharging the merchant and selects the option allowing him to recharge his prepaid account by CVD. Then it enters its authentication parameters with the reload server 35 (step 2).
  • the recharging server 35 transmits the authentication parameters to the SCVD 20 (step 3) and the SCVD (step 4) authenticates the client 10.
  • the recharging server 35 (step 5) then proposes different amounts for recharging.
  • the client 10 selects an amount (step 6).
  • the recharging server 35 requests a CVD from the SCVD 20 for the chosen amount (step 7).
  • the SCVD 20 calculates a CVD number and transmits it to the reload server 35 (step 8).
  • the recharging server 35 requests the credit from the prepaid account of the user 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).
  • the recharging server 35 confirms to the user 10 when recharging the account, the amount of recharging and the CVD number used, by mini messages (step 12).
  • the merchant recharging server 35 sends its files transactions to the banking system 40 which triggers the clearing procedures (step 13).
  • the dialogs identified in references 3, 4, 7, 8 are preferably standardized so as to always have the same interface between the different recharging servers 35 and the SCVD 20.
  • This embodiment therefore modifies the payment system so as to be able to retrieve a virtual bank card number to recharge a prepaid account, all in a single session.
  • the currently existing prepaid cards are often materialized by a physical medium.
  • merchants are obliged to use a network of paid sellers to distribute these cards.
  • the client 10 accesses the recharging server 35 of the merchant system 30 and selects the option allowing 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 intermediary (step 2). The SCVD 20 then authenticates the client 10 and then redirects the client 10 to the reload server 35, specifying that the client is authenticated for the session (step 3). Then steps similar to those described previously are implemented.
  • the reload server 35 offers different amounts for reloading (step 4).
  • the user 10 selects an amount (step 5). Then the recharging 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 recharging server 35 then requests credit from the user's prepaid account 10 for the amount chosen in step 8). The credit is then confirmed (step 9). The reload server then stores the CVD number for future compensation (step 10). The reload server 35 then confirms to the user 10 the reload and account, the amount of the reload and the CVD number used, by mini-messages (step 11).
  • 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 the references 2, 3, 6, 7 are preferably standardized so as to always have the same interface between the various reloading servers 35 and the SCVDs.
  • the merchant server 30 is interfaced with the SCVD 20 through a specific interface 50 (APi).
  • the client is registered for the “virtual card” service via his bank and can access this service via his mobile terminal 10 or any remote access device (PC, PDA, etc.).
  • the SCVD 20 calculates a CVD number which it transmits to the merchant 30 using this API.
  • the system is now organized as follows: the merchant has a mobile terminal (mobile, PDA, landline telephone, ...) allowing him to interact with a merchant manager using conventional channels (WAP, SMS, USSD or Vocal ).
  • the merchant management server 36 is a server accredited by the merchants to act as an intermediary between the merchant's mobile terminals, the SCVD and the banks. H 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 like a conventional terminal (mobile, PDA, landline telephone).
  • An API 50 ensures and standardizes the dialogs between the merchant server (s) (site) or merchant managers and the SCVD.
  • a client terminal 10 an SCVD 20, a merchant 30, a banking system 40, an API 50.
  • the merchant server is interfaced with the SCVD.
  • the client is registered for the “virtual card” service via his bank 40 and can access this service via his client terminal 10.
  • the client 10 connects this time to the SCVD 20 with his client terminal 10, authenticates, enters the amount of your transaction.
  • the merchant manager can also retrieve the parameters for authentication and obtaining the CVD for the amount of the good to be purchased and transmit them to the SCVD 20.
  • the SCVD 20 then calculates a CVD number, transmits it to the merchant manager server 36 to which is registered the merchant 30 and the merchant manager server 36 records the characteristics of the transaction for further compensation.
  • the SCVD 20 then acknowledges by mini-message the client 10 on the issue of the CVD number and on the associated amount.
  • the merchant manager 36 acknowledges, by minimessage the merchant 30 on the bank card transaction. More precisely, the following steps are implemented (figure
  • the client 10 connects to the 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 1).
  • the SCVD 20 then asks the client to enter the amount of the transaction, the merchant code and then calculates 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).
  • the merchant manager 36 sends a request for confirmation of the transaction to the merchant 30 (terminal 37) using an SISDN / merchant code base (step 6).
  • the merchant 30 validates the transaction (step 7).
  • 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 of the transaction (step 9).
  • the merchant manager 36 sends its transaction files to the banking system 40, which triggers the clearing procedure (step 1).
  • the dialogs identified by the references 5 and 8 are preferably standardized to always have the same interface between the different merchant management sites and the SCVDs.
  • the client 10 chooses to pay for a good by virtual card (step 1). Then the client 10 transmits its authentication parameters, the merchant code, the amount of the transaction to the merchant manager 36 (step 2). Then, after a check of the MS ISDN / Merchant Code base, it is the merchant manager 36 which transmits the authentication parameters to the SCVD 20 (step 3).
  • the SCVD 20 then authenticates the client 10 (step 4).
  • the merchant manager 36 then requests a CVD from the SCVD for the amount of the asset (step 5).
  • the SCVD 20 calculates a CVD number and communicates it to the merchant manager 36 (step 5).
  • the merchant manager 36 sends a request for confirmation of the transaction to the merchant 30 on his terminal (37) (step 7).
  • the merchant 30 validates the transaction (step 8).
  • the merchant manager 36 stores the CVD number, the merchant code, for future compensation ⁇ step 9), Then the merchant manager 36 confirms to the client 10 the delivery of the good, the amount and the CVD number used by mini -message (step 10).
  • the merchant manager 36 sends its transaction files to the banking system 40, which triggers the clearing procedure (step 11).
  • bank 40 credits the market account and debits the customer account (step 12).
  • the dialogs identified in references 3, 4, 5, 6 are preferably standardized so as to always have the same interface between the various merchant management sites and the SCVDs.
  • This example above provides the advantage of high payment reliability.
  • it allows the merchant to delegate to a merchant manager dialog with the SCVD, an API then advantageously defining the dialogs between the merchant sites or the merchant manager servers and the SCVD.
  • a merchant manager advantageously deals here with the connections with the SCVD server and the banks.
  • This example is based on the fact that clients and merchants delegate the links with the SCVD server and the banks to a proxy. The examples described therefore make it possible to compensate for the fact that the current terminals cannot manage two different sessions with satisfactory ergonomics (here the recovery of the CVD number and the payment).

Abstract

The invention relates to a method of performing a transaction between a client terminal (10) and a terminal for receiving a payment (30, 35, 36) by virtual payment card. The inventive method comprises the following steps, namely: a step consisting in supplying a virtual payment card to the payment-receiving terminal (30, 35, 36), as well as a preliminary step consisting in taking account of co-ordinates which are pre-established by the client and which are intended for a virtual card-issuing terminal (20) for the purpose of issuing a virtual card. The invention is characterised in that it also comprises a step consisting in using a direct connection between the virtual card server (20) and the payment-receiving terminal (30, 35, 36) in order to supply said server with the virtual card issued by the virtual card server (20).

Description

DISPOSITIF DE TRANSACTION A EFFICACITE AMELIOREE TRANSACTION DEVICE WITH IMPROVED EFFICIENCY
Le domaine technique de l'invention est celui des services de télécommunications et concerne plus particulièrement les services de transactions. Plus précisément, la présente invention concerne les cartes virtuelles dynamiques (CVD), systèmes de transaction selon lequel un client a la possibilité de télécharger de son PC via une appiet sécurisée une carte virtuelle dynamique, permettant l'achat de biens en vente à distance par saisie des paramètres de cette carte. L'utilisation de la carte virtuelle pour le paiement est complètement transparente pour le marchand qui ne voit passer que les paramètres d'une carte « classique » (aucun kit spécifique n'est à implémenter par le marchand). La récupération de CVD via SMS, SVI, WAP et USSD est également possible. Désignée aussi bien par les termes génériques « Carte Virtuelle Dynamique (CVD) », « Carte Virtuelle », « e-Card » ou le terme commercial « e-Carte Bleue », la carte est qualifiée de virtuelle, ce qui signifie ici non physique. Cette appellation désigne non seulement un numéro de carte bancaire virtuelle à 16 chiffres dont les caractéristiques vérifient les mêmes propriétés notamment cryptographiques qu'un numéro de carte bancaire physique, mais également les paramètres associés à ce numéro : nom, prénom, date de fin de validité et numéro de CW (Carte Vérification Value). Ce groupe de paramètres peut être généré à distance par sollicitation et authentification préalable de l'utilisateur par tous les canaux liés à la vente à distance (Serveur vocal, SMS, WAP, Internet et éventuellement Minitel voire courrier postal). Ce « Numéro de carte virtuelle » n'est valable qu'une seule fois pour un montant fixé au moment du téléchargement de cette carte. Une telle carte virtuelle dynamique est délivrée par un serveur de carte virtuelle dynamique ou SCVD, c'est à dire un serveur habilité à délivrer des numéros de carte virtuelle. Ces serveurs sont soit liés à des organismes bancaires techniquement et contractuellement, soit directement hébergés par ces organismes bancaires. Un numéro de carte virtuelle est obtenu par le client via son terminal client, celui-ci pouvant être un terminal mobile, un PDA, un téléphone fixe, etc.. Ainsi le document de brevet ORBISCOM WO 9949424 fait état de la possibilité pour un utilisateur de télécharger depuis son PC via une appiet sécurisée une carte virtuelle dynamique, permettant l'achat de biens en vente à distance par saisie des paramètres de cette carte. L'utilisation de la carte virtuelle pour le paiement est complètement transparente pour le marchand qui ne voit passer que les paramètres d'une carte « classique » (aucun kit spécifique n'est à implémenter par le marchand). L'utilisation habituelle de CVD en mobilité n'est pas pratique en raison de plusieurs sessions de browsing à gérer. L'invention vise à apporter une amélioration ergonomique, et notamment à simplifier l'utilisation d'une CVD auprès d'un marchand pour des utilisateurs en mobilité (achat via PDA/téléphone mobile/téléphone fixe). En outre, certains marchands ne sont pas équipés de lecteurs de cartes bancaires physiques, et ne peuvent non plus faire l'objet d'un paiement par CVD. L'invention permet à ces commerçants (professionnels en mobilité) d'accepter les CVD. Enfin, une conséquence de l'invention est qu'une CVD puisse être aisément utilisée pour recharger un compte prépayé chez un marchand donné (en remplacement d'une carte prépayée dans le cas d'un opérateur de téléphonie). L'utilisation d'un tel numéro de CVD garantit au marchand (ou opérateur) que le client est dûment enregistré et identifié auprès de l'organisme habilité à délivrer des CVD. Le risque de fraude est quasi-nul. Ces buts sont atteints selon l'invention grâce à un procédé de transaction entre un client et un serveur de réception de paiement par carte de paiement virtuelle, comprenant une étape de fourniture d'une carte de paiement virtuelle au serveur de réception de paiement, comprenant en outre l'étape préliminaire de prise en compte de coordonnées pré-étabiies de la part du client à destination d'un serveur d'émission de cartes virtuelles en vue de l'émission d'une carte virtuelle, caractérisé en ce qu'il comprend l'étape consistant à utiliser une liaison directe entre le serveur de cartes virtuelles et le serveur de réception de paiement pour fournir à ce serveur la carte virtuelle émise par le serveur de cartes virtuelles. On propose également selon l'invention un dispositif de transaction comprenant un serveur de réception de paiement, un serveur émetteur de cartes de paiement virtuelles, le serveur de cartes virtuelles étant apte à fournir une carte de paiement virtuelle à la réception de coordonnées de client préétablies et le serveur de réception de paiement étant apte à entériner un paiement en échange de la réception d'une carte virtuelle, le dispositif étant caractérisé en ce qu'il comprend en outre des moyens formant une liaison directe entre le serveur de réception de paiement et le serveur de cartes virtuelles, le serveur de cartes virtuelles incorporant des moyens d'émission de la carte virtuelle sur ce lien direct à destination du serveur de réception de paiement. D'autres buts, caractéristiques et avantages de l'invention apparaîtront à la lecture de la description détaillée qui va suivre, faite en référence aux figures annexées sur lesquelles : - la figure 1 est une vue schématisée illustrant une première approche selon l'invention ; - la figure 2 illustre une première variante d'ensemble fonctionnel conforme à l'invention ; - la figure 3 illustre une seconde variante d'ensemble fonctionnel conforme à l'invention ; - la figure 4 est une vue schématisée illustrant une seconde approche selon l'invention ; - la figure 5 illustre une troisième variante d'ensemble fonctionnel conforme à l'invention ; - la figure 6 illustre une quatrième variante d'ensemble fonctionnel conforme à l'invention. Le premier mode de réalisation de l'invention concerne le rechargement d'un compte prépayé, via tout canal de vente à distance (SVl Serveur Vocal Interactif, WAP, WEB, USSD, SMS, etc.), au moyen d'une carte virtuelle à usage unique. L'invention permet implicitement au marchand d'être assuré par un tiers de confiance (SCVD) que le client est enregistré auprès de ce tiers et donc que les risques de fraude autour du numéro de carte utilisé pour le paiement sont quasi nuls. La garantie de paiement est envisageable. Ce mode de réalisation concerne également le rechargement de tous types de comptes prépayés, en particulier les comptes prépayés téléphoniques. Sur les figures 1 et 2, on a représenté un terminal du client sous la référence 10. Le terminal du client est utilisé comme un terminal classique (mobile, PDA, téléphone fixe...). Les fonctions WAP, SMS, USSD sont préférentiellement présentes. Un SCVD (serveur de cartes virtuelles dynamiques), référencé 20, est ici prévu apte, après une authentification du client à générer à la demande du client un numéro de CVD qui est transmis au marchand. Un serveur 30 du marchand joue le rôle de réception du paiement, comme on le décrira par la suite, ce serveur sert d'intermédiaire entre les terminaux mobiles des clients, le SCVD et les banques, et gère les comptes prépayés des clients. La référence 30 vise ici le serveur marchand qui comprend un serveur de rechargement 35. Un système bancaire 40 assure la compensation entre les différents acteurs (clients, marchands) pour débiter/créditer les comptes. En outre, une API 50 assure les dialogues entre le serveur 30 de rechargement et le SCVD 20, dialogues normalisés par cette API 50. L'API définit les dialogues entre le ou les serveurs de marchands, tels que le serveur 30 (comprenant le serveur de rechargement 35) et le ou les SCVD tels que le SCVD 20. Préalablement, le client s'est inscrit au service « carte virtuelle » via sa banque 40 lui permettant tout achat en vente à distance et peut ainsi accéder à ce service via son terminal client 10. Le serveur du marchand 30 va proposer comme moyen de paiement le paiement par carte bancaire virtuelle. En sélectionnant ce moyen de paiement le client 10 va être invité par le marchand 30 à saisir un code identifiant et son mot de passe. Ce code va être transmis en background au serveur 20 qui, après authentification du client 10, va calculer un numéro de carte virtuelle pour ce client et le transmettre au serveur marchand 30. Le serveur marchand 30 crédite alors le compte prépayé du client du montant associé à la carte bancaire virtuelle et traite le numéro de carte virtuelle comme n'importe quel numéro de carte bancaire en vente à distance. Pour cela, les étapes décrites maintenant en détail vont être mises en œuvre par l'ensemble représenté à fa figure 2. En référence à la figure 2, un client, à partir de son terminal 10 (mobile, PDA, téléphone fixe, ...), désire utiliser le système de CVD (serveur 20) pour créditer un système de compte prépayé géré par le site marchand (serveur marchand 30). Pour cela, le client 10 appelle le serveur marchand 30 qui est accrédité auprès du serveur SCVD 20. li accède ainsi au serveur 35 (étape 1) de rechargement du marchand et sélectionne l'option lui permettant de recharger son compte prépayé par CVD. Puis il saisit ses paramètres d'aυthentification auprès du serveur de rechargement 35 (étape 2). Puis le serveur de rechargement 35 transmet les paramètres d'authentification au SCVD 20 (étape 3) et le SCVD (étape 4) authentifie le client 10. Le serveur de rechargement 35 (étape 5) propose alors différents montants pour le rechargement. Le client 10 sélectionne alors un montant (étape 6). Le serveur de rechargement 35 fait alors une demande de CVD au SCVD 20 pour le montant choisi (étape 7). Ensuite le SCVD 20 calcule un numéro de CVD et le transmet au serveur de rechargement 35 (étape 8). Le serveur de rechargement 35 demande alors le crédit du compte prépayé de l'utilisateur 10 pour le montant choisi (étape 9). Le crédit est ensuite confirmé (étape 10). Le serveur de rechargement 35 stocke alors le numéro de CVD pour une future compensation (étape 11). Puis le serveur de rechargement 35 confirme à ('utilisateur 10 te rechargement du compte, le montant du rechargement et îe numéro de CVD utilisé, par mini messages (étape 12). En fin de journée, le serveur de rechargement marchand 35 envoie ses fichiers de transactions vers le système bancaire 40 ce qui déclenche les procédures de compensation (étape 13). Les dialogues repérés dans les références 3, 4, 7, 8 sont préférentiellement normalisés pour avoir toujours la même interface entre les différents serveurs de rechargement 35 et les SCVD 20. Ce mode de réalisation modifie donc le système de paiement de façon à pouvoir récupérer un numéro de carte bancaire virtuelle pour recharger un compte prépayé, le tout dans une unique session. Les cartes prépayées actuellement existantes sont souvent matérialisées par un support physique. De plus les marchands, pour distribuer ces cartes, sont obligés de recourir à un réseau de vendeurs rémunérés. Dans ce mode de réalisation, le support n'existe plus et rémetteur de la carte prépayée n'a plus de royalties à verser, ce qui est un avantage supplémentaire. Selon une autre variante, telle qu'illustrée à la figure 3, le client 10 aiccède au serveur de rechargement 35 du système marchand 30 et sélectionne l'option lui permettant de recharger son compte prépayé avec une CVD (étape 1). Puis le client 10 est redirigé, par le serveur de rechargement 35, vers le SCVD 20 pour authentification sans intermédiaire (étape 2). Le SCVD 20 authentifie alors le client 10 puis redirige le client 10 vers le serveur de rechargement 35 en précisant que le client est authentifié pour la session (étape 3). Ensuite, des étapes similaires à celles décrites précédemment sont mises en œuvre. Le serveur de rechargement 35 propose différents montants pour le rechargement (étape 4). L 'utilisateur 10 sélectionne alors un montant (étape 5). Puis le serveur de rechargement 35 fait une demande de CVD au SCVD pour le montant choisi (étape 6). Alors le SCVD 20 calcule un numéro de CVD et le transmet au serveur de rechargement 35 (étape 7). Le serveur de rechargement 35 demande alors le crédit du compte prépayé de l'utilisateur 10 pour le montant choisi étape 8). Le crédit est ensuite confirmé (étape 9). Le serveur de rechargement stocke ensuite le numéro de CVD pour une future compensation (étape 10). Le serveur de rechargement 35 confirme ensuite à l'utilisateur 10 le rechargement ctυ compte, le montant du rechargement et le numéro de CVD utilisé, par mini-messages (étape 11 ). Et en fin de journée, le serveur de rechargement marchand 35 envoie ses fich iers de transaction vers le système bancaire 40, ce qui déclenche les procédures de compensation (étape 12). Les dialogues repérés sous les références 2, 3, 6, 7 sont préférentiellement normalisés pour avoir toujours la même interface entre les différents serveurs de rechargement 35 et les SCVD 20. Dans les deux cas exposés ci-avant, le serveur marchand 30 est interface au SCVD 20 par une interface spécifique 50 (APi ). En outre, le client est inscrit au service « carte virtuelle » via sa banque et peut accéder à ce service via son terminal mobile 10 ou n'importe quel te rminal d'accès distant (PC, PDA etc...). Après autfientification du client 10, le SCVD 20 calcule un numéro de CVD qu'il transmet au marchand 30 grâce à cette API. Les opérateurs ou marchands recherchant une solution sécurisée de rechargement à distance, en particulier via terminal mobile, se trouvent avantageusement aidés par un tel système. En effet, les utilisateurs étant d'une part préalablement enregistrés auprès de leur banque pour pouvoir utiliser le service « carte virtuelle » et d'autre part authentifiés auprès du SCVD, les risques de fraude liés au numéro de carte utilisé sont quasiment nuls. On décrira maintenant un autre mode de réalisation (figures 4 et 5), toujours conforme à l'invention. Ce mode de réalisation vise les systèmes nécessitant un paiement par carte bancaire certifié tels que l'achat à distance via les canaux liés au e-commerce, mais aussi plus spécifiquement le paiement de proximité chez les marchands ne disposant pas de terminal de paiement bancaire (médecins à domicile, taxis, ...). Les marchands ne disposant pas de terminaux de paiement, en particulier les professionnels itinérants (taxis, médecins à domicile, livreurs, etc), sont donc particulièrement concernés par ce mode de réalisation. Le système est maintenant organisé de la façon suivante : le marchand possède un terminal mobile (mobile, PDA, téléphone fixe, ...) lui permettant de dialoguer avec un gestionnaire de marchands en utilisant les canaux classiques (WAP, SMS, USSD ou Vocal). Le serveur gestion naire de marchands 36 est un serveur accrédité par les marchands pour servir d'intermédiaire entre les terminaux mobiles des marchands, le SCVD et les banques. H gère le dialogue entre lui et le SCVD pour récupérer le numéro de CVD, et il gère également le dialogue entre lui et le terminal du marchand pour avoir l'acceptation du marchand. Le terminal du marchand 37 est utilisé comme un terminal classique (mobile, PDA, téléphone fixe). Une API 50 assure et normalise les dialogues entre le ou les serveurs (sites) marchands ou les gestionnaires de marchands et le SCVD. Dans ce mode de réalisation, on retrouve un terminal client 10, un SCVD 20, un marchand 30, un système bancaire 40, une API 50. Là encore, un interfaçage du serveur marchand avec le SCVD est proposé. Là encore, le client est inscrit au service « carte virtuelle » via sa banque 40 et peut accéder à ce service via son terminal client 10. Lors de l'acte de paiement de proximité, le client 10 se connecte cette fois au SCVD 20 avec son terminal client 10, s'authentifie, saisit le montant de ta transaction. Le gestionnaire de marchands peut également récupérer les paramètres pour l'a thentification et l'obtention de la CVD pour le montant du bien à acheter et les transmettre au SCVD 20. Le SCVD 20 calcule alors un numéro de CVD, le transmet au serveur gestionnaire de marchands 36 auquel est inscrit le marchand 30 et le serveur 36 gestionnaire de marchands enregistre les caractéristiques de la transaction pour une compensation ultérieure. Le SCVD 20 acquitte alors par mini-message le client 10 sur la délivrance du numéro de CVD et sur le montant associé. Le gestionnaire de marchands 36 acquitte, lui, par minimessage le marchand 30 sur la transaction carte bancaire. Plus précisément, les étapes suivantes sont mises en œuvre (figureThe technical field of the invention is that of telecommunications services and more particularly relates to transaction services. More specifically, the present invention relates to dynamic virtual cards (CVD), transaction systems according to which a customer can download from his PC via a secure appiet a dynamic virtual card, allowing the purchase of goods for sale remotely by entry of parameters for this card. The use of the virtual card for payment is completely transparent for the merchant who only sees the parameters of a “classic” card (no specific kit is to be implemented by the merchant). CVD recovery via SMS, SVI, WAP and USSD is also possible. Referred to by the generic terms "Dynamic Virtual Card (CVD)", "Virtual Card", "e-Card" or the commercial term "e-Blue Card", the card is qualified as virtual, which means here not physical . This designation designates not only a 16-digit virtual bank card number whose characteristics verify the same properties, notably cryptographic, as a physical bank card number, but also the parameters associated with this number: surname, first name, expiry date and CW number (Value Verification Card). This group of parameters can be generated remotely by solicitation and prior authentication of the user by all the channels linked to distance selling (Voice server, SMS, WAP, Internet and possibly Minitel or even postal mail). This "Virtual Card Number" is only valid once for an amount fixed at the time of downloading this card. Such a dynamic virtual card is issued 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 client via his client terminal, which can be a mobile terminal, a PDA, a landline telephone, etc. Thus the patent document ORBISCOM WO 9949424 states the possibility for a user to download a dynamic virtual card from their PC via a secure app, allowing the purchase of goods for sale at a distance 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 “classic” card (no specific kit is to be implemented by the merchant). The usual use of CVD in mobility 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 with a merchant for users on the move (purchase via PDA / mobile telephone / landline telephone). In addition, some merchants are not equipped with physical bank card readers, and cannot be paid by CVD either. The invention allows 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 thanks to a transaction method between a client and a server for receiving payment by virtual payment card, comprising a step of supplying a virtual payment card to the server for receiving payment, comprising in addition the preliminary step of taking into account pre-established coordinates from the client to a virtual card issuing server with a view to issuing a virtual card, characterized in that it comprises the step of using a direct link between the card server and the payment receiving server to provide this server with the virtual card issued by the virtual card server. A transaction device is also proposed according to the invention comprising a payment reception server, a server issuing virtual payment cards, the virtual card server being able to supply a virtual payment card upon reception of pre-established customer details. and the payment reception server being able to confirm a payment in exchange for the reception 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 transmitting the virtual card on this direct link to the payment reception server. Other objects, characteristics and advantages of the invention will appear on reading the detailed description which follows, made with reference to the appended figures in which: - Figure 1 is a schematic view illustrating a first approach according to the invention; - Figure 2 illustrates a first variant of functional assembly according to the invention; - Figure 3 illustrates a second variant of functional assembly according to the invention; - Figure 4 is a schematic view illustrating a second approach according to the invention; - Figure 5 illustrates a third variant of functional assembly according to the invention; - Figure 6 illustrates a fourth variant of a functional assembly according to the invention. The first embodiment of the invention relates to the recharging of a prepaid account, via any distance selling channel (SVl Interactive Voice Server, WAP, WEB, USSD, SMS, etc.), using a single-use virtual card. The invention implicitly allows the merchant to be assured by a trusted third party (SCVD) that the customer is registered with this third party and therefore that the risk of fraud around the card number used for payment is almost zero. Payment guarantee is possible. This embodiment also relates to the recharging of all types of prepaid accounts, in particular prepaid telephone accounts. In FIGS. 1 and 2, a client terminal has been represented under the reference 10. The client terminal is used like a conventional terminal (mobile, PDA, landline telephone, etc.). The WAP, SMS, USSD functions are preferably present. An SCVD (dynamic virtual card server), referenced 20, is here provided capable, after authentication of the client, at the request of the client, generating a CVD number which is transmitted to the merchant. A server 30 of the merchant plays the role of receiving 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. The reference 30 here relates to the merchant server which includes a reload server 35. A banking system 40 provides compensation between the different actors (customers, merchants) for debiting / crediting the accounts. In addition, an API 50 provides the dialogs between the reload server 30 and the SCVD 20, dialogs standardized by this API 50. The API defines the dialogs between the merchant server (s), such as the server 30 (including the server 35) and the SCVD (s) such as the SCVD 20. Beforehand, the customer has registered for the “virtual card” service via his bank 40 allowing him to make any purchase for distance selling and can thus access this service via his client terminal 10. The merchant's server 30 will offer payment by virtual bank 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 the 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 prepaid account of the client with the associated amount to the virtual bank card and treats the virtual card number like any distance selling bank card number. For this, the steps now described in detail will be implemented by the assembly shown in Figure 2. Referring to Figure 2, a customer, from his terminal 10 (mobile, PDA, landline, etc. .), wishes to use the CVD system (server 20) to credit a prepaid account system managed by the merchant site (merchant server 30). For this, the client 10 calls the merchant server 30 which is accredited to the SCVD server 20. He thus accesses the server 35 (step 1) for recharging the merchant and selects the option allowing him to recharge his prepaid account by CVD. Then it enters its authentication parameters with the reload server 35 (step 2). Then the recharging server 35 transmits the authentication parameters to the SCVD 20 (step 3) and the SCVD (step 4) authenticates the client 10. The recharging server 35 (step 5) then proposes different amounts for recharging. The client 10 then selects an amount (step 6). The recharging server 35 then requests a CVD from the SCVD 20 for the chosen amount (step 7). Then the SCVD 20 calculates a CVD number and transmits it to the reload server 35 (step 8). The recharging server 35 then requests the credit from the prepaid account of the user 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 recharging server 35 confirms to the user 10 when recharging the account, the amount of recharging and the CVD number used, by mini messages (step 12). At the end of the day, the merchant recharging server 35 sends its files transactions to the banking system 40 which triggers the clearing procedures (step 13). The dialogs identified in references 3, 4, 7, 8 are preferably standardized so as to always have the same interface between the different recharging servers 35 and the SCVD 20. This embodiment therefore modifies the payment system so as to be able to retrieve a virtual bank card number to recharge a prepaid account, all in a single session.The currently existing prepaid cards are often materialized by a physical medium. In addition, merchants are obliged to use a network of paid sellers to distribute these cards. of realization, the support no longer exists and the issuer of the prepaid card no longer has any royalties to pay, which is an additional advantage. According to another variant, as illustrated in FIG. 3, the client 10 accesses the recharging server 35 of the merchant system 30 and selects the option allowing 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 intermediary (step 2). The SCVD 20 then authenticates the client 10 and then redirects the client 10 to the reload server 35, specifying that the client is authenticated for the session (step 3). Then steps similar to those described previously are implemented. The reload server 35 offers different amounts for reloading (step 4). The user 10 then selects an amount (step 5). Then the recharging 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 recharging server 35 then requests credit from the user's prepaid account 10 for the amount chosen in step 8). The credit is then confirmed (step 9). The reload server then stores the CVD number for future compensation (step 10). The reload server 35 then confirms to the user 10 the reload and account, the amount of the reload 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 the references 2, 3, 6, 7 are preferably standardized so as to always have the same interface between the various reloading servers 35 and the SCVDs. In the two cases explained above, the merchant server 30 is interfaced with the SCVD 20 through a specific interface 50 (APi). In addition, the client is registered for the “virtual card” service via his bank and can access this service via his mobile terminal 10 or any remote access device (PC, PDA, etc.). After client authentication 10, the SCVD 20 calculates a CVD number which it transmits to the merchant 30 using this API. Operators or merchants looking for a secure remote recharging solution, in particular via mobile terminal, are advantageously helped by such a system. Indeed, the users being on the one hand previously registered with their bank to be able to use the “virtual card” service and on the other hand authenticated with the SCVD, the risks of fraud linked to the card number used are almost nil. We will now describe another embodiment (Figures 4 and 5), still in accordance with the invention. This embodiment is aimed at systems requiring payment by certified bank card such as remote purchase via channels linked to e-commerce, but also more specifically proximity payment at merchants without a bank payment terminal ( home doctors, taxis, ...). Merchants who do not have payment terminals, in particular itinerant professionals (taxis, home doctors, delivery people, etc.), are therefore particularly concerned by this embodiment. The system is now organized as follows: the merchant has a mobile terminal (mobile, PDA, landline telephone, ...) allowing him to interact with a merchant manager using conventional channels (WAP, SMS, USSD or Vocal ). The merchant management server 36 is a server accredited by the merchants to act as an intermediary between the merchant's mobile terminals, the SCVD and the banks. H 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 like a conventional terminal (mobile, PDA, landline telephone). An API 50 ensures and standardizes the dialogs between the merchant server (s) (site) 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. Here again, the merchant server is interfaced with the SCVD. Here again, the client is registered for the “virtual card” service via his bank 40 and can access this service via his client terminal 10. During the proximity payment act, the client 10 connects this time to the SCVD 20 with his client terminal 10, authenticates, enters the amount of your transaction. The merchant manager can also retrieve the parameters for authentication and obtaining the CVD for the amount of the good to be purchased and transmit them to the SCVD 20. The SCVD 20 then calculates a CVD number, transmits it to the merchant manager server 36 to which is registered the merchant 30 and the merchant manager server 36 records the characteristics of the transaction for further compensation. The SCVD 20 then acknowledges by mini-message the client 10 on the issue of the CVD number and on the associated amount. The merchant manager 36 acknowledges, by minimessage the merchant 30 on the bank card transaction. More precisely, the following steps are implemented (figure
5). D'abord le client 10 se connecte au SCVD 20 pour demander un numéro de CVD (étape 1). Puis le SCVD 20 demande au client 10 de s'authentifier (étape 2). Ensuite, le client 10 saisit un code d'accès alphanumérique (étape5). First the client 10 connects to the 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). Le SCVD 20 demande alors au client de saisir le montant de la transaction, le code du marchand puis calcule un numéro de CVD pour le montant saisi (étape 4). Le SCVD 20 transmet ensuite le numéro de CVD au gestionnaire de marchands 36 dont il retrouve l'adresse grâce au code marchand (étape 5).3). The SCVD 20 then asks the client to enter the amount of the transaction, the merchant code and then calculates 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).
Puis le gestionnaire de marchands 36 envoie une demande de confirmation de la transaction au marchand 30 (terminal 37) grâce à une base SISDN/code marchand (étape 6). Le marchand 30 valide alors la transaction (étape 7). Puis le gestionnaire de marchands 36 confirme la transaction au SCVD et stocke le numéro de CVD pour la transaction (étape 8). Le SCVD 20 envoie ensuite au client 10 un mini-message de confirmation de la génération du numéro de CVD et de la transaction (étape 9). En fin de journée, le gestionnaire de marchands 36 envoie ses fichiers de transactions vers le système bancaire 40, ce qui déclenche la procédure de compensation (étape 1 ). Les dialogues repérés par les références 5 et 8 sont préférentiellement normalisés pour avoir toujours la même interface entre les différents sites gestionnaires de marchands et les SCVD. On notera que dans une variante correspondant à une vente à distance, l'exemple qui vient d'être décrit est également valable, dans la mesure où l'intermédiaire est remplacé par un serveur marchand, qui joue également le rôle d'interface de choix de produits. L'utilisation d'un gestionnaire de marchands décharge là aussi la tâche de gestion du paiement d'un tel serveur marchand. En variante, on met en œuvre les étapes suivantes (figure 6) : D'abord, le client 10 choisit de payer un bien par carte virtuelle (étape 1). Puis le client 10 transmet ses paramètres d'authentification, le code du marchand, le montant de la transaction auprès du gestionnaire de marchands 36 (étape 2). Puis, après un contrôle de la base MS ISDN/Code marchand, c'est le gestionnaire de marchands 36 qui transmet au SCVD 20 les paramètres d'authentification (étape 3). Le SCVD 20 authentifie ensuite le client 10 (étape 4). Le gestionnaire de marchands 36 fait alors une demande de CVD au SCVD pour le montant du bien (étape 5). Puis le SCVD 20 calcule un numéro de CVD et le communique au gestionnaire de marchands 36 (étapeThen the merchant manager 36 sends a request for confirmation of the transaction to the merchant 30 (terminal 37) using an SISDN / merchant code base (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 of the transaction (step 9). At the end of the day, the merchant manager 36 sends its transaction files to the banking system 40, which triggers the clearing procedure (step 1). The dialogs identified by the references 5 and 8 are preferably standardized to always have the same interface between the different merchant management sites and the SCVDs. It will be noted that in a variant corresponding to a distance sale, the example which has just been 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 again relieves the task of managing the payment of such a merchant server. As a variant, the following steps are implemented (FIG. 6): First, the client 10 chooses to pay for a good by virtual card (step 1). Then the client 10 transmits its authentication parameters, the merchant code, the amount of the transaction to the merchant manager 36 (step 2). Then, after a check of the MS ISDN / Merchant Code base, it is the merchant manager 36 which transmits the authentication parameters to the SCVD 20 (step 3). The SCVD 20 then authenticates the client 10 (step 4). The merchant manager 36 then requests a CVD from the SCVD for the amount of the asset (step 5). Then the SCVD 20 calculates a CVD number and communicates it to the merchant manager 36 (step
6). A ce stade, le gestionnaire de marchands 36 envoie une demande de confirmation de la transaction au marchand 30 sur son terminal (37) (étape 7). Le marchand 30 valide la transaction (étape 8). Le gestionnaire de marchands 36 stocke alors le numéro de CVD, le code marchand, pour une future compensation <étape 9), Puis le gestionnaire de marchands 36 confirme au client 10 la livraison du bien, le montant et le numéro de CVD utilisé par mini-message (étape 10). En fin de journée, le gestionnaire de marchands 36 envoie ses fichiers de transactions vers le système bancaire 40, ce qui déclenche la procédure de compensation (étape 11). Enfin, la banque 40 crédite le compte march and et débite le compte client (étape 12). Les dialogues repérés aux références 3, 4, 5, 6 sont préférentiellement normalisés pour avoir toujours fa même interface entre les différents sites gestionnaires de marchands et les SCVD. Cet exemple ci-dessus fournit l'avantage d'u ne fiabilité de paiement élevée. En outre il permet au marchand de déléguer à un gestionnaire de marchands de dialogue avec le SCVD, une API définissant alors avantageusement les dialogues entre les sites marchands ou les serveurs gestionnaires de marchands et les SCVD. Contrairement à certains des cas décrits ci-avant où les clients et les marchands sont en relation directe, un gestionnaire de marchand s'occupe avantageusement ici des liaisons avec le serveur SCVD et les banques. Cet exemple s'appuie sur le fait que les clients et les marchands délèguent à un mandataire les liaisons avec le serveur SCVD et les banques. Les exemples décrits permettent donc de pallier au fait que les terminaux actuels ne peuvent pas gérer deux sessions différentes avec une ergonomie satisfaisante (ici la récupération du numéro de CVD et le paiement). 6). At this stage, the merchant manager 36 sends a request for confirmation of the transaction 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 compensation <step 9), Then the merchant manager 36 confirms to the client 10 the delivery of the good, the amount and the CVD number used by mini -message (step 10). At the end of the day, the merchant manager 36 sends its transaction files to the banking system 40, which triggers the clearing procedure (step 11). Finally, bank 40 credits the market account and debits the customer account (step 12). The dialogs identified in references 3, 4, 5, 6 are preferably standardized so as to always have the same interface between the various merchant management sites and the SCVDs. This example above provides the advantage of high payment reliability. In addition, it allows the merchant to delegate to a merchant manager dialog with the SCVD, an API then advantageously defining the dialogs between the merchant sites or the merchant manager servers and the SCVD. Contrary to some of the cases described above where the customers and the merchants are in direct relation, a merchant manager advantageously deals here with the connections with the SCVD server and the banks. This example is based on the fact that clients and merchants delegate the links with the SCVD server and the banks to a proxy. The examples described therefore make it possible to compensate for the fact that the current terminals cannot manage two different sessions with satisfactory ergonomics (here the recovery of the CVD number and the payment).

Claims

REVENDICATIONS
1. Procédé de transaction entre un terminal client (10) et un serveur de réception de paiement (30, 35, 36) par carte de paiement virtuelle, comprenant une étape de fourniture d'une carte de paiement virtuelle au serveur de réception de paiement (30, 35, 36), comprenant en outres l'étape préliminaire de prise en compte de coordonnées pré-établies de la part du client à destination d'un serveur d'émission de cartes virtuelles (20) en vue de l'émission d'une carte virtuelle, caractérisé en ce qu'il comprend- l'étape consistant à utiliser une liaison directe entre le serveur de cartes virtuelles (20) et le serveur de réception de paiement (30, 35, 36) pour fournir à ce serveur la carte virtuelle émise par Je serveur de cartes virtuelles (20 . 1. Method of transaction between a client terminal (10) and a payment reception server (30, 35, 36) by 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 contact details on the part of the client intended for a virtual card issuing server (20) with a view to issuing of a virtual card, characterized in that it comprises the step consisting in using a direct link between the virtual card server (20) and the payment reception server (30, 35, 36) to supply this server the virtual card issued by the virtual card server (20.
2. Procédé selon la revendication 1, caractérisé en ce qu'il comprend l'étape par laquelle le serveur de réception de paiement (30, 35, 36) requiert auprès du client (10) les coordonnées nécessaires à l'obtention d'une carte virtuelle, puis l'étape selon laquelle le serveur de réception de paiement (30, 35, 36) transmet lui-même ces coordonnées au serveur de cartes virtuelles (20). 2. Method according to claim 1, characterized in that it comprises the step by which the payment reception server (30, 35, 36) requests from the client (10) the contact details necessary for obtaining a virtual card, then the step according to which the payment reception server (30, 35, 36) itself transmits these coordinates to the virtual card server (20).
3. Procédé selon la revendication 1, caractérisé en qu'il comprend l'étape selon laquelle le serveur de réception de paiement met en place une liaison directe (50) entre le client (10) et le serveur de cartes virtuelles (20), le procédé comprenant en outre l'étape selon laquelle le client (10) fournit alors au serveur de cartes virtuelles (20) les coordonnées nécessaires à l'émission d'une carte virtuelle. 3. Method according to claim 1, characterized in that it comprises the step according to which the payment reception server sets up a direct link (50) between the client (10) and the virtual card server (20), the method further comprising the step whereby the client (10) then supplies the virtual card server (20) with the coordinates necessary for the issuance of a virtual card.
4. Procédé selon la revendication 1 , caractérisé en ce qu'il comprend une étape de mise en relation du serveur de cartes virtuelles (20) avec le serveur de réception de paiement (30, 35, 36) à l'initiative du client ("10), au moyen d'une identification du serveur de réception de paiement (30, 35, 36) délivrée par le client (10) au serveur de cartes virtuelles (20). 4. Method according to claim 1, characterized in that it comprises a step of bringing the virtual card server (20) into contact with the payment reception server (30, 35, 36) on the initiative of the client ( "10), by means of an identification of the payment reception server (30, 35, 36) delivered by the client (10) to the virtual card server (20).
5. Procédé selon l'une quelconque des revendications précédentes, caractérisé en ce que le serveur de réception de paiement (30, 35, 36) est une entité de présentation de produits. 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. Procédé selon l'une quelconque des revendications précédentes! , caractérisé en ce que le serveur de réception de paiement (30, 35, 36) e& un serveur (35, 36) réceptionnant des paiements pour le compte d'une entité de présentation de produits (30) qui est distincte de ce serveur de réception de paiement (35, 36). 7, Procédé selon la revendication 4, caractérisé en ce qu'il comprend en outre l'étape par laquelle le serveur de cartes virtuelles (20) informe le client (10) qu'une carte virtuelle a bien été émise à destination du serveur de réception de paiement (30, 35, 36) identifié par le client (10). 8. Procédé selon la revendication 4, caractérisé en ce qu'il fait appel à une entité de présentation de produits qui est distincte du serveur des réception de paiement, et en ce qu'il comprend en outre l'étape par laquelle* le serveur de réception de paiement (30, 35, 36) informe, par émission d'un message à destination d'un terminal de communication (37) appartenant à l'entité de présentation de produits, qu'il a effectivement reçu un paiement par carte virtuelle. 9. Procédé de créditement de compte téléphonique prépayé par carte de paiement virtuelle, caractérisé en ce qu'il inclut le procédé de transaction selon l'une quelconque de revendications précédentes. 10. Dispositif de transaction comprenant un serveur de réception de paiement (30, 35, 36), un serveur émetteur de cartes de paiement virtuelles, le serveur de cartes virtuelles (20) étant apte à fournir une carte de paiement virtuelle à la réception de coordonnées de client préétablies et le serveur de réception de paiement (30, 35, 36) étant apte à entériner un paiement en échange de la réception d'une carte virtuelle, le dispositif étant caractérisé en ce qu'il comprend en outre des moyens formant une liaison directe (50) entre le serveur de réception de paiement (30, 35, 36) et le serveur de cartes virtuelles (20), le serveur de cartes virtuelles (20) incorporant des moyens d'émission de la carte virtuelle sur ce lien direct à destination du serveur de réception de paiement (30, 35, 36). 11. Dispositif selon la revendication 10, caractérisé en ce que le serveur de réception de paiement (30, 35, 36) comporte des moyens de dialogue avec un terminal client (10) et des moyens pour initier, au cours d'une session de dialogue avec le client, une relation directe entre ce client (10) et le serveur de cartes virtuelles (20), en vue d'une fourniture directe depuis le terminal client vers le serveur de cartes virtuelles (20) des coordonnées préétablies nécessaires à l'émission d'une carte virtuelle. 12. Dispositif selon la revendication 10, caractérisé en ce que le serveur de réception de paiement (30, 35, 36) inclut des moyens de dialogue avec un terminal client, aptes à requérir de ce terminai client (10) la fourniture de coordonnées préétablies nécessaires à l'émission d'une carte virtuelle, et aptes à transmettre ces coordonnées au serveur de cartes virtuelles (20). 13. Dispositif selon la revendication 10, caractérisé en ce que l-e serveur de cartes virtuelles comporte des moyens pour réceptionner, de ta part du client (10), des coordonnées d'identification de serveur de réception de paiement (30, 35, 36), et mettre en place une liaison directe entre le serveur de cartes virtuelles et le serveur de réception de paiement ainsi identifié. 14. Dispositif selon l'une quelconque des revendications 10 à 13*, caractérisé en ce que le serveur de réception de paiement (30, 35, 36) est une entité de présentation de produits (30). 15. Dispositif selon l'une quelconque des revendications 10 à 15, caractérisé en ce qu'il comprend une entité de présentation de produits (30 ) et en ce que le serveur de réception de paiement (35, 36) est distinct de cette entité mais réceptionnant des paiements pour le compte de cette entité. 16. Dispositif selon l'une quelconque des revendications 10 à 15 caractérisé en ce que le serveur de cartes virtuelles (20) comprend des moyens pour émettre un message à destination d'un terminal client (10), indiquant qu'une carte virtuelle a été émise à destination du serveur d& réception de paiement. 17. Dispositif selon la revendication 13, caractérisé en ce qu'il comprend une entité de présentation de produits (30), un serveur de réception de paiement (35, 36) qui est distinct de cette entité de présentation de produits (30) mais réceptionnant des paiements pour cette entité, le serveur de réception de paiement (35, 36) comprenant des moyens pour émettre un message à destination d'un terminal de communication (37) appartenant à l'entité de présentation de produits, message indiquant qu'une carte virtuelle a été réceptionnée par le serveur de réception de paiement (30, 35, 36) 18. Dispositif selon l'une quelconque des revendications 10 à 17, caractérisé en ce que le serveur de réception de paiement (30, 35, 36) est un serveur de rechargement dé compte téléphonique prépayé. 6. Method according to any one of the preceding claims! , characterized in that the payment receiving server (30, 35, 36) e & a server (35, 36) receiving payments on behalf of a product presentation entity (30) which is separate from this payment server receipt of payment (35, 36). 7, A 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 indeed been issued to the server. receipt of payment (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 receipt server, and in that it further comprises the step by which * the server receiving payment (30, 35, 36) informs, by sending a message to a communication terminal (37) belonging to the product presentation entity, that it has actually received a payment by card Virtual. 9. Method for crediting a prepaid telephone 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 supply a virtual payment card upon receipt of pre-established customer coordinates and the payment reception server (30, 35, 36) being able to confirm a payment in exchange for the reception 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 of dialogue with a client terminal (10) and means for initiating, during a dialogue session with the client, a direct relationship between this client (10) and the virtual card server (20), with a view to direct supply from the client terminal to the virtual card server (20) of the pre-established contact details required to issue a virtual card. 12. Device according to claim 10, characterized in that the payment reception server (30, 35, 36) includes means of dialogue with a client terminal, capable of requesting from this client terminal (10) the supply of pre-established coordinates. necessary for issuing a virtual card, and capable of transmitting these coordinates to the virtual card server (20). 13. Device according to claim 10, characterized in that the virtual card server comprises means for receiving, from the client (10), identification coordinates of the payment reception server (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 15, 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 this 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 has has been sent to the payment reception server. 17. 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 this entity, the payment reception server (35, 36) comprising 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 payment server recharging of prepaid telephone account.
PCT/FR2005/000602 2004-03-15 2005-03-14 Transaction device with improved efficiency WO2005101336A1 (en)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR0402635A FR2867585A1 (en) 2004-03-15 2004-03-15 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
FR0402635 2004-03-15

Publications (1)

Publication Number Publication Date
WO2005101336A1 true WO2005101336A1 (en) 2005-10-27

Family

ID=34896519

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/FR2005/000602 WO2005101336A1 (en) 2004-03-15 2005-03-14 Transaction device with improved efficiency

Country Status (2)

Country Link
FR (1) FR2867585A1 (en)
WO (1) WO2005101336A1 (en)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN107257284A (en) * 2016-06-24 2017-10-17 收付宝科技有限公司 A kind of method and apparatus for carrying out virtual card transaction

Families Citing this family (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20100332334A1 (en) * 2007-12-11 2010-12-30 Craig Patrick Kilfoil System and method for sending money to a recipient
FR2945881B1 (en) * 2009-05-19 2019-06-28 Worldline METHOD AND SYSTEM FOR TRANSACTING GOODS AND / OR SERVICES USING A TERMINAL VIA A COMMUNICATION NETWORK
FR3043232A1 (en) * 2015-11-03 2017-05-05 Orange METHOD OF VERIFYING IDENTITY DURING VIRTUALIZATION

Citations (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP0590861A2 (en) * 1992-09-29 1994-04-06 AT&T Corp. Secure credit/debit card authorization
WO1999005633A1 (en) * 1997-07-25 1999-02-04 Main Street Marketing Automated credit card payment system
WO2000002150A1 (en) * 1998-07-01 2000-01-13 Webcard Inc. Transaction authorisation method
EP1028401A2 (en) * 1999-02-12 2000-08-16 Citibank, N.A. Method and system for performing a bankcard transaction
WO2000072109A2 (en) * 1999-05-25 2000-11-30 Safepay Australia Pty Limited System for handling network transactions
WO2001065502A2 (en) * 2000-02-29 2001-09-07 E-Scoring, Inc. Systems and methods enabling anonymous credit transactions
US20010034702A1 (en) * 2000-02-04 2001-10-25 Mockett Gregory P. System and method for dynamically issuing and processing transaction specific digital credit or debit cards
WO2001090845A2 (en) * 2000-05-19 2001-11-29 Mybusinessonly, Incorporated A system and method for conducting anonymous transactions using a trusted intermediary
US20020128977A1 (en) * 2000-09-12 2002-09-12 Anant Nambiar Microchip-enabled online transaction system

Patent Citations (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP0590861A2 (en) * 1992-09-29 1994-04-06 AT&T Corp. Secure credit/debit card authorization
WO1999005633A1 (en) * 1997-07-25 1999-02-04 Main Street Marketing Automated credit card payment system
WO2000002150A1 (en) * 1998-07-01 2000-01-13 Webcard Inc. Transaction authorisation method
EP1028401A2 (en) * 1999-02-12 2000-08-16 Citibank, N.A. Method and system for performing a bankcard transaction
WO2000072109A2 (en) * 1999-05-25 2000-11-30 Safepay Australia Pty Limited System for handling network transactions
US20010034702A1 (en) * 2000-02-04 2001-10-25 Mockett Gregory P. System and method for dynamically issuing and processing transaction specific digital credit or debit cards
WO2001065502A2 (en) * 2000-02-29 2001-09-07 E-Scoring, Inc. Systems and methods enabling anonymous credit transactions
WO2001090845A2 (en) * 2000-05-19 2001-11-29 Mybusinessonly, Incorporated A system and method for conducting anonymous transactions using a trusted intermediary
US20020128977A1 (en) * 2000-09-12 2002-09-12 Anant Nambiar Microchip-enabled online transaction system

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN107257284A (en) * 2016-06-24 2017-10-17 收付宝科技有限公司 A kind of method and apparatus for carrying out virtual card transaction
CN107257284B (en) * 2016-06-24 2020-05-19 收付宝科技有限公司 Method and device for carrying out virtual card transaction

Also Published As

Publication number Publication date
FR2867585A1 (en) 2005-09-16

Similar Documents

Publication Publication Date Title
EP0451057B1 (en) System for paying services by telephone
US7685020B2 (en) Mobile commerce receipt system
US7461010B2 (en) Computer network method for conducting payment over a network by debiting and crediting telecommunication accounts
US8463674B2 (en) System and method for distributing mobile gift cards
US8086530B2 (en) Electronic payment system utilizing intermediary account
EP1360665A1 (en) Telepayment method and system
EP1014317A1 (en) Secure payment method
US20130103546A1 (en) Method and system for secure electronic transactions
KR20100059932A (en) Mobile remittances/payments
EP1256911A1 (en) Securization method for a payment from a client to a merchant, associated location server and system
EP1754205A1 (en) Anonymous and secure internet payment method and mobile devices
WO2003083733A2 (en) System of setting up a connection between two users of a telecommunication network
GB2366162A (en) Controlling access to a telecommunicated data file
WO2005101336A1 (en) Transaction device with improved efficiency
FR2795897A1 (en) Secure transaction system for Internet purchases uses link to mobile phone for confirmation of transaction payment
WO2005052869A1 (en) Method and system for the electronic payment of goods or services which are dispensed by an automaton with asynchronous reconciliation
US20160162874A1 (en) Using successive levels of authentication in online commerce
FR2823882A1 (en) Commercial transaction using prepayment card over the Internet, uses personal computer or mobile phone, certification center validates data contained on prepayment card
WO2016005947A1 (en) Method for managing a transaction, corresponding server, computer program product and storage medium
FR2816422A1 (en) METHOD FOR THE PAYMENT OF TRANSACTIONS CARRIED OUT FOR EXAMPLE ON THE INTERNET
FR3005190A1 (en) METHOD OF DELIVERING BY A MOBILE TELEPHONY CARD AUTOMATE SIM WITH PREPAID OR POSTPAYED SUBSCRIPTION
FR2945881B1 (en) METHOD AND SYSTEM FOR TRANSACTING GOODS AND / OR SERVICES USING A TERMINAL VIA A COMMUNICATION NETWORK
WO2002031612A2 (en) Method for carrying out a commercial transaction over a network
WO2005088568A1 (en) Micropayment method and device
FR2869702A1 (en) Pre-paid or post paid telephonic service accessing method for e.g. telephone, involves utilizing memory key comprising universal serial bus connection as information storage media for authentication of user account

Legal Events

Date Code Title Description
AK Designated states

Kind code of ref document: A1

Designated state(s): AE AG AL AM AT AU AZ BA BB BG BR BW BY BZ CA CH CN CO CR CU CZ DE DK DM DZ EC EE EG ES FI GB GD GE GH GM HR HU ID IL IN IS JP KE KG KP KR KZ LC LK LR LS LT LU LV MA MD MG MK MN MW MX MZ NA NI NO NZ OM PG PH PL PT RO RU SC SD SE SG SK SL SM SY TJ TM TN TR TT TZ UA UG US UZ VC VN YU ZA ZM ZW

AL Designated countries for regional patents

Kind code of ref document: A1

Designated state(s): BW GH GM KE LS MW MZ NA SD SL SZ TZ UG ZM ZW AM AZ BY KG KZ MD RU TJ TM AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HU IE IS IT LT LU MC NL PL PT RO SE SI SK TR BF BJ CF CG CI CM GA GN GQ GW ML MR NE SN TD TG

121 Ep: the epo has been informed by wipo that ep was designated in this application
NENP Non-entry into the national phase

Ref country code: DE

WWW Wipo information: withdrawn in national office

Country of ref document: DE

122 Ep: pct application non-entry in european phase