Re: [mezzanine-users] Direct POST payments in Cartridge

[cognisantsoftware]

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  > 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 > > 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 >> > 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  wrote:

> There was a lengthy mailing list discussion on this years ago where 
> everyone agreed that there shouldn't be 

Re: [mezzanine-users] Direct POST payments in Cartridge

[Alexander Hill]

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 st...@jupo.org 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 a...@hill.net.au 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 st...@jupo.org
 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 a...@hill.net.au
 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 

Re: [mezzanine-users] Direct POST payments in Cartridge

[Josh Cartmell]

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.

Re: [mezzanine-users] Direct POST payments in Cartridge

[Alexander Hill]

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 joshcar...@gmail.com 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 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.


-- 
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.

Re: [mezzanine-users] Direct POST payments in Cartridge

[Stephen McDonald]

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 a...@hill.net.au 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 joshcar...@gmail.com 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 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.

  --
 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.




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

Re: [mezzanine-users] Direct POST payments in Cartridge

[Alexander Hill]

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 st...@jupo.org 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 a...@hill.net.au 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 joshcar...@gmail.com 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 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.

  --
 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.




 --
 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 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.

[mezzanine-users] Direct POST payments in Cartridge

[Alexander Hill]

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.