perso, ça me dérange de donner mes identifiants bancaires (mot de passe d'accès à mon espace client notamment...) à quelqu'un d'autre que ma banque...
Mais tu ne fais jamais ça. La procédure standard, c'est que tu saisis tes informations de payement (nom sur la carte, numéro de carte, date de validité, et code de sécurité) dans un formulaire sur le site du commerçant. Tu valides les payement, et le commerçant contacte la banque. Plusieurs possibilités:
-> Le commerçant passe outre la double vérif (parce que le montant et faible et/ou tu es déja client chez lui), et la commande est validée instantanément
-> La banque te contacte directement (par une notification ou par un SMS) pour valider le payement sur un autre terminal (typiquement, ton smartphone)
-> Exceptionnellement, si tu n'as pas de smartphone ou que tu as spécifié une procédure spécifique, tu es redirigé vers le site de ta banque.
C'est cette dernière situation que je trouve dangereuse, puisqu'il est relativement facile de se faire passer pour la banque dans ce cas. C'est pourtant la solution préconisée par l'OP, et c'est pour ça que je suis en désaccord. Ça semble "standard", mais 1) c'est peu ergonomique (on sort complètement du site, il faut éventuellement resaisir ses informations...), 2) c'est buggogène (notamment avec toutes les extensions anti-scripts et anti-redirections), 3) c'est dangereux (parce que c'est très facile d'essayer d'usurper le site de la banque et d'obtenir justement les identifiants de connexion).
Du point de vue de l'utilisateur, je trouve donc bien plus facile et sécurisant de confier au commerçant ses identifiants de payement, qui ne permettent que de demander un payement (mais pas de le valider), et de valider indépendamment du commerçant, en étant contacté directement par la banque, via une procédure à laquelle le commerçant n'a pas accès (SMS ou appli bancaire).
[^] # Re: Paiement en iframe
Posté par arnaudus . En réponse au journal Exigeons des banques, une vraie mise en œuvre de la DSP2 !. Évalué à 5.
Mais tu ne fais jamais ça. La procédure standard, c'est que tu saisis tes informations de payement (nom sur la carte, numéro de carte, date de validité, et code de sécurité) dans un formulaire sur le site du commerçant. Tu valides les payement, et le commerçant contacte la banque. Plusieurs possibilités:
-> Le commerçant passe outre la double vérif (parce que le montant et faible et/ou tu es déja client chez lui), et la commande est validée instantanément
-> La banque te contacte directement (par une notification ou par un SMS) pour valider le payement sur un autre terminal (typiquement, ton smartphone)
-> Exceptionnellement, si tu n'as pas de smartphone ou que tu as spécifié une procédure spécifique, tu es redirigé vers le site de ta banque.
C'est cette dernière situation que je trouve dangereuse, puisqu'il est relativement facile de se faire passer pour la banque dans ce cas. C'est pourtant la solution préconisée par l'OP, et c'est pour ça que je suis en désaccord. Ça semble "standard", mais 1) c'est peu ergonomique (on sort complètement du site, il faut éventuellement resaisir ses informations...), 2) c'est buggogène (notamment avec toutes les extensions anti-scripts et anti-redirections), 3) c'est dangereux (parce que c'est très facile d'essayer d'usurper le site de la banque et d'obtenir justement les identifiants de connexion).
Du point de vue de l'utilisateur, je trouve donc bien plus facile et sécurisant de confier au commerçant ses identifiants de payement, qui ne permettent que de demander un payement (mais pas de le valider), et de valider indépendamment du commerçant, en étant contacté directement par la banque, via une procédure à laquelle le commerçant n'a pas accès (SMS ou appli bancaire).