[vox-tech] Sales/Shipping/Payment without Transactions.

[Micah J. Cowan]

On Fri, Apr 25, 2003 at 09:09:02PM -0400, Mike Simons wrote:
> On Fri, Apr 25, 2003 at 09:26:44AM -0700, Micah J. Cowan wrote:
> > Answer the question: what would you do to avoid having either an
> > order in the DB marked to be shipped without payment, or payment for
> > an order which didn't get into your DB?
> 
>   I will attempt to give an example, I'm not saying this is the only 
> way to do this without transactions.  This may be a bit long winded.

<snip>

> Race Condition 1:
> ====
>   Credit card company issued a authorization, but the authorization
> number is not stored.
> 
>   Since the payment status never changes to 'approved', order status
> never moves to 'pending', and items are not shipped.
>   Even though a credit card authorization is issued I expect the customer
> is not billed.  I have not dealt with credit card transactions before, but 
> here is why I suspect that this is fine.
> 
>   In my mind the authorization step just puts a short term hold on the
> funds, the item_selling_company must *bill* the credit card company
> with authorization number to actually collect money.  This is why some
> transactions clear on one's credit card statement days away from when
> the store receipt says.

Typically for e-commerce, authorized transactions are *automatically*
processed at the end of the day by the credit card processing company,
unless specifically cancelled (this is the case for IonGate, and I
believe for AuthorizeNet). Sometimes, they are stored in batch and
require explicit authorization, but this is usually not correlated
with other data and involves a simple "Process current batch"
button-click. It is often not an easy thing to check each authorized
transaction against the orders in a DB to ensure that the order really
is marked for shipping. And, in the case of automatic batch processing
at end-of-day, it is somewhat unsafe.

<snip>

>   I think a system like the one above would be very easy to track down
> problems in, at each important step a log is made.

The point I was trying to make about commit/rollback is that there are
no problems to track down in the first place: it either succeeded or
didn't; no DB record is ever in a "halfway" point. In my experience,
it is a very dangerous thing for a system's reliability to hang on the
diligence of the human administrator to check for problems.

I would of course have utmost confidence in your diligence, but if
something happened to you and I was forced to bring someone else in,
I'd start getting nervous. ;)

-Micah