[ic] authorizenet failure increments counter?

[Mark Johnson]

Bob Puff wrote:
> Hi Gang,
> 
> Just saw something strange tonight on a catalog running under 5.2. 
> There was a gap in the order numbers.

[snip]

> Obviously, someone entered a bad CC number, and it told them so.  But
> why did it increment the order number counter?  I thought this only
> happened on successful orders.

At some point between 4.8 and now, the charge routine was moved out of
the order profile and into the order route. I'm quite certain the
purpose of this was so that the order number would be available to the
charge request as identifying data (the context in which this came up
most often was for Verisign where it is highly desirable to include the
order number in one of the COMMENT fields to ease reconciliation). The
difference is, as you've noted, order numbers get "used" on failed
attempts. The problem is there's no ironclad way to "roll back"
increments (even RDBMS systems recognize this as sequence values are
never rolled back as part of a failed transaction).

If you do not include the order number with the CC transaction, you can
move the charge routine back into the profile. That allows charges to
fail before assigning an order number to the process. I personally
prefer this configuration because gaps in your order sequence indicate a
real problem, and not part of normal operation. I try to set up the
order process so there is no legitimate possible failure for the routes
and, when I do find gaps in order numbers, can use that to isolate where
unanticipated problems occurred.

> Also, should it have thrown off an error on Order.pm?

Not sure specifically what you're asking here, but route error handling
is configurable. You can specify that a route is error_ok, in which case
it simply moves on to the next route on failure, or if it's not it
aborts the process as you've described from the error log and takes the
user back to (I believe) mv_nextpage.

Mark

--
Mark Johnson
End Point Corporation
http://www.endpoint.com