Hi guys Firstly awesome work Stephen! Mezzanine & Cartridge are exactly what I was looking for.
Have you guys made any progress on the merging the cart and order? I am also in the process of implementing an external payment via direct POST, and also need the order id before payment is completed. Regards On Saturday, December 13, 2014 at 4:21:58 AM UTC+2, Stephen McDonald wrote: > > The idea around merging carts and orders into one makes sense in all the > ways you discussed - let's try that and see where it goes. > > Thanks a lot Alex. > > On Wed, Dec 10, 2014 at 7:17 PM, Alexander Hill <[email protected] > <javascript:>> wrote: >> >> Lots of good points there. >> >> I suppose I have unconsciously been thinking about this from the >> perspective of someone who needs to take payments via external POST, and >> also happens to want the unfinished orders hanging around as well. So >> cleaning up and hiding the unfinished orders didn't occur to me. >> >> I agree that this change doesn't warrant all of that, and I would be >> happy with an easier way to make this configurable. One easy thing we could >> change would be to make sure Cartridge's OrderForm works nicely if passed >> an instance. I have no idea how far this is from being the case currently >> (missing argument to __init__ aside). I'll have a play with this shortly. >> >> >> Hmmm... >> >> Another somewhat (!) more invasive idea is to unify orders and carts. I >> think that could actually simplify Cartridge quite a lot, as there's a lot >> of code marshalling data between sessions, carts and orders currently. Let >> every order begin as a cart, and simply add data to it as the user >> progresses through the checkout and payment steps. The status field would >> indicate how far the order has come – cart, checkout, payment, complete, >> processed. >> >> We would be able to clean out old unfinished orders for free – we already >> do that with carts. As a bonus, we'd also get user-based carts for free, >> since carts/orders would have the user_id field set. We would satisfy the >> use cases mentioned in this thread, and simplify the code and schema. >> >> Big change I know, but what do you reckon? >> >> Cheers, >> Alex >> >> >> On Wed, Dec 10, 2014 at 2:05 PM, Stephen McDonald <[email protected] >> <javascript:>> wrote: >> >>> 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] >>> <javascript:>> 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] >>>> <javascript:>> 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] >>>>> <javascript:>> 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] >>>>>> <javascript:>> 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] >>>>>>> <javascript:>> 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] <javascript:>. >>>>>>>> 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] <javascript:>. >>>>>>> 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] <javascript:>. >>>>>> 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] <javascript:>. >>>>> 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] <javascript:>. >>>> 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] <javascript:>. >>> 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] <javascript:>. >> 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.
