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.
