Mailing List Archive

Little more follow-up:

Nothing shows up in the standard logs out of the ordinary stuff that shows on
a decline:

50.0.0.0 MnDiqWia:50.0.0.0 - [07/May/2015:05:41:59 -0700] deli
/cgi-bin/deli/ord/finalize.html Safe: Real-time charge failed. Reason:
Authorizenet error: This transaction has been declined. Please call in your
order or try again.
>
>
> die errmsg(
> "Real-time charge failed. Reason: %s\n",
> errmsg($Session->{cybercash_error}),
> );

I did enable debug, and I see this in the debug log:

Can't locate package DBI::common for @DBI::db::ISA at
/usr/local/lib/perl5/site_perl/5.10.1/x86_64-linux/DBD/mysql.pm line 232.
Can't locate package DBI::common for @DBI::db::ISA at
/usr/local/lib/perl5/site_perl/5.10.1/x86_64-linux/DBD/mysql.pm line 232.
Argument "" isn't numeric in numeric ge (>=) at (eval 912) line 5.

The DBI package is indeed installed.

Bob


_______________________________________________
interchange-users mailing list
interchange-users@icdevgroup.org
http://www.icdevgroup.org/mailman/listinfo/interchange-users

Is there no one that can offer advice on a place to start looking to fix this one?

> Greetings,

> I have a catalog running on IC 5.8.2 using the AuthorizeNet gateway that
> apparently has had a long-time problem that we just discovered:

> When a user goes to check out and enters a bad credit card number, it is
> properly declined (with the correct error message). However, the shipping
> amount displayed goes to 0. If they then put in a correct card number, the
> order goes thru with 0 shipping. If, however, after getting the error, you
> click on the RECALCULATE button under the cart contents, the shipping charges
> will then show properly.

> This only seems to happen on a AuthorizeNet fail - if I put in a bogus CC
> number that fails the luhn check, it does work properly.

> Where do I look for this one?

Bob

_______________________________________________
interchange-users mailing list
interchange-users@icdevgroup.org
http://www.icdevgroup.org/mailman/listinfo/interchange-users

> Is there no one that can offer advice on a place to start looking to fix
this one?

>> Greetings,

>> I have a catalog running on IC 5.8.2 using the AuthorizeNet gateway
>> that apparently has had a long-time problem that we just discovered:

>> When a user goes to check out and enters a bad credit card number, it
>> is properly declined (with the correct error message). However, the
>> shipping amount displayed goes to 0. If they then put in a correct
>> card number, the order goes thru with 0 shipping. If, however, after
>> getting the error, you click on the RECALCULATE button under the cart
>> contents, the shipping charges will then show properly.

>> This only seems to happen on a AuthorizeNet fail - if I put in a bogus
>> CC number that fails the luhn check, it does work properly.

>> Where do I look for this one?

The luhn check I believe is done in Interchange already: lib/Vend/Order.pm
has some routines for this.
So that validation is done before calls are made to AuthorizeNet ...

My assumption (without knowing your flow) is that the luhn check just brings
you back to your checkout page after the POST request and rendering the page
again ... But your AuthorizeNet failure maybe results in a redirect, which
is set to your checkout page. And this is losing some of your data. Are you
doing something 'special' for (re)calculating shipping rates? Maybe storing
it in a scratch/tmp parameter .. Which it picks up when it rerenders after a
'local' luhn check, but not after a 'redirect' from AuthorizeNet?

> Bob

_______________________________________________
interchange-users mailing list
interchange-users@icdevgroup.org
http://www.icdevgroup.org/mailman/listinfo/interchange-users


_______________________________________________
interchange-users mailing list
interchange-users@icdevgroup.org
http://www.icdevgroup.org/mailman/listinfo/interchange-users

Thanks for the reply, Gert!

> My assumption (without knowing your flow) is that the luhn check
> just brings you back to your checkout page after the POST request
> and rendering the page again ... But your AuthorizeNet failure maybe
> results in a redirect, which is set to your checkout page. And this
> is losing some of your data. Are you doing something 'special' for
> (re)calculating shipping rates? Maybe storing it in a scratch/tmp
> parameter .. Which it picks up when it rerenders after a 'local'
> luhn check, but not after a 'redirect' from AuthorizeNet?

The cart is based off an earlier version "demo" store, and the only thing
different from the stock code in the checkout stuff that I recall is the
shipping calculation inside the shipping.asc file.

I am using version 5.8.2, and I *think* I even set up a test catalog with the
most recent version's demo, plugged in the authorizenet stuff, and saw it
happen on that one as well.

Since it does come back properly after a recalculate, does that mean there is
a scratch variable that gets updated with a recalc? Is there a way I can set
the code so that it does a recalc when it comes back with an error?

Bob

_______________________________________________
interchange-users mailing list
interchange-users@icdevgroup.org
http://www.icdevgroup.org/mailman/listinfo/interchange-users

Quoting Bob Puff (bob@nleaudio.com):
> Thanks for the reply, Gert!
>
> > My assumption (without knowing your flow) is that the luhn check
> > just brings you back to your checkout page after the POST request
> > and rendering the page again ... But your AuthorizeNet failure maybe
> > results in a redirect, which is set to your checkout page. And this
> > is losing some of your data. Are you doing something 'special' for
> > (re)calculating shipping rates? Maybe storing it in a scratch/tmp
> > parameter .. Which it picks up when it rerenders after a 'local'
> > luhn check, but not after a 'redirect' from AuthorizeNet?
>
> The cart is based off an earlier version "demo" store, and the only thing
> different from the stock code in the checkout stuff that I recall is the
> shipping calculation inside the shipping.asc file.
>
> I am using version 5.8.2, and I *think* I even set up a test catalog with the
> most recent version's demo, plugged in the authorizenet stuff, and saw it
> happen on that one as well.

It's possible there is a problem in the standard demo store. I would bet
that it has to do with the one-page checkout.

The standard demo store hasn't received any attention in years. It is
woefully out-of-date. Instead, my suggestion would be Perusion's "strap"
demo, which you can find here:

http://www.perusion.com/demos.html

You will notice that there are no problems with shipping and checkout
failures on the demo store here:
http://demo.perusion.com/i/strap

Feel free to grab the checkout flow and use in your store.

--
Josh Lavin
Perusion -- Expert Interchange Consulting http://www.perusion.com/
... ask me about job opportunities ...

_______________________________________________
interchange-users mailing list
interchange-users@icdevgroup.org
http://www.icdevgroup.org/mailman/listinfo/interchange-users

> The standard demo store hasn't received any attention in years. It is
> woefully out-of-date. Instead, my suggestion would be Perusion's "strap"
> demo, which you can find here:
>
> http://www.perusion.com/demos.html
>
> You will notice that there are no problems with shipping and checkout
> failures on the demo store here:
> http://demo.perusion.com/i/strap
>
> Feel free to grab the checkout flow and use in your store.
>
> --
> Josh Lavin

Hi Josh,

Great suggestion, I'll give it a go. That might also fix some other little
gremlins I was having. I assume this will fully pass a PCI compliance test,
yes? My old catalog apparently allows SQL injections, and it is in places
that are just stock code.

Bob

_______________________________________________
interchange-users mailing list
interchange-users@icdevgroup.org
http://www.icdevgroup.org/mailman/listinfo/interchange-users

Quoting Bob Puff (bob@nleaudio.com):
>
> > The standard demo store hasn't received any attention in years. It is
> > woefully out-of-date. Instead, my suggestion would be Perusion's "strap"
> > demo, which you can find here:
> >
> > http://www.perusion.com/demos.html
> >
> > You will notice that there are no problems with shipping and checkout
> > failures on the demo store here:
> > http://demo.perusion.com/i/strap
> >
> > Feel free to grab the checkout flow and use in your store.
> >
> > --
> > Josh Lavin
>
> Hi Josh,
>
> Great suggestion, I'll give it a go. That might also fix some other little
> gremlins I was having. I assume this will fully pass a PCI compliance test,
> yes? My old catalog apparently allows SQL injections, and it is in places
> that are just stock code.

Hi Bob,

We're not aware of any issues, and we've used it in several places. That
said, there could be things we've missed.

--
Josh Lavin
Perusion -- Expert Interchange Consulting http://www.perusion.com/
... ask me about job opportunities ...

_______________________________________________
interchange-users mailing list
interchange-users@icdevgroup.org
http://www.icdevgroup.org/mailman/listinfo/interchange-users