Generating random, unique invoice number

[LucidSurf]

Hi guys,

I have developed an ecommerce system and would like to give people a nice, tidy reference number when they have signed up.

At the moment the reference number is created using a combination of today's date and then a string representing their domain name - but I don't think this is very user friendly or tidy!

$ref = echo date("Ymd") . stripslashes($website); 

This produces something like: 20070613www.lucidsurf.com

I was thinking, maybe it would be better to convert their domain name into numbers (serialise it?) so that the reference is all numeric - but am not sure of the best approach.

Any suggestions would be much appreciated.

[c.norris]

Maybe you can use the time instead of date and thea actual invoice number, such as if its your first order it will be 12021 (using 24 hrs time) that looks good I think.

[kromey]

I've also favored YYYYMMDDHHMMSS# for this kind of application, where # is a counter (just in case you're issuing more than one per second; add more digits if you're doing more than 10 per second). For example, the first 3 invoices issued at this very moment would be
200706131631490
200706131631491
200706131631492

You could easily break this up to make it easier on your users:
20070613-163149-0
Or even:
2007-0613-163149-0

[Dan Grossman]

Why not give them their actual order number from your ecommerce system's database? Why do you want to create some second artificial identifier?

[c.norris]

I guess so that a customer doesn't think that the website is new.

What , I am order number #1???

[Dan Grossman]

I guess so that a customer doesn't think that the website is new.

What , I am order number #1???

Then start numbering at 1000

[c.norris]

Lol, I wouldn't be afraid to start with 1. Email : ~Congradulations, you are our first order.

[Dan Grossman]

Lol, I wouldn't be afraid to start with 1. Email : ~Congradulations, you are our first order.

I started one of my ecommerce sites at 1 in 2004. It's now in the 30,000's. Those first customers didn't mind at all

[kromey]

I like starting with 1234. It's just a fun little number

[LucidSurf]

Thanks everyone.

Hi Dan, I actually have to generate the reference number before submitting the transaction to my payment gateway. The system I have only enters orders into the database if they are successfully processed, so I really need to create a transaction id at the start of the process.

I guess I could query the database and get the last successful transaction id and then + 1 to it before submitting to the payment gateway.

Although, I'm thinking that for a quick solution Kromey's idea would work pretty well.

[c.norris]

I wouldn't mind being the first order, here is a scenario. Lets say they mess up big time and their order is hmmn, tehre doing date and time so 2106130607 the customer is going to say, I wonder if anyone else of the 2,106,130,607 people they serviced has had this same problem :-X

[c.norris]

order_number++;

[kromey]

I guess I could query the database and get the last successful transaction id and then + 1 to it before submitting to the payment gateway.

Careful about that - you could conceivably end up submitting the same transaction ID twice if two people place orders simultaneously.

I would add to the database, setting a flag to say "not yet processed", then use the database-generated ID as their transaction ID (maybe after adding, say, 1234 to it ).

[Dan Grossman]

Hi Dan, I actually have to generate the reference number before submitting the transaction to my payment gateway. The system I have only enters orders into the database if they are successfully processed, so I really need to create a transaction id at the start of the process.

Why do you need to give someone a reference number before they've finished checking out and paying?

I would add to the database, setting a flag to say "not yet processed", then use the database-generated ID as their transaction ID (maybe after adding, say, 1234 to it ).

When a customer on one of my sites finishes shopping, has gone through the first half of checkout, and reaches the payment stage, that's when I convert their cart into an order entry in the database. I have payment information associated with an order (is it paid? what method? reference info? when?) and not having that information means the order isn't paid for.

It's necessary to record orders in the database before payment if you intend to accept PayPal. You might get away with not doing so with other 3rd party processors if they guarantee returning the user to your site after paying, but with PayPal, payment might actually occur way out in the future -- 2 weeks sometimes for an eCheck payment -- so you definitely have to record the order first and update its payment status later.