FR2867585A1 - Dispositif de transaction a efficacite amelioree - Google Patents

Abstract

L'invention concerne un 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 outre 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 le serveur de cartes virtuelles (20).

Description

Le domaine technique de l'invention est celui des services de 5

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 applet 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 99 49424 fait état de la possibilité pour un utilisateur de télécharger depuis son PC via une applet 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 PDAltéléphone mobilelté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 coàrdonnées pré-établies 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 25 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 (SVI 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 oeuvre par l'ensemble représenté à la 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.

Il 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'authentification 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 te 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 à l'utilisateur 10 le rechargement du compte, le montant du rechargement et le 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 15 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 l'é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 accè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 30 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 oeuvre. 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 5 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 du 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 fichiers 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 20 les différents serveurs de rechargement 35 et les SCVD 20.

Dans les deux cas exposés ci-avant, le serveur marchand 30 est interfacé 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 25 n'importe quel terminal d'accès distant (PC, PDA etc...).

Après authentification 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 t 4 2867585 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 gestionnaire 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. II 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 la transaction. Le gestionnaire de marchands peut également 2867585 9 récupérer les paramètres pour l'authentification 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 oeuvre (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 (étape 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). Puis le gestionnaire de marchands 36 envoie une demande de confirmation de la transaction au marchand 30 (terminal 37) grâce à une base MSISDNIcode marchand (étape 6).

Le marchand 30 valide alors la transaction (étape 7). Puis le 25 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 11).

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 oeuvre 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 MSISDN/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 (étape 6).

A ce stade, le gestionnaire de marchands 36 envoie une demande de confirmation de la transaction au marchand 30 sur son terminal (37) 25 (é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 30 (é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 marchand 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 la même interface entre 5 les'différents sites gestionnaires de marchands et les SCVD.

Cet exemple ci-dessus fournit l'avantage d'une 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).

Claims (1)

12 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 outre 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 le serveur de cartes virtuelles (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).

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.

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).

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.

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) est 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 de 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 terminal 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 le serveur de cartes virtuelles comporte des moyens pour réceptionner, de la 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 à 13, 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 de 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 de compte téléphonique prépayé.