gert at 3edge
Aug 10, 2009, 12:33 PM
Post #2 of 12
(1138 views)
Permalink
|
> -----Original Message-----
> From: interchange-users-bounces [at] icdevgroup [mailto:interchange-
> users-bounces [at] icdevgroup] On Behalf Of Glenn McCalley
> Sent: Monday, August 10, 2009 8:36 PM
> To: interchange-users [at] icdevgroup
> Subject: [ic] custom payment module
>
> Here's the situation:
>
> We've got several stores running Interchange V5.2.0 It does the job!
> Been
> using it for years.
>
> A new client (big one, of course) wants us to process the charges for
> their
> store through their own credit card system that they already use for
> contributions. They also want us to pass order item detail to them in
> an
> XML type structure so they can maintain their own merged database when
> people have both made a contribution and a store purchase. The
> sequence
> would be
> - we take the order using the IC checkout page
> -- send the charge/item info to our client
> -- get their response on the charge
> - we show the customer receipt.
>
> They have provided a Perl routine that works, meaning I can run it from
> the
> command line with a $1.00 amount and the charge gets processed by them
> OK.
>
> SO!
> How do you turn this into a payment module? I've perused the
> Payment.pm and
> Payment module directory and am having trouble seeing how they
> interact, how
> it gets called, where the "OK" or "refused" is returned to the checkout
> process, etc. It looks like things get mapped/translated into things
> which
> get mapped/translated into other things where they get mapped once
> again,
> and somehow somewhere an "OK" signal is returned. Is there a HowTo or
> a
> reference on this somewhere?
The HowTo I did:
- copy one of the existing payment modules
- bash it , smack it, whack it, tweak it, until it says 'transaction OK' and
the (pre) authorization ended up in the banks cc transaction backoffice ...
You probably need to figure out some stuff, such as:
- what is the protocol used to communicate with the payment system (often
https)
- are there authentication key/values (username/password/secrect keys) that
you need to set up the transaction, the you usually stick
In your catalog.cfg (see the one from standard for example:
Route authorizenet id "__MV_PAYMENT_ID__"
Route authorizenet secret "__MV_PAYMENT_SECRET__"
Route authorizenet host "__MV_PAYMENT_HOST__"
Route authorizenet referer "__MV_PAYMENT_REFERER__"
- do you build a xml document to send (like I had to do), or you send some
key/value pairs?
- what do they return after your request?
This you will have to extract from your existing perl module ...
If I remember correctly once you do a request like this in your
OwnPaymentModule.pm:
my $thing = post_data($opt, \%query);
The \%query contains whatever you have to tell the cc processing end
$thing will contain the answer in one form or another ...
Then you parse that and extract the main information in a hash with keys
like:
MStatus (success,denied)
MErrMsg (could put in an error message provided from the cc company or
some other 'oopsies failed' message)
order-id the ID for your succesfull order ..
You probably have to look for the %type_map hash as that contains a mapping
for transaction types ... might need some tweaking.
And then in Payment.pm you have the 'sub charge' which is where I believe
things are going down, looking down until :
# This is the return from all routines
my %result;
there is where then the OwnPaymentModule.pm comes to play ...
Perhaps a simple approach could be to set up OwnPaymentModule.pm and at the
point where it has 'post_data()' you just call that existing Perl script,
retrieve the response from that script and set the MStatus/MErrMsg/order-id
..
Oh and then in the standard store, the whole payment process starts from
etc/log_transaction and I believe etc/receipt holds the content of the page
shown after successful order processing ... there you can show the
ordernumber I think with [value mv_order_number]
So (unless someone will correct me, quite likely as all is done by head):
- checkout page, creditcard details added (standard fields
mv_credit_card_xxx)
- click checkout - field validation checks, then goes to etc/log_transaction
(depending on how your routes are set up)
- in log_transaction you have somewhere something like: [charge route="[var
MV_PAYMENT_MODE]"] where MV_PAYMENT_MODE is the your modulename, without
.pm
- that charge is calling Payment.pm which used your module...
- if all goes well it updates your database and anything else you want it to
do and uses etc/receipt.html to show the notice that the order has been
processed ...
Anyway good luck and let us know how you have sorted it in the end!
CU,
Gert
_______________________________________________
interchange-users mailing list
interchange-users [at] icdevgroup
http://www.icdevgroup.org/mailman/listinfo/interchange-users
|
