I don't know, which means I guess I'm not set. I understand the desire for it, but I've always felt it's important with Mezzanine and Cartridge to reject certain features, even when they'd be useful to someone, especially when they start to compromise the original intent of how things have been designed.
So I suppose If it could be implemented simply enough with a setting, then sure - but what does it really entail? It would need some documentation around it, describing why unfinished orders get left floating around, and how they could possibly be cleaned up. It'd even best be up to Cartridge to provide the management command that does that, and notes in the documentation on how it can be used as a cron job. The SHOP_ORDER_STATUS_CHOICES will need something like an "Unfinished" status as well. Then the admin will need support too - if unfinished orders remain in the db, it really makes no sense for them to appear by default. You can see one seemingly small option controlled by a setting really does have a flow-on effect throughout the project, which is a major part of why I don't want it. Is this really not something that can be implemented by doing away with the final checkout step views of Cartridge, and just using something custom? Actually a better question might be - how can we make this configurable somehow, without actually implementing "order objects get created before payment" feature? Could we not break the checkout form (which I recall as being swappable via a setting) up into enough overridable methods, that control the behaviour, similar to how a lot of class based views work? On Wed, Dec 10, 2014 at 4:45 PM, Alexander Hill <[email protected]> wrote: > My understanding is that if CC details touch your server, even in memory, > you need to be compliant. The official PCI body says "The DSS globally > applies to *all* entities that store, process or transmit cardholder > data" at https://www.pcisecuritystandards.org/pdfs/pci_ssc_quick_guide.pdf > > I agree that Cartridge's simplicity is a strength, but I don't feel that > adding this feature will compromise that. Are you pretty set on this, or is > it worth me making a branch and seeing if it can be done without > complicating things too much? > > Cheers > Alex > > On Wed, Dec 10, 2014 at 10:11 AM, Stephen McDonald <[email protected]> wrote: > >> 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. >> > > -- > 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.
