[ic] Authorizenet payment module (modifications)

[Philip S. Hempel]

On Thu, 2003-06-05 at 15:59, John Young wrote:
> Philip S. Hempel wrote:
> > It seems to put a comma in between the two and authorizenet make use of it to split
> > see the output from the logs later.
> > 
> >>      if($actual{b_address1}) {
> >>          $actual{b_address} = "$actual{b_address1}";
> >>          $actual{b_address} .=  ", $actual{b_address2}"
> >>              if $actual{b_address2};
> >>      }
> 
> Yes, I wasn't paying attention to that earlier.  The code above
> sorta turns into a bug if you just add all the extra return fields
> and do nothing else.  I don't think it is a big problem if you
> use an alternate delimiter without field encapsulation, though.
> 
> I *would have* said that for the Interchange distribution, the code above
> from Payment.pm should not have the "," added during concatenation;
> however, there is nothing to stop a customer from adding a comma in
> their address (unless you filter it out) -- so the risk remains.
> 
> For now, I vote for the solution following the next quote:
> 
> 
> > This is the output that is sent back from a submission using the : (colon) as a delim.
> > It is required to have a field sperator, using the comma default is what I have
> > chosen. The field encapsulation chararacter is optionial if wanting to use the
> > extended (cvv2 and others) information then it would be required.
> 
> 
> Why not use "|" as the delimiter and no field encapsulation?  That
> strategy should (I think) only entail the following:

This works perfect, never did I think about the second line issue with
IC actually placing the comma in between the two address lines.

I see this at least does what I am looking for, and am able to parse the
data correctly. 
> 
> * Change AuthorizeNet preferences to use "|" (on AuthorizeNet web site)
> * Change AuthorizeNet.pm to use:
>           = split (/\|/,$page);
>      instead of:
>           = split (/,/,$page);
>      for @result{}.

This I did for encap and never worked I did not think to use this as the
main character for the fields, works very well
THANKS!

> * Filter "|" out of form input (if it isn't already).
> 
> If "|" isn't good, one could use "~" for a pseudo X12 EDI feel ;-)
> 
> 
> Fiddling with field encapsulation just seems like a bunch of extra work
> to me ('cause you would still have to alter ANet settings, etc.).  I
> don't believe it buys you anything.  Don't be too hard on yourself --
> the steps above should work and are pretty simple.
> 
> 
> Good luck,
> John Young

I am off to get the rest of the error codes put into the module. I
already have the fields from IC mapped in for standard E-Checks, I am
not sure where to even start with getting IC to use live verification
for E-Checks (I hope it already will, but not my luck).

I started with doing a check for credit_card and online_check and that
seems to pass for credit cards (realize this is a great feat for me
since I know very little about perl!)

I will hope someone will audit this thing for me once I am done and make
sure that I have not done anything stupid with it.

Thanks very much for your help, the simple little stuff is what always
messes me up.

-- 
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/