[ic] AuthorizeNet.pm missing fields
Pann McCuaig
interchange-users@interchange.redhat.com
Tue Oct 2 14:30:01 2001
On Tue, Oct 02, 2001 at 11:10, mheins@redhat.com wrote:
> Quoting Pann McCuaig (pann@ourmanpann.com):
> > In my ongoing battle to pass all the values to Authorize.net that it
> > will return to me via email, I've got the billing and shipping info
> > working. However, these values are not coming back:
> >
> > x_Tax => $actual->{salestax},
> > x_Freight => $actual->{shipping},
> >
> > both shipping and salestax are mapped in Payment.pm, are defined in
> > checkout.html before the "Place Order" button is selected, and show up
> > on the interchange-generated emails.
>
> What makes you think [value salestax] and [value shipping] hold what you
> want? Where is it documented that you can expect that?
>
> In short, they don't; [salestax] is not the same as [value salestax].
> You would have to explicitly set them to what you want.
A reasonable question. One which I'll answer at some length in the hope
that it may provide food for thought for those who write documentation
for interchange (and I know you've done most of that, to date).
Interchange is big:
1695269 Sep 22 13:52 interchange-4.8.2.tar.gz
4422926 Sep 22 13:55 interchange-doc-4.8.2.tar.gz
We who try to use this (very nice) package have to pick and choose what
we read.
I'd guess that most of us new to the interchange world use one of the
provided demos as a template. I think it's wonderful that you provide
those templates. My first exposure to this world was minivend several
years ago. I hacked on the art store demo and got a functional store
running.
If you look at the store operated by Jim Balcom, a frequent contributor
to this list, you'll see an extensive store with lotsa features, but it
jumps right out at you that it's based on the construct demo.
On the other hand, if you look at the korksoft.com website run by Jason
Korkin, another frequent contributor to this list, you'll see that it
doesn't look like any of the demos, but watching the URLs that appear in
the Location: textbox will soon convince you that it is running either
minivend or interchange (Jason's been doing this a long time).
Not too long ago a real client with a real brick-and-mortar business
decided to upgrade his web business. He wanted to run an online store
based on interchange, and he wanted to use Authorize.net as his CC
gateway. Thus was I re-introduced to interchange after a hiatus of
several years.
Everything went reasonably well until I needed to get Authorize.net
working. I asked some questions on this list, and got useful replies,
primarily from you, Mike. And I consider the reply you made to my last
question useful, because it got me to read somewhere else.
But the question was prompted because I had gone to the source,
.../lib/Vend/Payment/AuthorizeNet.pm, to try and find the source of my
difficulty, because that has worked for me before.
Let's talk about this little snippet:
# x_Company => $actual->{company},
# x_Phone => $actaul->{phone_day},
x_Email => $actual->{email},
x_Phone => $actaul->{phone_day},
I noticed that x_Company and x_Phone were commented out, although
x_Phone appears uncommented a couple of lines later. I also noticed the
creative spelling of 'actual'. Correcting that spelling and bouncing
interchange resulted in the field corresponding to x_Phone showing up on
the email I receive from Authorize.net.
Let me interject here that I have another non-interchange site that has
been using Authorize.net successfully for more than a year. It's using
PERL code that I wrote from scratch, so I have some familiarity with the
Anet API.
The second thing I noticed was that uncommenting the x_Company line and
bouncing interchange did _not_ cause the corresponding field to show up
in the email I received from Anet.
Further investigation showed this code snippet in
.../interchange/lib/Vend/Payment.pm:
my @map = qw(
address
address1
address2
amount
b_address
b_address1
b_address2
b_city
b_country
b_fname
b_lname
b_name
b_state
b_zip
check_account
check_accttype
check_checktype
check_dl
check_magstripe
check_number
check_routing
check_transit
city
comment1
comment2
corpcard_type
country
cvv2
email
fname
item_code
item_desc
lname
mv_credit_card_exp_month
mv_credit_card_exp_year
mv_credit_card_number
name
origin_zip
phone_day
phone_night
pin
po_number
salestax
shipping
state
tax_duty
tax_exempt
tender
zip
);
You'll notice that 'company' is not on this list. Adding it to the list
and bouncing interchange caused the corresponding field to show up on
the email I received from Anet.
So I continued my investigation. I decided that the line
x_Address => $actual->{address},
should reference 'b_address' instead of 'address' since that is what
Anet is interested in. For those of you even less informed than I, those
tokens with 'b_' prepended are from the "Billing Address" portion of
the Account Info form and those without are from the Shipping Address
portion. If no separate Billing Address is entered, the obvious is done.
Now I was rockin' and rollin'. Noting that all the tokens for both
Billing Address and Shipping Address were in @map in Payment.pm, I
just went ahead and added a few lines in AuthorizeNet.pm, so that the
relevant snippet is:
x_First_Name => $actual->{b_fname},
x_Last_Name => $actual->{b_lname},
x_Company => $actual->{b_company},
x_Address => $actual->{b_address},
x_City => $actual->{b_city},
x_State => $actual->{b_state},
x_Zip => $actual->{b_zip},
x_Country => $actual->{b_country},
x_Email => $actual->{email},
x_Phone => $actual->{phone_day},
x_Ship_To_First_Name => $actual->{fname},
x_Ship_To_Last_Name => $actual->{lname},
x_Ship_To_Company => $actual->{company},
x_Ship_To_Address => $actual->{address},
x_Ship_To_City => $actual->{city},
x_Ship_To_State => $actual->{state},
x_Ship_To_Zip => $actual->{zip},
x_Ship_To_Country => $actual->{country},
I bounced interchange, entered another order with different billing and
shipping addresses, and Voila!, the email from Anet reflected all my
changes.
Mike, here is where I answer your question:
Having noticed that the 'salestax' and 'shipping' tokens are in @map
in Payment.pm, and having verified that [salestax] and [shipping] are
used in .../pages/ord/checkout.html, I went ahead an added a couple of
lines to AuthorizeNet.pm that I thought would get those values emailed
to me with the same ease I had slain the other dragons. When this didn't
work, I posted the email that has ultimately resulted in this lengthy
response.
Only after reading Mike's response did I go back to checkout.html and
note the difference between, say, [salestax] and [value b_fname].
I made what seemed to me to be a reasonable inference based on the
tokens in @map in Payment.pm and the structure of the Anet query in
AuthorizeNet.pm. It turned out not to be reasonable, and as soon as I
post this I'll start trying to figure out the cleanest way to get what I
want.
I'm reasonably sure that many folks using this list are also
using Authorize.net as a credit card gateway. If they're doing it
successfully, then either they've solved some of the problems I've
alluded to herein, or the missing fields on the Anet emails are not
important to them. If they've solved the problems, then I believe
they're remiss in not posting those solutions to this list. If they
don't care, then, no problem.
But there is no documentation _anywhere_ (save archives of this list)
that I could find that has anything to say about using Authorize.net:
$ grep -ilr authorize interchange-doc-4.8.2/*
$
# grep -ilr authorize /usr/local/interchange/doc/*
#
So we've got to do the best we can by searching list archives and the
source code:
# grep -ilr authorize /usr/local/interchange/lib/
/usr/local/interchange/lib/Vend/Payment/Skipjack.pm
/usr/local/interchange/lib/Vend/Payment/CyberCash.pm
/usr/local/interchange/lib/Vend/Payment/Signio.pm
/usr/local/interchange/lib/Vend/Payment/CCVS.pm
/usr/local/interchange/lib/Vend/Payment/AuthorizeNet.pm
/usr/local/interchange/lib/Vend/Server.pm
/usr/local/interchange/lib/Vend/Parse.pm
/usr/local/interchange/lib/Vend/Util.pm
/usr/local/interchange/lib/Business/UPS.pm
/usr/local/interchange/lib/UI/Primitive.pm
/usr/local/interchange/lib/UI/ichelp.txt
/usr/local/interchange/lib/UI/locales/da_DK.cfg
/usr/local/interchange/lib/UI/locales/de_DE.cfg
/usr/local/interchange/lib/UI/locales/nl_NL.cfg
/usr/local/interchange/lib/UI/locales/sv_SE.cfg
/usr/local/interchange/lib/UI/pages/admin/add_meta_option.html
/usr/local/interchange/lib/UI/pages/admin/customer.html
/usr/local/interchange/lib/UI/pages/admin/customer_select.html
/usr/local/interchange/lib/UI/pages/admin/group.html
/usr/local/interchange/lib/UI/pages/admin/layout.html
/usr/local/interchange/lib/UI/pages/admin/order.html
/usr/local/interchange/lib/UI/pages/admin/order_status.html
/usr/local/interchange/lib/UI/pages/admin/reconfig.html
/usr/local/interchange/lib/UI/pages/admin/regen.html
/usr/local/interchange/lib/UI/pages/admin/report.html
/usr/local/interchange/lib/UI/pages/admin/report_results.html
/usr/local/interchange/lib/UI/pages/admin/search_wizard_results.html
/usr/local/interchange/lib/UI/pages/admin/special/key_violation.html
/usr/local/interchange/lib/UI/pages/admin/spread.html
/usr/local/interchange/lib/UI/pages/admin/tablereport.html
/usr/local/interchange/lib/UI/pages/admin/upload_file.html
/usr/local/interchange/lib/UI/pages/admin/wizard/step_pay.html
/usr/local/interchange/lib/UI/pages/admin/wizard/step_pay_auth.html
/usr/local/interchange/lib/UI/pages/admin/wizard/step_pay_itransact.html
/usr/local/interchange/lib/UI/pages/admin/wizard/step_pay_skipjack.html
/usr/local/interchange/lib/UI/profiles/db_maintenance
#
If you've gotten this far, thanks for reading.
Cheers,
Pann
--
geek by nature, Linux by choice L I N U X .~.
The Choice /V\
http://www.ourmanpann.com/linux/ of a GNU /( )\
Generation ^^-^^