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 <a...@hill.net.au> 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 mezzanine-users+unsubscr...@googlegroups.com. > 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 mezzanine-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
