Paiement électronique chez Crédit Mutuel / CIC
Yann KLIS
Je dois mettre en place un module de paiement électronique pour me
connecter à la banque Crédit Mutuel / CIC. Celles-ci fournissent un
kit pour PHP, Java (et même python), mais évidemment pas pour Ruby /
Rails.
Pour se connecter aux serveurs, en gros, il faut calculer une somme de
contrôle Hmac SHA1 à l'aide d'une clé fournie. Mais je n'arrive
absolument pas à faire fonctionner le tout en Ruby (pourtant il existe
ce qu'il faut dans le monde Ruby, grâce notamment à OpenSSL).
Est-ce que quelqu'un a déjà mis un tel moyen de paiement électronique
avec Rails et aurait des conseils à me donner ?
Merci d'avance,
yk
Jean-Christophe Michel
Le 8 mai 07, à 17:37, Yann KLIS a écrit :
> Je dois mettre en place un module de paiement électronique pour me
> connecter à la banque Crédit Mutuel / CIC. Celles-ci fournissent un
> kit pour PHP, Java (et même python), mais évidemment pas pour Ruby /
> Rails.
Pas directement une réponse à ta question... mais :
quelle base as-tu utilisé ? pourrait-on mettre en commun une base de
code pour implémenter les paiements et rendre le passage de l'un à
l'autre plus simple ?
Je vais pour ma part implémenter celui de la Banque Populaire de
Lorraine.
As-tu pensé à appeler un script en shell depuis ruby pour le calcul de
ta clé ?
L'analyse du script php ne te permet-elle pas de porter leur algorithme
?
Jean-Christophe Michel
--
Symétrie, édition de musique et services multimédia
30 rue Jean-Baptiste Say
69001 LYON (FRANCE)
tél +33 (0)478 29 52 14
fax +33 (0)478 30 01 11
web www.symetrie.com
Yann KLIS
Le 09/05/07, Jean-Christophe Michel<jc.m...@symetrie.com> a écrit :
>
>
> Le 8 mai 07, à 17:37, Yann KLIS a écrit :
> > Je dois mettre en place un module de paiement électronique pour me
> > connecter à la banque Crédit Mutuel / CIC. Celles-ci fournissent un
> > kit pour PHP, Java (et même python), mais évidemment pas pour Ruby /
> > Rails.
>
> Pas directement une réponse à ta question... mais :
> quelle base as-tu utilisé ? pourrait-on mettre en commun une base de
> code pour implémenter les paiements et rendre le passage de l'un à
> l'autre plus simple ?
> Je vais pour ma part implémenter celui de la Banque Populaire de
> Lorraine.
>
> As-tu pensé à appeler un script en shell depuis ruby pour le calcul de
> ta clé ?
> L'analyse du script php ne te permet-elle pas de porter leur algorithme
> ?
En fait, je suis partie de leur documentation technique pour
implémenter ce qu'il fallait. Simplement, cette documentation
simplifie grandement les choses. En réalité, il faut effectivement se
référer au code source fourni.
Par exemple, je suis parti du code source PHP fourni pour implémenter
ma propre solution. Au final c'est assez simple, mais il fallait
saisir les petites subtilités.
Il faut que je vois si je peux rendre ce code source public.
++
yk
philippe lachaise
Yann KLIS
que t'as utilisé voire même de divulguer des informations sur le
process.
Dans le cas du Crédit Mutuel, tout est sous licence libre (et ils
insistent bien là-dessus). Par contre, je me demande juste comment
communiquer le source sans que ça ait des implications juridiques pour
ma pomme (si tant est que ça puisse être le cas).
++
yk
Le 09/05/07, philippe lachaise<philippe...@gmail.com> a écrit :
Jérémy Dierx
Le code source qu'ils te fournissent n'est sûrement pas le code source de leur programme CGI mais des exemples de codes (php, perl,...) pour pouvoir communiquer avec leur programme CGI.
Le programme CGI de chiffrage qui t'a été fournit lui est compilé et son code source n'est pas accessible (d'ailleurs, il n'y a aucun intérêt à relire ce code source, excepté pour corrigé un bug :-P)
quel système de paiement te propose le CM : paybox, atos, ... ?
++
J.
|
------------------------------------------------------------------------ Pickabee Communication Visuelle & Multimédia 6 rue Jacques de la Roque - 13100 Aix-en-Provence Tél. 04 42 96 98 13 - 06 32 60 31 86 http://www.pickabee.com |
Sébastien Gruhier
// EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
// MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
// NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
HOLDERS BE
// LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN
ACTION
// OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION
// WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
Ca devrait le faire :)
Yann KLIS
Toutes les infos sont là : http://commerce.e-i.com/news/ (tout le monde peut télécharger leur "kit de connexion").
En gros, voici comment cela fonctionne. Le Crédit Mutuel fournit un clé privé. Pour faire un paiement électronique via leur banque il "suffit" d'envoyer toutes les infos par un POST d'un formulaire ainsi qu'un hash de contrôle (HMAC SHA1) grâce à la clé fournie.
Ils fournissent des exemples d'implémentation de leur algorithme en PHP, Python, Java, C++, VB (voir sur http://commerce.e-i.com/news/).
++
yk
c0rwin
J'ai développé le module de paiement Cybermut (avec clef SHA1) en ruby/
rails pour ma société en me basant sur le kit de dev de la banque.
Ceux que ça intéresse peuvent prendre contact avec moi par mail.
++
Harold.
On May 10, 9:36 am, "Yann KLIS" <yann.k...@gmail.com> wrote:
> C'est leur propre système de paiement.
>
> Toutes les infos sont là :http://commerce.e-i.com/news/(tout le monde peut
> télécharger leur "kit de connexion").
>
> En gros, voici comment cela fonctionne. Le Crédit Mutuel fournit un clé
> privé. Pour faire un paiement électronique via leur banque il "suffit"
> d'envoyer toutes les infos par un POST d'un formulaire ainsi qu'un hash de
> contrôle (HMAC SHA1) grâce à la clé fournie.
> Ils fournissent des exemples d'implémentation de leur algorithme en PHP,
> Python, Java, C++, VB (voir surhttp://commerce.e-i.com/news/).
>
> ++
>
> yk
>
> Le 10/05/07, Jérémy Dierx <jeremy.di...@pickabee.com> a écrit :
Yann KLIS
Voici donc le code que j'ai pondu pour me connecter aux serveurs de
paiement électronique du Crédit Mutuel / CIC :
http://strasslab.net/blog/index.php?2007/05/10/247-petit-intermede-technique
++
yk
Le 10/05/07, Sébastien Gruhier<sgru...@gmail.com> a écrit :
Jean-François
> Voici donc le code que j'ai pondu pour me connecter aux serveurs de
> paiement électronique du Crédit Mutuel / CIC :
>
> http://strasslab.net/blog/index.php?2007/05/10/247-petit-intermede-technique
Merci pour le code.
Mes premières remarques, parfois cosmétiques :
- Dans la méthode show, il y a :
@data = @tpe + "*" + @date + "*" + @montant + "*" + @reference +
"*" + @texte_libre + "*" + @version + "*" + @lgue + "*" + @societe + "*"
j'aurais tendance à préférer :
@data = "#{@tpe}*#{@date}*#{@montant}*#{@reference}*#{@texte_libre}*#{version}*#{lgue}*#{societe}*"
(car on crée moins d'objets String, au détriment de la lisibilité)
ou dans ce cas-ci :
@data = [ @tpe, @date, @montant, @reference, @texte_libre,
@version, @lgue, @societe ].join("*") + "*"
De plus @data ne sert pas dans la vue, donc une variable locale
suffit non ? data
- Dans la méthode confirm :
Il y a deux fois : @mac = params[:MAC]
et écrire @mac = params[:MAC].downcase
... permet d'avoir une conditionnelle plus claire je trouve :
if @mac == hmac(@data)
- S'il y a un render :text à la fin de la méthode #confirm,
pourquoi avoir des variables d'instance @tpe, @date...
alors que des variables locales suffisent ?
- à quoi sert @result ?
- je ne suis pas trop adepte du +=
@data += "..."
pour moi, écrire @data << "..." économise un objet String
- Dans le render :text il y a un Time.now.strftime("%d/%m/%Y:%H:%M:%S")
visiblement le même que dans #show, tu gagnerais à le
factoriser, pour n'avoir qu'un seul endroit pour modifier
le format de la date, si modification ultérieure il y a.
- enfin si le formulaire a toujours la même forme, on peut
peut-être en faire un helper ?
et dans la vue on aurait un :
<%= cybermut_form(:tpe => @tpe, :reference => @reference, ...) %>
un truc dans ce genre.
Voilà pour l'instant, j'ai pas encore lu le pdf dans le Kit, mais
ça a l'air assez intéressant tout ça.
-- Jean-François.
--
À la renverse.
philippe lachaise
Jean-François
> >> - Dans la méthode show, il y a ...
>
> Ha ha ! Serait-ce la naissance d'un nouveau projet ? :-)
Ouais, j'étais en train d'envisager ça... avec une api propre
et des tests.
Mais j'ai à peine étudié les specs...
philippe lachaise
Jérémy Dierx
>> Ouais, j'étais en train d'envisager ça...
Ca revient assez souvent sur la ML, il aura surement pas mal de monde intéressé.
Yann KLIS
le code sans vraiment nettoyer). Dès que j'ai trouvé un endroit un peu
plus approprié que mon blog pour publier ce code (en intégrant tes
remarques), je refais signe.
++
yk
Le 10/05/07, Jean-François<jf....@gmail.com> a écrit :
philippe lachaise
Philippe.
Cyril Mougel
Je conseillerais plutôt de mettre le projet sur RubyForge. Car ca
permettra même si un gem est fait de l'ajouter directement dans la
base de donnée rubygems de RubyForge.
Rubyforge fournit tout ce qui est nécessaire pour développer un projet
en Ruby. C'est vrai que c'est un poil moins performant au niveau suivi
du svn que trac. Mais c'est déjà pas mal.
--
Cyril Mougel
Jonathan Tron
wrote:
> Je vais pour ma part implémenter celui de la Banque Populaire de
> Lorraine.
J'ai un bout de code pour la BPLC, utilisé depuis 1an a peu près sans
problème.
Dans environment.rb :
# Configuration du paiement BPLC
# URL à appeler
PAIEMENT_BPLC_URL_CONTACT = "https://ecom.cimetz.com/telepaie/
cgishell.exe/epaie01"
# Champs d'identification du marchand
PAIEMENT_BPLC = { :CHAMP000 => '000000', # Numéro
abonné internet
:CHAMP001 => '0000', # Code
activité commerçant (MCC)
:CHAMP002 => '0000000000', # Numéro de
contrat (numéro commerçant)
:CHAMP003 => 'I', # Type de
paiement (I = Immédiat, D = Différé)
:CHAMP900 => '01' # Adhérent
(toujours passer 01)
Dans lib/bplc_paiement.rb :
require "erb"
class BplcPaiement
attr_accessor :uri,
:champs,
:client,
:commande
###
# Class de gestion des échanges avec le serveur de paiement de la
bplc
#
# Paramètres :
# cl : Objet Client correspondant au client souhaitant payer
# co : Objet Commande correspondant à la commande du client à
payer
# informations_paiement : Hash contenant les données de
configuration du paiement
###
def initialize(cl, co, informations_paiement)
@uri = PAIEMENT_BPLC_URL_CONTACT
@champs = { # Commerçant
:CHAMP000 => '.', # Numéro aboné internet
:CHAMP001 => '.', # Code activité commerçant (MCC)
:CHAMP002 => '.', # Numéro de contrat (numéro
commerçant)
:CHAMP003 => 'D', # Type de paiement (I = Immédiat,
D = Différé)
:CHAMP004 => '.', # Nom du serveur commerçant
(informatif)
:CHAMP005 => '.', # Adresse du script appelé après
paiement (RSTS = backend, STD = page confirmation)
:CHAMP006 => '.', # Nom du commerçant (informatif)
:CHAMP007 => '.', # Adresse de retour 2 chez le
commerçant (RSTS = confirmation, STD = inutile)
:CHAMP008 => '.', # Email de confirmation du
commerçant
:CHAMP010 => '.', # Timer de redirection
automatique (si CHAMP007)
# Client
:CHAMP100 => '.', # Nom
:CHAMP101 => '.', # Prénom
:CHAMP102 => '.', # Société
:CHAMP103 => '.', # Téléphone
:CHAMP104 => '.', # Adresse email
:CHAMP106 => '.', # Fax
:CHAMP107 => '.', # Adresse (numéro et rue)
:CHAMP108 => '.', # Ville
:CHAMP109 => '.', # Code Postal
:CHAMP110 => '.', # Code Pays (informatif, aucune
norme spéciale)
# Commande
:CHAMP200 => '.', # Référence de la commande
(stocké pour éviter les doublons de paiement 15 chiffres significatif)
:CHAMP201 => '.', # Montant (symbole décimal est la
virgule)
:CHAMP202 => 'EUR', # Devise (accépté : EUR)
# Divers
:CHAMP900 => '01' # Adhérent (toujours passé 01)
}.merge(informations_paiement)
@client = cl
@commande = co
end
###
# Retourne une url formatée pour être passée au script de la bplc
#
# Console => @cl = Client.find(:first, :order => "id desc"); @co =
@cl.commandes.first; @bplc = BplcPaiement.new(@cl, @co,
PAIEMENT_BPLC_TEST)
###
def get_url
url = uri.dup
# Configuration Commerçant
champs[:CHAMP004] = "http://www.monsite.com"
champs[:CHAMP005] = "http://monsite.com/backend_shopping/
valider_paiement/#{commande.reference}?CHAMPBPX"
champs[:CHAMP006] = "Ma Société SARL"
champs[:CHAMP007] = "http://monsite.com/confirmation_commande/
#{commande.reference}"
champs[:CHAMP008] = "cyberp...@monsite.com"
champs[:CHAMP010] = "5"
# Configuration infos Client
champs[:CHAMP100] = "#{client.nom}"
champs[:CHAMP101] = "#{client.prenom}"
champs[:CHAMP103] = "#{client.adresse.telephone}" unless
client.adresse.telephone.empty?
champs[:CHAMP104] = "#{client.email}"
champs[:CHAMP107] = "#{client.adresse.rue}"
champs[:CHAMP108] = "#{client.adresse.ville}"
champs[:CHAMP109] = "#{client.adresse.codepostal}"
# Configuration des infos de la commande
champs[:CHAMP107] = "#{commande.reference}"
champs[:CHAMP201] = "#{commande.prix_total.to_s.gsub('.',',')}"
url += '?' + champs.collect { |key, val|
"#{key}=#{ERB::Util::h(ERB::Util::u(val))}" }.join('&')
url
end
end
Une fois l'instance de BplcPaiement créée (@bplc), il suffit de
proposer un lien vers le site de paiement de la bplc
<%= link_to 'Accéder au site sécurisé de paiement', @bplc.get_url %>
ou de rediriger automatiquement dessus.
Bon c'est ici ultra couplé avec l'application qui l'utilise, mais le
seul intéret de cette classe étant finalement de correctement encoder
les champs dans l'url, c'est pas bien difficile à adapter.
En espérant que ça serve à quelqu'un.
Jean-Christophe Michel
Le 14 mai 07, à 21:34, Jonathan Tron a écrit :
> J'ai un bout de code pour la BPLC, utilisé depuis 1an a peu près sans
> problème.
Et le calcul de la clé de retour pour vérification ?
J'ai ça en php, je vais le porter et l'ajouter.
Jean-Christophe Michel
--
symetrie.com
Better Nested Set for rails:
http://opensource.symetrie.com/trac/better_nested_set
philippe lachaise
Jean-Christophe Michel
Le 15 mai 07, à 09:01, philippe lachaise a écrit :
> Et bien en tout cas ça bouge le payement électRo(R)nique :-)
>
> Sur Rubyforge ou ailleurs ça vaut le coup d'en faire un projet.
Certes. Un plugin serait le mieux.
Pourrait-on décider collectivement d'une api préférable et si possible,
commune pour différents paiements ?
(quitte à passer un hash qui lui serait différent suivant le service)
Ou bien s'aligne-t-on sur un plugin anglo-états-unien ?
philippe lachaise
Comme je continue à croire que vos initiatives e-payment vont intéresser beaucoup de gens, je joins le geste à la parole :
Il y a un trac+svn tout neuf dédié à l'hébergement et à la documentation de vos codes.
Le site (https://epay.pizzaonrails.org/) est protégé pour éviter de se transformer en online-pharmacy, je suis à votre disposition pour créer les comptes pour tous ceux qui le désirent.
Merci à Loïc Guitaut qui à si rapidement mis en place les outils sur la dedibox.
Philippe.