• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
RE: What's a good way to handle orders?
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: What's a good way to handle orders?


  • Subject: RE: What's a good way to handle orders?
  • From: "James C. Lee" <email@hidden>
  • Date: Sun, 6 Jan 2008 15:51:19 -0800
  • Importance: Normal

Bad orders are just the way things are. You will always end up with bad
orders. You will get failed credit card authorizations, even if the user
completes the order.

A philanthropic project we run has tons of bad orders...bad credit cards, no
payments, etc. And yes, those bad orders just live in the database:

http://www.gi-bracelet.org

Orders should not take up too much disk space. And if you want to, you could
always schedule jobs to clean up bad orders. We just leave them to rot. :-)

^James


> -----Original Message-----
> From:
> webobjects-dev-bounces+jcl_applewodev=email@hidden
> ple.com
> [mailto:webobjects-dev-bounces+jcl_applewodev=dreamissary.com@
> lists.apple.com] On Behalf Of Kevin Windham
> Sent: Sunday, January 06, 2008 3:27 PM
> To: WO Dev-Apple
> Subject: Re: What's a good way to handle orders?
>
>
>
> On Jan 6, 2008, at 5:20 PM, James C. Lee wrote:
>
> > Kevin,
> >
> > How about add a numeric column "status" to the Order table, with
> > values such
> > as:
> >
> > 0 = newly order
> > 1 = got credit card info, ready for authorization
> > 2 = authorization successful, ready to pack
> > 3 = authorization failed
> > 4 = packed, ready to charge credit card
> > 5 = credit card charged
> > ...
> > 11 = paypal payment received
> > etc.
>
> I thought about doing a status, but then I could still end up with
> orders that are cluttering up the db for no good reason. A person
> really on the fence could go in several times and create the same
> order on different days before finally deciding to purchase. Then I
> would have to go back and search out "bad" orders and clean it up.
>
> I think it will be best to not have the order go into the db until
> payment is made, just not sure what the best way to do that is. I'm
> leaning toward duplicate objects and then clone the temp
> objects into
> the freshly created db inserted objects upon payment.
>
> Kevin
>  _______________________________________________
> Do not post admin requests to the list. They will be ignored.
> Webobjects-dev mailing list      (email@hidden)
> Help/Unsubscribe/Update your Subscription:
email@hidden

This email sent to email@hidden

 _______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list      (email@hidden)
Help/Unsubscribe/Update your Subscription:

This email sent to email@hidden

  • Follow-Ups:
    • Re: What's a good way to handle orders?
      • From: Guido Neitzer <email@hidden>
References: 
 >Re: What's a good way to handle orders? (From: Kevin Windham <email@hidden>)

  • Prev by Date: Re: Ajax demo
  • Next by Date: Re: What's a good way to handle orders?
  • Previous by thread: Re: What's a good way to handle orders?
  • Next by thread: Re: What's a good way to handle orders?
  • Index(es):
    • Date
    • Thread