There was a lengthy mailing list discussion on this years ago where everyone agreed that there shouldn't be unfinished orders floating around in the database.
I still agree with that and I'm not particularly keen on the idea of having to maintain this as an option and feature. Cartridge is intentionally very simple and limited compared to the alternatives, I'd rather keep it that way. BTW I naively assumed that Cartridge dealt with credit card handling well enough from a PCI-DSS perspective - the card number doesn't get stored anywhere and is only posted from one checkout step form to the next. On Wed, Dec 10, 2014 at 1:03 PM, Alexander Hill <[email protected]> wrote: > Hi Josh, > > I'm interested to hear from Steve too. Since Cartridge was initially > written to call payment processors from the server, only creating the > orders after payment was submitted makes sense it makes sense – doing so > earlier does introduce a bit of extra complexity. Keeping the cart in sync > with the order if the customer gets up to the payment step and then adds > items, for example. > > I remember reading through cartridge-payments a couple of years back. I'm > a bit wary of side-effects in forms (like saving the order object). That > said, it's a clever way of getting it done without any custom view code, > which is what I'm doing. I might copy it :) > > Am I missing something or is the added callback_uuid field not strictly > necessary? The order number should uniquely identify the payment anyway. > > Cheers, > Alex > On Dec 10, 2014 12:45 AM, "Josh Cartmell" <[email protected]> wrote: > >> I like the idea of having an order ID before payment (for the reasons you >> outlined) but I'd be curious to hear if Steve had any particular reason for >> not doing this when he originally created Cartridge. >> >> Also, in case you haven't seen it you might want to look at >> https://github.com/explodes/cartridge-payments >> >> On Mon, Dec 8, 2014 at 9:39 PM, Alexander Hill <[email protected]> wrote: >> >>> Hi all, >>> >>> I don't want credit card details touching our server for PCI-DSS reasons >>> and have a no-Javascript constraint, so I use direct POST with our payment >>> processor. In my project I create an Order instance before the payment page >>> is displayed, so that I'm able to pass the correct order number to my >>> payment processor. >>> >>> I remember seeing a similar workaround in someone else's payment >>> processing code a long time ago so I assume this kind of thing might be >>> useful to more than just me. It's quite messy to bolt on aftermarket, so I >>> propose integrating it into Cartridge, probably toggled by a new setting, >>> SHOP_CREATE_ORDER_BEFORE_PAYMENT or similar. >>> >>> This change also has the helpful side-effect of allowing one to query >>> incomplete orders – I have a job that sends a daily email summary of >>> incomplete orders to sales staff, for example. >>> >>> Thoughts? >>> >>> Alex >>> >>> -- >>> You received this message because you are subscribed to the Google >>> Groups "Mezzanine Users" group. >>> To unsubscribe from this group and stop receiving emails from it, send >>> an email to [email protected]. >>> For more options, visit https://groups.google.com/d/optout. >>> >> >> -- >> You received this message because you are subscribed to the Google Groups >> "Mezzanine Users" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to [email protected]. >> For more options, visit https://groups.google.com/d/optout. >> > -- > You received this message because you are subscribed to the Google Groups > "Mezzanine Users" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > For more options, visit https://groups.google.com/d/optout. > -- Stephen McDonald http://jupo.org -- You received this message because you are subscribed to the Google Groups "Mezzanine Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
