Débit CB à l'expédition

[Guest Asgarel]

Bonjour,

Alors voilà, pour mon futur site, j'aimerais proposer du débit à l'expédition pour mes clients. Parce que je trouve ça sécurisant pour l'acheteur, de ne pas être pris au piège par le commerçant si la livraison tarde un peu. Et puis, de plus en plus de gros sites fonctionnent comme ça, et ça fait plus "pro". Je cherche donc une solution pour mettre ce type de paiement en place.

Du coté des banques, il ne semble pas y avoir de solution complète. J'en ai contacté plusieurs, et le mieux qu'elles puissent faire, c'est de se servir du délai légal de 7 jours pour la validité du paiement. On peut donc retarder l'encaissement de 7 jours max, et même débiter le client pour un montant inférieur en cas de livraison partielle. Mais pas possible d'enregistrer une simple autorisation de prélèvement sur le compte du client ou de morceler le paiement en plusieurs "sous-paiements" si on livre la commande en plusieurs fois.

Du coté des "fournisseurs de TPEV", j'ai contacté PAYBOX, et la formule de base est la même que celle des banques. Mais il existe chez eux des formules plus évoluées comme DIRECT PLUS qui permettent à priori d'enregistrer de simples autorisations et de faire ce que je souhaite, mais avec une mise en place de 1800, un abonnement mensuel de 85 et aussi une interface plus compliquée entre le site et PAYBOX, donc du développement et du coût supplémentaire. Pas là solution pour démarrer, donc, mais quand le site est bien lancé, pourquoi pas ?

La dernière solution, conseillée par PAYBOX, est de faire de la saisie de paiement manuelle. On récupère le numéro de CB du client (crypté), on le copie sur un bout de papier, et quand on est prêt pour l'expédition, on débite sa carte sur un TPEV. La solution est un peu archaïque, certes, mais c'est simple, pas cher, et y a pas de raison que ça fonctionne pas. Qu'en pensez vous ?

Là où je m'interroge, c'est que, toujours d'après PAYBOX, de nombreux gros sites comme la FNAC ( :!: ) fonctionnent de cette manière. En remplaçant bien sur le bout de papier par une moulinette automatique. Ils conserveraient nos numéros de CB et ressaisiraient les paiements au jour J. Alors, peut-on tous procéder de la sorte, puisque les clients ne s'aperçoivent de rien, et que pour eux, c'est un service supplémentaire ? Où est le problème ?

Si certains pros ou utilisateurs expérimentés peuvent nous dire ce qu'ils pensent de tout ça, et par la même occasion nous dire tout ce qu'ils savent sur le paiement différé à l'expédition tel que pratiqué en France, ça pourrait peut-être lancer un débat profitable à tous...

[Spidetra]

Nous utilisions des développement en interne.

[blman]

Pour le débit à l'expédition, je pense que les logiciels de paiement sécurisé des banques le font.

En tout cas, moi je le fais avec le logiciel E-transaction du crédit agricole (qui n'est tout même surement pas le meilleur dès que tu veux faire des développement un peu plus poussé). Bref, voici comment ça fonctionne :

- le logiciel est paramétré en mode VALIDATION ce qui implique que le paiement se déroule en 2 phases :

1- le client donne son numéro de carte, ... : la banque test sa carte sur une valeur de 2 euros. Ca permet dans un premier temps de tester la fraude. Le client n'est pas débiter mais donne une autorisation de prélèvement

2- Une fois que ta commande est prête à être expédiée, tu peux valider le paiement sur une interface mise à disposition par la banque : dans ce cas, le logiciel revérifie la validité de la carte, le plafond, ... Le paiement peut être accepté ou refusé.

[Guest Asgarel]

- le logiciel est paramétré en mode VALIDATION ce qui implique que le paiement se déroule en 2 phases :

1- le client donne son numéro de carte, ... : la banque test sa carte sur une valeur de 2 euros. Ca permet dans un premier temps de tester la fraude. Le client n'est pas débiter mais donne une autorisation de prélèvement

2- Une fois que ta commande est prête à être expédiée, tu peux valider le paiement sur une interface mise à disposition par la banque : dans ce cas, le logiciel revérifie la validité de la carte, le plafond, ... Le paiement peut être accepté ou refusé.

<{POST_SNAPBACK}>

merci pour ta réponse.

Une précision : est ce que dans ce cas, tu connais le numéro de carte du client pour repasser la transaction manuellement ou bien est ce que c'est la banque qui conserve ce numéro ? Et dans ce cas, combien de temps le conserve t-elle ? N'est ce pas justement dans la limite des 7 jours légaux ?

[blman]

C'est la banque qui conserve la transaction. Elle te donne un id de transaction et tu n'a jamais accès aux coordonnées bancaires de ton client. Toutes les manipulations se font grâce à l'id de transaction.

Au niveau du temps entre le paiement sur le site et la validation manuelle, c'est toi qui le configure aussi (le maximum étant de 90 jours je crois, peut-être un peu plus)

[Bourinho]

Bonjour,

Je souhaitais savoir combien la banque prenait si jamais la commande ne faisait finalement pas...parce que j'imagine qu'il doit y avoir un cout!!! On parle de banques là...si elles commencent à offrir des services gratuits, ou va t'on?

Par avance, merci!

[blman]

Je crois que ça ne coute rien de plus. Pas de différence pour eux entre le mode VALIDATION ou AUTHOR_CAPTURE.

Par contre, je viens de vérifier dans la doc, la valeur capture_day peut varier de 0 à 99 donc le délais maximum pour valider un paiement est de 99 jours

[Guest Asgarel]

Par contre, je viens de vérifier dans la doc, la valeur capture_day peut varier de 0 à 99 donc le délais maximum pour valider un paiement est de 99 jours

<{POST_SNAPBACK}>

C'est sur que cette solution me conviendrait bien. Je suis justement au crédit agricole, mais mon conseiller ne m'a pas du tout parlé de cette solution. Quand je lui est posé la question précisemment, il s'est renseigné au siège, et sa réponse fut : impossible, on ne peut pas faire ce genre de choses....

Est ce qu'il s'agit d'un contrat standard qu'il suffit ensuite de paramétrer ? Peux tu me donner les références precises de cette option pour que je sache quoi lui demander exactement (module VALIDATION ?) ?

[Bourinho]

Je crois que ça ne coute rien de plus. Pas de différence pour eux entre le mode VALIDATION ou AUTHOR_CAPTURE.

[/quote

Ca ne coute rien de plus, donc ca te coute ce que ca t'aurait couté si tu avais encaissé... Donc tu paies une comission pour rien quand même...C'est bien ça?

[blman]

Asgarel, il s'agit bien d'un contrat standard. Voici ce que dit la doc :

5. La capture différée

Lenvoi en banque dune transaction, également appelé capture ou remise dune transaction, peut être défini à laide de deux paramètres : capture_mode et capture_day. Le champ capture_mode précise le mode denvoi en banque, tandis que le champ capture_day indique le délai avant lenvoi en banque.

Le champ capture_mode peut prendre les valeurs AUTHOR_CAPTURE ou VALIDATION, tandis que le champ capture_day peut varier de 0 à 99. Dès lors que le capture_day est non nul, on parle de capture différée car lenvoi en banque ne se fait pas le même jour que la création de la transaction.

Si les champs capture_mode et capture_day ne sont pas renseignés au niveau de lAPI, ils sont respectivement initialisés par le serveur à AUTHOR_CAPTURE et 0 pour signifier une capture immédiate après lacceptation du paiement.

Le choix du mode VALIDATION ou AUTHOR_CAPTURE dépend du souhait du commerçant de contrôler ou non lenvoi en banque des transactions.

5.1. Mode AUTHOR_CAPTURE

Dans ce mode, les transactions sont automatiquement envoyées en banque par le serveur E-Transactions, aucune action nest nécessaire au commerçant. Cependant, si le commerçant souhaite annuler tout ou partie de la transaction avant lenvoi en banque, il peut le faire à laide du module office.

Par exemple, si le champ capture_mode est vide et le champ capture_day a la valeur 6, le serveur de paiement E-Transactions fait une demande dautorisation en ligne du montant réel lors de la transaction. Cette dernière est ensuite envoyée en banque à jour + 6.

5.2. Mode VALIDATION

Les transactions ne sont envoyées en banque quaprès la validation du commerçant. La validation dune transaction se fait à laide du module office. Si une transaction nest pas validée dans le délai fixé par le capture_day, elle expire. La transaction est alors perdue.

Par exemple, si le champ capture_mode est à VALIDATION et le champ capture_day a la valeur 6, le serveur de paiement E-Transactions fait une demande dautorisation en ligne du montant réel lors de la transaction. Le commerçant à capture_day jours pour valider la transaction. La transaction est envoyée en banque le jour de la validation.

[Guest Asgarel]

Merci pour ces précisions blman.

J'espère maintenant que c'est bien le même principe dans toutes les régions (je suis au CA sud Rhones Alpes)...

[blman]

Hé bien, en fait, je pense que oui. E-transaction fonctionne sous le logiciel ATOS donc tous les logiciels qui fonctionnent sous ATOS doivent fonctionner pareil, peut importe la région ou la banque.