Now that the foundation of the ordering process is in place, orders can have different statuses, and Notification Center 2 is integrated, I’m still grappling with an almost philosophical problem: Ordered or not ordered, that is the question.
According to the button solution, the final step in the ordering process is usually called Buy. After clicking this button, customers are redirected to the payment provider. In Isotope, orders were previously only saved if the payment was successful, even though a legally binding purchase agreement had already been made. If the payment was canceled, the order was discarded, and even shop owners couldn’t track which orders hadn’t been completed.
I’m currently considering whether Isotope should stay this way or what an alternative might look like. For the (new) system, it would be simpler if an order were just there as soon as the button is clicked (or rather, when it’s created via PHP). It would also create the opportunity to follow up with customers regarding uncompleted orders and likely close some additional sales. Whether this is done manually or automated at some point is a sepearate question.
However, there are also some potential problems: if many customers abandon the payment process, this results in many abandoned orders in the backend. This probably means unnecessary extra work for owners, especially those running small shops. Even an order confirmation email (to the owner) doesn’t automatically mean that a product can be shipped. That was already the case before when offering prepayment, but not with credit cards. If the email is sent only after payment, you would no longer know what was ordered (and not paid).
Another issue is the order number in Isotope. Some of you may know that in the backend, you see both the database ID and the order number. This is mainly because the order number isn’t generated until payment is completed—and thus can’t be transmitted to third-party systems (e.g., PayPal) as a reference number. Those systems require the database ID, which is rather inconvenient. If the number were available before payment is completed, it could be used everywhere. But this results in sequential numbering being generated for unpaid (and possibly later canceled) orders. If accounting requires sequential document numbering, you would also have to book failed orders in your accounting software.
One possible solution would be to generate a number for the order and, for example, an invoice number for an invoice. The latter, of course, only upon payment. That would actually be correct—but Isotope currently does not support documents associated with an order or anything similar. This is a concept that would first need to be developed and implemented.
What do you think about this? Feel free to let me know in a comment.
