Pour une application E commerce web, on peut etre amener a saisir
un paiement, on doit s'adresser a la banque pour avoir une
api qui permet de transmettre l'autorisation au serveur, le dialogue
se fait avec un protocole ssl, mais est ce que le certficat est fourni
au commercant par la banque.
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Sylvain
zx wrote on 06/07/2007 19:48:
bonjour,
Pour une application E commerce web, on peut etre amener a saisir un paiement, on doit s'adresser a la banque pour avoir une api qui permet de transmettre l'autorisation au serveur, le dialogue se fait avec un protocole ssl, mais est ce que le certficat est fourni au commercant par la banque.
il faut distinguer 2 cas:
- généralement un "certificat" (assez souvent un truc propriétaire attendu par les dites APIs et contenant un clé et un identifiant de commerçant) est fourni par la banque.
ce certificat sert à activer la procédure de paiement, il ne sert pas à établir la session SSL avec le client internaute, mais uniquement à générer une URL qui sera la première en protocole https, le SSL étant fait avec des certs de la banque.
- un serveur peux également jouer son propre SSL, il aura alors ses propres certs (qui devront être émis par une autorité classique sous peine de faire fuir les internautes), la transaction pourra alors être mené entièrement par le site marchand, il pourra enregistrer les détails du client pour une transaction à la main ou les forwarder à un serveur d'autorisation bancaire.
le 2nd cas est moins classique car plus compliqué et honéreux, pour ta seule question, le cert servant au SSL n'a pas besoin d'être fourni par la banque.
Sylvain.
zx wrote on 06/07/2007 19:48:
bonjour,
Pour une application E commerce web, on peut etre amener a saisir
un paiement, on doit s'adresser a la banque pour avoir une api qui
permet de transmettre l'autorisation au serveur, le dialogue
se fait avec un protocole ssl, mais est ce que le certficat est fourni
au commercant par la banque.
il faut distinguer 2 cas:
- généralement un "certificat" (assez souvent un truc propriétaire
attendu par les dites APIs et contenant un clé et un identifiant de
commerçant) est fourni par la banque.
ce certificat sert à activer la procédure de paiement, il ne sert pas à
établir la session SSL avec le client internaute, mais uniquement à
générer une URL qui sera la première en protocole https, le SSL étant
fait avec des certs de la banque.
- un serveur peux également jouer son propre SSL, il aura alors ses
propres certs (qui devront être émis par une autorité classique sous
peine de faire fuir les internautes), la transaction pourra alors être
mené entièrement par le site marchand, il pourra enregistrer les détails
du client pour une transaction à la main ou les forwarder à un serveur
d'autorisation bancaire.
le 2nd cas est moins classique car plus compliqué et honéreux, pour ta
seule question, le cert servant au SSL n'a pas besoin d'être fourni par
la banque.
Pour une application E commerce web, on peut etre amener a saisir un paiement, on doit s'adresser a la banque pour avoir une api qui permet de transmettre l'autorisation au serveur, le dialogue se fait avec un protocole ssl, mais est ce que le certficat est fourni au commercant par la banque.
il faut distinguer 2 cas:
- généralement un "certificat" (assez souvent un truc propriétaire attendu par les dites APIs et contenant un clé et un identifiant de commerçant) est fourni par la banque.
ce certificat sert à activer la procédure de paiement, il ne sert pas à établir la session SSL avec le client internaute, mais uniquement à générer une URL qui sera la première en protocole https, le SSL étant fait avec des certs de la banque.
- un serveur peux également jouer son propre SSL, il aura alors ses propres certs (qui devront être émis par une autorité classique sous peine de faire fuir les internautes), la transaction pourra alors être mené entièrement par le site marchand, il pourra enregistrer les détails du client pour une transaction à la main ou les forwarder à un serveur d'autorisation bancaire.
le 2nd cas est moins classique car plus compliqué et honéreux, pour ta seule question, le cert servant au SSL n'a pas besoin d'être fourni par la banque.
Sylvain.
zx
Bonjour,
Merci beaucoup pour la réponse,
Ok, Une api peu avoir son propre certificat fourni par la banque pour traiter et encodé les informations du paiement?
On a un client web ssl qui communique en ssl entre l'acheteur et le commercant avec ses propres certificats, délivré par une CA (autorité de certifiation), ( verisign parr exemple), puis la transaction est acheminée jusqu'au serveur d'autorisation de la banque.
Lors de l'echange ssl, je suppose que la banque communique sa cle publique au commercant, les données envoyées par le commercant sont bien encodées avec la cle publique de la banque, et elle est ensuite décodée par la banque avec sa clé privé (rsa).
Mais est ce que le commercant communique aussi sa clé publique, je pense que les deux doivent s'echanger réciproquement les clés publique, sinon je vois pas comment le commercant peu décoder les informations envoyé par la banque en retour, sauf si le commercant a la cle privé de la banque ?
Si Il y'a des liens sur le sujet ou des bouquin, je suis intéressé, je potasse quelques bouquins, mais des que j'approche des aspects pratique et technique, ca devient un peu flou et un peu occulte, je connais un peu les aspects de l'autorisation coté serveur, mais pas du coté du paiement electronique via le web, coté client.
Merci pour vos informations
Cordialement
Bonjour,
Merci beaucoup pour la réponse,
Ok, Une api peu avoir son propre certificat fourni par la banque
pour traiter et encodé les informations du paiement?
On a un client web ssl qui communique en ssl entre l'acheteur et le
commercant avec ses propres certificats, délivré par une CA (autorité de
certifiation),
( verisign parr exemple), puis la transaction est acheminée jusqu'au
serveur d'autorisation
de la banque.
Lors de l'echange ssl, je suppose que la banque communique sa cle publique
au commercant,
les données envoyées par le commercant sont bien encodées avec la cle
publique de la banque,
et elle est ensuite décodée par la banque avec sa clé privé (rsa).
Mais est ce que le commercant communique aussi sa clé publique, je pense
que les deux doivent s'echanger
réciproquement les clés publique, sinon je vois pas comment le commercant
peu décoder les informations
envoyé par la banque en retour, sauf si le commercant a la cle privé de la
banque ?
Si Il y'a des liens sur le sujet ou des bouquin, je suis intéressé, je
potasse
quelques bouquins, mais des que j'approche des aspects pratique et
technique,
ca devient un peu flou et un peu occulte, je connais un peu les aspects de
l'autorisation coté serveur,
mais pas du coté du paiement electronique via le web, coté client.
Ok, Une api peu avoir son propre certificat fourni par la banque pour traiter et encodé les informations du paiement?
On a un client web ssl qui communique en ssl entre l'acheteur et le commercant avec ses propres certificats, délivré par une CA (autorité de certifiation), ( verisign parr exemple), puis la transaction est acheminée jusqu'au serveur d'autorisation de la banque.
Lors de l'echange ssl, je suppose que la banque communique sa cle publique au commercant, les données envoyées par le commercant sont bien encodées avec la cle publique de la banque, et elle est ensuite décodée par la banque avec sa clé privé (rsa).
Mais est ce que le commercant communique aussi sa clé publique, je pense que les deux doivent s'echanger réciproquement les clés publique, sinon je vois pas comment le commercant peu décoder les informations envoyé par la banque en retour, sauf si le commercant a la cle privé de la banque ?
Si Il y'a des liens sur le sujet ou des bouquin, je suis intéressé, je potasse quelques bouquins, mais des que j'approche des aspects pratique et technique, ca devient un peu flou et un peu occulte, je connais un peu les aspects de l'autorisation coté serveur, mais pas du coté du paiement electronique via le web, coté client.
Merci pour vos informations
Cordialement
zx
Bonjour,
Merci beaucoup pour la réponse,
Ok, Une api peu avoir son propre certificat fourni par la banque pour traiter et encodé les informations du paiement.
On a un client web ssl qui communique en ssl entre l'acheteur et le commercant avec ses propres certificats, délivré par une CA (autorité de certifiation), ( verisign parr exemple), puis la transaction est acheminée jusqu'au serveur d'autorisation de la banque.
Lors de l'echange ssl, je suppose que la banque communique sa cle publique au commercant, les données envoyées par le commercant sont bien encodées avec la cle publique de la banque, et elle est ensuite décodée par la banque avec sa clé privé (rsa).
Mais est ce que le commercant communique aussi sa clé publique, je pense que les deux doivent s'echanger réciproquement les clés publique, sinon je vois pas comment le commercant peu décoder les informations envoyé par la banque en retour, sauf si le commercant a la cle privé de la banque ?
Si Il y'a des liens sur le sujet ou des bouquin, je suis intéressé, je potasse quelques bouquins, mais des que j'approche des aspects pratique et technique, ca devient un peu flou et un peu occulte, je connais un peu les aspects de l'autorisation coté serveur, mais pas du coté du paiement electronique via le web, coté client.
Merci pour vos informations
Cordialement
Bonjour,
Merci beaucoup pour la réponse,
Ok, Une api peu avoir son propre certificat fourni par la banque
pour traiter et encodé les informations du paiement.
On a un client web ssl qui communique en ssl entre l'acheteur et le
commercant avec ses propres certificats, délivré par une CA (autorité de
certifiation),
( verisign parr exemple), puis la transaction est acheminée jusqu'au
serveur d'autorisation
de la banque.
Lors de l'echange ssl, je suppose que la banque communique sa cle publique
au commercant,
les données envoyées par le commercant sont bien encodées avec la cle
publique de la banque,
et elle est ensuite décodée par la banque avec sa clé privé (rsa).
Mais est ce que le commercant communique aussi sa clé publique, je pense
que les deux doivent s'echanger
réciproquement les clés publique, sinon je vois pas comment le commercant
peu décoder les informations
envoyé par la banque en retour, sauf si le commercant a la cle privé de la
banque ?
Si Il y'a des liens sur le sujet ou des bouquin, je suis intéressé, je
potasse
quelques bouquins, mais des que j'approche des aspects pratique et
technique,
ca devient un peu flou et un peu occulte, je connais un peu les aspects de
l'autorisation coté serveur,
mais pas du coté du paiement electronique via le web, coté client.
Ok, Une api peu avoir son propre certificat fourni par la banque pour traiter et encodé les informations du paiement.
On a un client web ssl qui communique en ssl entre l'acheteur et le commercant avec ses propres certificats, délivré par une CA (autorité de certifiation), ( verisign parr exemple), puis la transaction est acheminée jusqu'au serveur d'autorisation de la banque.
Lors de l'echange ssl, je suppose que la banque communique sa cle publique au commercant, les données envoyées par le commercant sont bien encodées avec la cle publique de la banque, et elle est ensuite décodée par la banque avec sa clé privé (rsa).
Mais est ce que le commercant communique aussi sa clé publique, je pense que les deux doivent s'echanger réciproquement les clés publique, sinon je vois pas comment le commercant peu décoder les informations envoyé par la banque en retour, sauf si le commercant a la cle privé de la banque ?
Si Il y'a des liens sur le sujet ou des bouquin, je suis intéressé, je potasse quelques bouquins, mais des que j'approche des aspects pratique et technique, ca devient un peu flou et un peu occulte, je connais un peu les aspects de l'autorisation coté serveur, mais pas du coté du paiement electronique via le web, coté client.
Merci pour vos informations
Cordialement
Sylvain
zx wrote on 07/07/2007 12:14:
tu ne décris pas tes contraintes (nombre de transactions, cout attendu par transaction, délégation ou non à un serveur bancaire de la gestion des pages (servies au client final) réalisant le paiement effectif (saisie du numéro de carte, etc), ...) - je décris donc ici des schémas existants mais peut être pas conformes à ton besoin exact.
Ok, Une api peu avoir son propre certificat fourni par la banque pour traiter et encodé les informations du paiement.
pour être clair: utilisé pour encoder les informations générant la demande de paiement (numéro de commerçant, montant, devise, message, logo, url de retour, de confirmation); la saisie et la transmission des informations bancaires du client n'est pas géré par ce cert là.
On a un client web ssl qui communique en ssl entre l'acheteur et le commercant avec ses propres certificats, délivré par une CA (autorité de certifiation), ( verisign parr exemple), puis la transaction est acheminée jusqu'au serveur d'autorisation de la banque.
ok, donc schéma 2 où le site marchand gère lui-même la saisie des info bancaires (cas des grands sites marchands).
les échanges entre le site marchand et sa banque peuvent être réalisés selon différents modes et je ne suis pas sur qu'une règle dominante existe, de plus selon les besoins du site marchand (télé-transmission immédiate ou différé, gestion des annulations, remboursements, etc) cette banque peut proposer des services et un protocole spécifiques.
il y a des chances d'être plus généralement dans un schéma bancaire (avec encryption symmétrique) plutôt que dans un schéma PKI - notamment parce que les échanges sont en "mode dépot" et non en mode échange entre serveurs.
un moyen d'obtenir des informations plus concrêtes est de contacter votre banque pour un RDV avec un conseiller e-commerce.
Sylvain.
zx wrote on 07/07/2007 12:14:
tu ne décris pas tes contraintes (nombre de transactions, cout attendu
par transaction, délégation ou non à un serveur bancaire de la gestion
des pages (servies au client final) réalisant le paiement effectif
(saisie du numéro de carte, etc), ...) - je décris donc ici des schémas
existants mais peut être pas conformes à ton besoin exact.
Ok, Une api peu avoir son propre certificat fourni par la banque
pour traiter et encodé les informations du paiement.
pour être clair: utilisé pour encoder les informations générant la
demande de paiement (numéro de commerçant, montant, devise, message,
logo, url de retour, de confirmation); la saisie et la transmission des
informations bancaires du client n'est pas géré par ce cert là.
On a un client web ssl qui communique en ssl entre l'acheteur et le
commercant avec ses propres certificats, délivré par une CA (autorité de
certifiation),
( verisign parr exemple), puis la transaction est acheminée jusqu'au
serveur d'autorisation
de la banque.
ok, donc schéma 2 où le site marchand gère lui-même la saisie des info
bancaires (cas des grands sites marchands).
les échanges entre le site marchand et sa banque peuvent être réalisés
selon différents modes et je ne suis pas sur qu'une règle dominante
existe, de plus selon les besoins du site marchand (télé-transmission
immédiate ou différé, gestion des annulations, remboursements, etc)
cette banque peut proposer des services et un protocole spécifiques.
il y a des chances d'être plus généralement dans un schéma bancaire
(avec encryption symmétrique) plutôt que dans un schéma PKI - notamment
parce que les échanges sont en "mode dépot" et non en mode échange entre
serveurs.
un moyen d'obtenir des informations plus concrêtes est de contacter
votre banque pour un RDV avec un conseiller e-commerce.
tu ne décris pas tes contraintes (nombre de transactions, cout attendu par transaction, délégation ou non à un serveur bancaire de la gestion des pages (servies au client final) réalisant le paiement effectif (saisie du numéro de carte, etc), ...) - je décris donc ici des schémas existants mais peut être pas conformes à ton besoin exact.
Ok, Une api peu avoir son propre certificat fourni par la banque pour traiter et encodé les informations du paiement.
pour être clair: utilisé pour encoder les informations générant la demande de paiement (numéro de commerçant, montant, devise, message, logo, url de retour, de confirmation); la saisie et la transmission des informations bancaires du client n'est pas géré par ce cert là.
On a un client web ssl qui communique en ssl entre l'acheteur et le commercant avec ses propres certificats, délivré par une CA (autorité de certifiation), ( verisign parr exemple), puis la transaction est acheminée jusqu'au serveur d'autorisation de la banque.
ok, donc schéma 2 où le site marchand gère lui-même la saisie des info bancaires (cas des grands sites marchands).
les échanges entre le site marchand et sa banque peuvent être réalisés selon différents modes et je ne suis pas sur qu'une règle dominante existe, de plus selon les besoins du site marchand (télé-transmission immédiate ou différé, gestion des annulations, remboursements, etc) cette banque peut proposer des services et un protocole spécifiques.
il y a des chances d'être plus généralement dans un schéma bancaire (avec encryption symmétrique) plutôt que dans un schéma PKI - notamment parce que les échanges sont en "mode dépot" et non en mode échange entre serveurs.
un moyen d'obtenir des informations plus concrêtes est de contacter votre banque pour un RDV avec un conseiller e-commerce.
