[RESOLU] Validation d'un paiement, peut-on tricher ?

Eléphant du PHP | 337 Messages

23 avr. 2016, 20:00

Bonjour,

Je finalise un site avec paiement en ligne, et suis soudain pris d'un gros doute existentiel...

Imaginons un client lambda qui valide son panier, arrive sur la page de paiement : le programme crée un formulaire de paiement avec les différentes variables relatives à la commande.

Puis, le client lambda, un peu fourbe ou étourdi, garde cette page ouverte, ouvre une autre fenêtre, remplit son panier à gogo : la commande est mise à jour dans la base de données.

Enfin, le client fourbe/étourdi revient sur la première fenêtre, avec un formulaire de paiement qui n'est plus à jour, et il valide son paiement depuis cette page.

Potentiellement, il paye donc le mauvais prix.


J'ai imaginé plusieurs solutions mais je ne suis sûr de rien :

- il me semble que les moyens de paiements prévoient un contrôle entre le prix effectivement payé par le client, et le prix de la commande (en tout cas, y a ça chez Paybox et chez Paypal). Cela s'applique-t-il donc ? Rien n'est moins sûr.

- sinon, est-il possible d'envisager, avant l'envoi effectif du formulaire vers le serveur du site de paiement, une page intermédiaire qui vérifie que la commande est conforme au prix payé ? Sinon, le formulaire n'est pas envoyé et un message d'erreur s'affiche.

Merci de vos conseils et lumières :D

Mammouth du PHP | 2703 Messages

23 avr. 2016, 20:06

pour empecher de tricher, il suffit d'empecher de mettre à jour la commande une fois qu'une étape a été franchie. si l'internaute ajoute des produits, ces produits sont ajoutés à une nouvelle commande.

Eléphant du PHP | 337 Messages

24 avr. 2016, 17:54

Ça fonctionnerait bien en effet, mais ça suppose que le système soit prévu pour pouvoir gérer plus d'une commande à la fois pour un même client, ce qui n'est pas le cas ici.

Et si je prévois un système qui "verrouille" la commande, de deux choses l'une :

- soit il est impossible de la déverrouiller, auquel cas ça fonctionne
- soit le client peut encore changer d'avis, déverrouiller la commande, et le problème reste intact...

Avatar du membre
Modérateur PHPfrance
Modérateur PHPfrance | 10684 Messages

25 avr. 2016, 13:08

Bonjour,

Le mieux serait effectivement de dissocier le panier de la commande... quand l'utilisateur valide le contenu de son panier, tu en stockes le contenu dans une pré-commande ou une commande en attente de confirmation, ... bref, tu le figes avant de procéder au paiement de cette commande.

Si l'utilisateur continue de remplir son panier et sa session, pas de soucis, au moment du paiement, là encore tu figeras la nouvelle commande. S'il parvient à revenir à l'ancienne, il pourra soit la payer, soit l'abandonner. Elle ne sera en rien liée à la nouvelle et tu n'auras qu'à faire le ménage dans les commandes figées depuis X minutes, heures, jours, ... et qui n'ont pas été payées pour les supprimer régulièrement.
Ce n'est pas en améliorant la bougie que l'on a inventé l'ampoule...

Avatar du membre
Administrateur PHPfrance
Administrateur PHPfrance | 9783 Messages

25 avr. 2016, 13:37

Bonjour,

Dans tous les cas, et sans exception, il est impératif pour toi d'attendre le retour de la plateforme de payement qui te confirmera le montant effectivement payé, que tu pourras comparer avec ce que tu as en base de données.

Chez Paypal, par exemple, le retour de confirmation s'appelle IPN (Instant Payment Notification).
Quand tout le reste a échoué, lisez le mode d'emploi...

Eléphant du PHP | 337 Messages

25 avr. 2016, 14:00

Merci pour vos réponses.

Cela confirme ce que je pensais, il n'y a que deux solutions :

- verrouiller la commande, et donc assurer qu'elle sera valide directement depuis le site de vente
- ne pas verrouiller, et laisser l'IPN vérifier que le prix payé est conforme (auquel cas cela crée une erreur de commande, que le vendeur devra gérer).

As usual, je serais curieux de savoir comment font les autres :-s