l i n u x - u s e r s - g r o u p - o f - d a v i s
L U G O D
 
Next Meeting:
April 21: Google Glass
Next Installfest:
TBD
Latest News:
Mar. 18: Google Glass at LUGOD's April meeting
Page last updated:
2003 Apr 26 06:09

The following is an archive of a post made to our 'vox-tech mailing list' by one of its subscribers.

Report this post as spam:

(Enter your email address)
Re: [vox-tech] Sales/Shipping/Payment without Transactions.
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



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
_______________________________________________
vox-tech mailing list
vox-tech@lists.lugod.org
http://lists.lugod.org/mailman/listinfo/vox-tech



LinkedIn
LUGOD Group on LinkedIn
Sign up for LUGOD event announcements
Your email address:
facebook
LUGOD Group on Facebook
'Like' LUGOD on Facebook:

Hosting provided by:
Sunset Systems
Sunset Systems offers preconfigured Linux systems, remote system administration and custom software development.

LUGOD: Linux Users' Group of Davis
PO Box 2082, Davis, CA 95617
Contact Us

LUGOD is a 501(c)7 non-profit organization
based in Davis, California
and serving the Sacramento area.
"Linux" is a trademark of Linus Torvalds.

Sponsored in part by:
Appahost Applications
For a significant contribution towards our projector, and a generous donation to allow us to continue meeting at the Davis Library.