2010-05-06 5 views
7

J'ai de sérieux problèmes avec l'acceptation des paiements.Comment puis-je empêcher les utilisateurs de surcharger le coût total d'un panier, lorsqu'il est soumis en tant que champ de saisie masqué?

Je passe le montant total dans un champ caché

<input type="hidden" 
    name="checkout-flow-support.merchant-checkout-flow-support.shipping-methods.flat-rate-shipping-1.price" 
    value="129.00"/> 

Certains utilisateurs ont changé cette valeur à 2 en utilisant Firebug et soumis le formulaire. Au lieu d'obtenir 129 $, nous n'avons reçu que 2 $.

Je n'ai aucune idée de la façon de procéder cette personne m'aidera rapidement.

Répondre

9

im passer le montant total dans un champ caché

Ne fais pas ça!

Puisque vous savez quels éléments l'utilisateur tente d'acheter, calculez le coût côté serveur.

+0

bien thanxs hobodave pour votre info. Juste une situation si vous avez faire don de 15 $ dans votre site et son formulaire html avec des champs cachés à ce moment-là comment ça va aider :( – Gobi

+0

S'il s'agit d'un don, alors bien sûr le montant est défini par l'utilisateur. Si c'est le cas, alors pourquoi un utilisateur donnant 2 $ au lieu de 129 $ importe-t-il? – hobodave

+2

La première règle du Distributed Computing Club est: Vous ne faites PAS confiance au client La deuxième règle du Distributed Computing Club est: Vous ne faites PAS confiance au client.La troisième règle du Distributed Computing Club est: Si c'est votre première visite, vous allez enfreindre les règles, et nous allons vous battre pour cela. – Jason

3

Ceci est une erreur de manuel, analogue à demander à un client dans un magasin de brique-et-mortier combien coûte l'article et faire confiance à cette réponse. C'est un cas particulier du principe de sécurité générale: ne pas faire confiance au client. La réponse de Hobodave est correcte. calculer les prix, les taxes, etc. côté serveur.

3

avec les fournisseurs de services de paiement (PSP), la configuration générale de communication va généralement quelque chose comme:

1) Votre serveur contacte la PSP et met en place la transaction, en précisant le montant requis et les détails de votre compte PSP.

2) Le PSP répond avec un identificateur de transaction, que vous ajoutez ensuite au formulaire. Cet identifiant de transaction ne contient aucune information sur les prix impliqués - il s'agit simplement d'un identifiant de l'enregistrement de transaction que votre serveur a mis en place avec le PSP.

3) Le visiteur remplit le formulaire qui est envoyé à la PSP. Ils redirigent ensuite le visiteur vers votre site.

4) Votre serveur interroge le serveur PSP et vérifie que la transaction a réussi (ie. Le mode de paiement des visiteurs OK'd la transaction avec la PSP, etc.)

La communication serveur-PSP est généralement fait en utilisant une bibliothèque telle que curl.

Google fournit un certain nombre de bibliothèques/exemples sur la façon de traiter correctement les transactions (et la plupart des autres PSPs font la même chose, dans mon expérience): http://code.google.com/apis/checkout/samplecode.html

Les détails de communication exacts peuvent varier en fonction de la PSP, mais Fondamentalement, il ne devrait pas être nécessaire d'avoir le "montant total" jamais passer par le formulaire affiché au visiteur. Tout est fait de serveur à serveur pour que le visiteur ne puisse pas changer les détails.

+0

-1: Vous semblez avoir complètement raté le point. Cette question n'a rien à voir avec la communication PSP Server <->, mais l'erreur de développeur flagrante dans l'acceptation du coût via l'entrée de l'utilisateur. – hobodave

+1

Ce qui se produit généralement parce que la personne posant la question comprend mal comment le processus de communication entre leur application, la PSP et le navigateur des visiteurs est supposé se produire. Simplement leur dire «ne pas» ou «c'est mauvais» n'est généralement pas très utile. Ici, j'ai essayé d'expliquer ce qu'ils devraient faire à la place. – AllenJB

+0

Je pense que la réponse d'Allen est juste. La dernière phrase de la réponse explique la partie "pourquoi" ... –