Pratiques exemplaires en matière de commerce électronique: Pour les cartes de crédit refusées, quelle quantité d'information est trop importante?

Question

Mes collègues discutent de la façon dont les transactions par carte de crédit ont été refusées. Nous obtenons beaucoup de détails sur les transactions de notre processeur de carte, et nous essayons de décider combien d'informations à transmettre à l'utilisateur. Par exemple, dites-vous à l'utilisateur que sa carte a été refusée parce qu'elle a expiré ou que le numéro CCV est erroné, ou y a-t-il trop de risque de fraude dans ce cas? Et lorsque nous renvoyons l'utilisateur à la page où il fournit les détails de paiement, remplissons-nous les champs avec les données saisies précédemment ou non?

Answer 1

Dans le passé, j'ai donné autant d'informations que possible et l'ai rendu aussi facile à corriger que possible. Je ne veux pas arrêter une vente potentielle (ou dans mon cas un don). Pour ce qui est de traiter la fraude, n'essayez pas d'y faire face en espérant que les associer à un mauvais numéro CCV va les ralentir, les gérer autrement, comme suivre la fréquence à laquelle une session tente de traiter une carte. (et échouant), si c'est trop de fois dans X temps, les liste noire. C'est une question distincte cependant.

Answer 2

Dans le passé, j'ai essayé d'être aussi général que possible. Par exemple, si vous dites que le numéro CVV2 est incorrect. Bien sûr, cela aide le titulaire de carte valide en leur faisant savoir que c'est le CVV2 qui est incorrect. Il permet également un indésirable savoir que le numéro de carte de crédit est correct. S'ils échouent, peut-être que vous les invitez à contacter quelqu'un.

Lorsque vous parlez de pré-remplissage des champs parlent d'après qu'ils ont échoué et réessayer ou à une occasion complètement distincte? Si c'est après qu'ils ont échoué, il me semble que la manière sécurisée de le faire serait de ne plus l'afficher, mais vous devrez vous assurer qu'ils ne pourraient pas cliquer en arrière et obtenir la même information, sinon il est inutile. Cela n'a peut-être pas beaucoup d'importance, cependant.

Si vous parlez d'une occasion complètement séparée, vous avez besoin d'un endroit pour stocker cette information. Si c'est sur vos serveurs, je vous suggère de regarder PCI-DSS. Même si vous transmettez simplement les données à une passerelle, vous devez être en conformité.

Answer 3

J'ai participé à un examen de conformité PCI il y a environ 4 ans, et la politique consistait alors simplement à renvoyer un Accepté ou Rejeté et l'ID de transaction à l'utilisateur. Si la transaction a été rejetée, nous avons ajouté une note "Pour plus d'informations contactez votre fournisseur de carte de crédit et citez ce numéro ...". Le raisonnement est que si quelqu'un tente de générer des numéros de carte, vous ne voulez pas lui fournir d'informations sur ce qu'il faut changer pour obtenir une carte valide. Si c'est une personne réelle, il y a trop de choses qui vont mal avec une transaction que vous n'êtes pas en mesure de résoudre, dites-leur de contacter leur fournisseur de carte. Même si la réponse de la transaction est "Carte expirée", cela pourrait être quelque chose d'autre, vous ne le savez pas, ne le devinez pas.

De même, si vous revenez sur une page avec des champs de paiement, ne les préconfigurez pas, laissez-les vides. Les clients pourraient faire une réflexion paranoïaque "Hey, est-ce que cette chose se souvenir de mon information de carte de crédit !?" La raison la plus probable pour laquelle la carte a été rejetée est qu'ils ont tapé quelque chose de faux, et en la remplissant de nouveau avec les mauvaises infos, vous êtes simplement tenté de cliquer sur Soumettre encore et encore jusqu'à ce que leur limite de crédit soit dépassée. Été là, fait cela.