[ic] Re: payment module authorizenet (modifications)

[Philip S. Hempel]

On Fri, 2003-05-23 at 17:09, John Young wrote:
> Philip S. Hempel wrote:
> 
> > I am using 4.9.7 daily
> > 
> > I am working on the authorizenet payment module and I am running into a
> > few glitches. 
> > 
> > I added to the module support for using the transid as per one of the
> > messages in the mailing list. This worked out great no problems.
> > 
> > OK, I want to add cvv2 support and that seemed to be  as simple as doing
> > a remap.
> > 
> > I placed mv_credit_card_cvv2 and a form on the checkout and that worked
> > fine. I do an order and the encrypted card that is emailed get the cvv2
> > number.
> > Ok for the remap I placed the 
> > x_Card_Code => $actual->{mv_credit_card_cvv2}
> > 
> > x_Card_Code does not map. 
> > 
> > So I do some digging and I decide to try something different, I put in
> > my checkout "my_card_code" and replace all of the above with this
> > variable. I then put in Payment.pm the my_card_code and then test.
> > 
> > Changing the above works for some reason. 
> > I also notice that mv_order_number is not remapped. I am thinking that
> > this has something to do with the same problem.
> > 
> > I am far from knowing perl so most of the things going on in the module
> > I do not understand.
> > 
> > I think I understand how cvv2 works, the "mv_credit_card_cvv2" gets
> > mapped by IC into "cvv2" in the Order.pm. The cvv2 then is used by
> > Payment.pm to be processed by whatever payment type it is. 
> > 
> > My confusion comes when I use any other variable and add it to
> > Payment.pm it works just fine. 
> > 
> > What am I seeing or doing that is incorrect? 
> > Also I have been trying to find the "'Payment Settings' heading in the
> > Interchange documentation" to learn something about the remapping of
> > these variables.
> 
> You shouldn't have to modify Payment.pm.  If you are modifying
> AuthorizeNet.pm anyway (which it needs) consider adding x_cvv2_resp_code
> to %result_map (between lines 400-450) as shown:

Thanks for the code, will say me some time!

I knew changing Payment.pm was wrong. I changed it to do some checking
on a few hunches I had. I was correct in saying that somewhere the
variables are being cleared since putting *my own* variables in, and
having them pass, worked.

> 
>               pop.avs_code          x_avs_code
>               pop.avs_zip           x_zip
>               pop.avs_addr          x_address
> +            pop.cvv2_resp_code    x_cvv2_resp_code
>       /
>       );
> 
> And then a few lines after that in the @result:
> 
>                          x_avs_code
>                          x_trans_id
> +                       x_cvv2_resp_code
>                  /
>                  }
> Quite a few things could be added to @result (x_invoice_num
> through x_md5_hash).  I'm looking at code from 1.5 months ago.
> AuthorizeNet.pm had some changes applied by Jon a day or two ago,
> so I might be a little off.
> 
> You could also check the response:
>      if ($result{x_cvv2_resp_code} eq 'N') {
>         my $msg = $opt->{message_cvv2} ||
>            q{Blah, blah, blah  The bank returned the following error: %s};
>         $result{MErrMsg} = errmsg($msg, $result{x_response_reason_text});
>      } elsif ($result{x_cvv2_resp_code} eq 'P') {
>      ...etc.
> 

Thanks for the response code for the cvv2. The response code stuff was
next on my list (you know, doing things in baby steps) once I could get
past the variable not being set. It just seems something is clearing
these two variables, mv_credit_card_cvv2 / cvv2 and mv_order_number (and
there could be more). 


> Version needs to be 3.1 (I'm guessing you've already done that)
>     x_Version       => '3.1',
> 

Yup, first thing I did, they said that cvv2 is only supported in 3.1

> x_ADC_Delim_Character might need changing (not for CVV2, but for expanded
> use).  If so, that requires coordination with your AuthorizeNet account
> settings modification of the split for @result.
> 
> It sounds like you are really close to having it working.  It's not
> too tough to do.  You can always turn on debugging and add something like:
> ::logDebug(qq{authorizenet 
> response_reason_text=$result{x_response_reason_text} response_code: 
> result{x_response_code} avs_code=$result{x_avs_code} 
> cvv2_resp_code=$result{x_cvv2_resp_code}});

I have been running the module in debug mode for a while now. I haven't
posted up the logs, should have mentioned at least that the results was
the same as stated by Dwayne Holmberg earlier

'x_Card_Code' => undef; from Authorizenet.pm

and

'cvv2' => undef; from Payment.pm


Once this is done I would like to see that it could be committed to the
archive. I surely do not want to have to keep patching this all the
time. I would think others would benefit from the additions as well. 

I also am looking at (once I get done with this section) adding e-checks
as well. I know one other person mentioned needing (wanting) e-check
support. I hope once I understand this part that adding the e-check
support will be trivial.

Thanks very much for your help.

It is great to know I can ask for help here. I just *hate* it when I
can't find something or did not know what to look for on the site or
list and find myself asking questions here. I feel a much greater sense
of accomplishment when I have figured it out on my own.

Nite all

-- 
Philip S. Hempel

Give a man a fish and he will feed himself for a day.
Teach a man to fish and he will feed himself for a lifetime.

http://linuxhardcore.com/