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
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
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
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 :
------------------------------------------------------------------------ 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 |
Ca devrait le faire :)
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 :
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 :
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.
Ouais, j'étais en train d'envisager ça... avec une api propre
et des tests.
Mais j'ai à peine étudié les specs...
>> Ouais, j'étais en train d'envisager ça...
Ca revient assez souvent sur la ML, il aura surement pas mal de monde intéressé.
++
yk
Le 10/05/07, Jean-François<jf....@gmail.com> a écrit :
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
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.
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
> 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 ?