You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@ofbiz.apache.org by Tim Ruppert <ti...@hotwaxmedia.com> on 2009/10/22 18:11:05 UTC
Re: Question about authorize.net and PCI compliance [ was on the dev list as Re: Clearing credit card data after capture ]
I hope this thread helps Scott.
Cheers,
Ruppert
--
Tim Ruppert
HotWax Media
http://www.hotwaxmedia.com
o:801.649.6594
f:801.649.6595
Begin forwarded message:
> From: Scott Gray <sc...@hotwaxmedia.com>
> Date: June 5, 2009 5:12:47 AM MDT
> To: dev@ofbiz.apache.org
> Subject: Re: Clearing credit card data after capture
> Reply-To: dev@ofbiz.apache.org
>
> Cool thanks, I'll look into it.
>
> Regards
> Scott
>
> On 5/06/2009, at 11:10 PM, David E Jones wrote:
>
>>
>> The more common recurring stuff in OFBiz right now is recurring
>> orders using an auto-order shopping list. You could certainly check
>> those before whacking the CC# and that would handle it.
>>
>> -David
>>
>>
>> On Jun 5, 2009, at 4:58 AM, Scott Gray wrote:
>>
>>> Thanks David, ProductStore it is.
>>>
>>> About the recurring billing I was hoping there would be someway to
>>> check if the cc is being used for it and to leave the information
>>> in place. That way we'd only be clearing unused cc data. I'm
>>> going to need to check for any pending transactions/payment prefs
>>> before clearing the data anyway, would that check be sufficient to
>>> pick up on recurring payments do you think?
>>>
>>> Regards
>>> Scott
>>>
>>> On 5/06/2009, at 9:54 PM, David E Jones wrote:
>>>
>>>>
>>>> On Jun 4, 2009, at 11:59 PM, Scott Gray wrote:
>>>>
>>>>> Hi All,
>>>>>
>>>>> I plan to add a configuration option to clear credit card data
>>>>> once there are no more auths pending against it. When I say
>>>>> clear the data I mean remove the expiry date and credit card
>>>>> number except for the last 4 digits.
>>>>>
>>>>> Any thoughts on where this should be configurable/how it should
>>>>> be implemented? I think the card clearing logic may have to be
>>>>> specific to the gateway being used, e.g. authorize.net needs you
>>>>> to keep the last 4 digits for refunds but others may not.
>>>>> I'm thinking perhaps I could add a new product store payment
>>>>> service type enumeration record, something like
>>>>> PRDS_PAY_CLEAR_DATA and the defined service would run after the
>>>>> capture and release services.
>>>>
>>>> That sounds pretty complex, and I'm wondering if the complexity
>>>> is needed. I guess to really answer more research would be
>>>> required, or maybe not. Keeping the last 4 digits should be
>>>> pretty safe, although these days I suppose that could be valuable
>>>> information for a hacker since for authentication over the phone
>>>> banks and others generally just ask for the last 4 digits of your
>>>> government ID#, the last 4 of your CC#, etc.
>>>>
>>>> Anyway, it would be more consistent and more simple to just have
>>>> a setting on the ProductStore, and perhaps one with 3 options:
>>>> keep CC #s, keep only last 4 digits of CC #s, don't keep CC #s.
>>>>
>>>>> Recurring billing is the other thing I'm not sure about, I guess
>>>>> I'd need to leave the card data alone in that case but I've
>>>>> never worked with recurring payments so I'm not sure how I would
>>>>> detect if the card is being used for them.
>>>>
>>>> If an organization wants to avoid keeping CC #s then it will
>>>> certainly limit certain otherwise automated things. Recurring
>>>> orders or recurring billing would be something that is not
>>>> possible, unless a third party payment provider is used that
>>>> keeps the CC #. This is actually one of the very appealing things
>>>> about services like PayPal or GoogleCheckout where the ecommerce
>>>> site doesn't ever even accept payment information.
>>>>
>>>> In fact, for anyone who wants a feature like (ie remove CC
>>>> numbers after use), they might consider using a third party
>>>> payment site instead of the more transparent option of handling
>>>> it through their application.
>>>>
>>>> -David
>>>>
>>>
>>
>
Re: Question about authorize.net and PCI compliance [ was on the dev list as Re: Clearing credit card data after capture ]
Posted by Tim Ruppert <ti...@hotwaxmedia.com>.
Ok - great - thanks Scott - I'm sure the other Scott will thank you.
Cheers,
Ruppert
--
Tim Ruppert
HotWax Media
http://www.hotwaxmedia.com
o:801.649.6594
f:801.649.6595
On Oct 22, 2009, at 1:19 PM, Scott Gray wrote:
> It actually never made it back into the trunk, the differences
> between the trunk and revision I was working on were too large for a
> simple merge and I was quite strapped for time.
>
> Thanks for the reminder though, I'll definitely look at putting this
> in there within the next weekend or two.
>
> Regards
> Scott
>
> HotWax Media
> http://www.hotwaxmedia.com
>
> On 23/10/2009, at 5:11 AM, Tim Ruppert wrote:
>
>> I hope this thread helps Scott.
>>
>> Cheers,
>> Ruppert
>> --
>> Tim Ruppert
>> HotWax Media
>> http://www.hotwaxmedia.com
>>
>> o:801.649.6594
>> f:801.649.6595
>>
>> Begin forwarded message:
>>
>>> From: Scott Gray <sc...@hotwaxmedia.com>
>>> Date: June 5, 2009 5:12:47 AM MDT
>>> To: dev@ofbiz.apache.org
>>> Subject: Re: Clearing credit card data after capture
>>> Reply-To: dev@ofbiz.apache.org
>>>
>>> Cool thanks, I'll look into it.
>>>
>>> Regards
>>> Scott
>>>
>>> On 5/06/2009, at 11:10 PM, David E Jones wrote:
>>>
>>>>
>>>> The more common recurring stuff in OFBiz right now is recurring
>>>> orders using an auto-order shopping list. You could certainly
>>>> check those before whacking the CC# and that would handle it.
>>>>
>>>> -David
>>>>
>>>>
>>>> On Jun 5, 2009, at 4:58 AM, Scott Gray wrote:
>>>>
>>>>> Thanks David, ProductStore it is.
>>>>>
>>>>> About the recurring billing I was hoping there would be someway
>>>>> to check if the cc is being used for it and to leave the
>>>>> information in place. That way we'd only be clearing unused cc
>>>>> data. I'm going to need to check for any pending transactions/
>>>>> payment prefs before clearing the data anyway, would that check
>>>>> be sufficient to pick up on recurring payments do you think?
>>>>>
>>>>> Regards
>>>>> Scott
>>>>>
>>>>> On 5/06/2009, at 9:54 PM, David E Jones wrote:
>>>>>
>>>>>>
>>>>>> On Jun 4, 2009, at 11:59 PM, Scott Gray wrote:
>>>>>>
>>>>>>> Hi All,
>>>>>>>
>>>>>>> I plan to add a configuration option to clear credit card data
>>>>>>> once there are no more auths pending against it. When I say
>>>>>>> clear the data I mean remove the expiry date and credit card
>>>>>>> number except for the last 4 digits.
>>>>>>>
>>>>>>> Any thoughts on where this should be configurable/how it
>>>>>>> should be implemented? I think the card clearing logic may
>>>>>>> have to be specific to the gateway being used, e.g. authorize.net
>>>>>>> needs you to keep the last 4 digits for refunds but others
>>>>>>> may not.
>>>>>>> I'm thinking perhaps I could add a new product store payment
>>>>>>> service type enumeration record, something like
>>>>>>> PRDS_PAY_CLEAR_DATA and the defined service would run after
>>>>>>> the capture and release services.
>>>>>>
>>>>>> That sounds pretty complex, and I'm wondering if the complexity
>>>>>> is needed. I guess to really answer more research would be
>>>>>> required, or maybe not. Keeping the last 4 digits should be
>>>>>> pretty safe, although these days I suppose that could be
>>>>>> valuable information for a hacker since for authentication over
>>>>>> the phone banks and others generally just ask for the last 4
>>>>>> digits of your government ID#, the last 4 of your CC#, etc.
>>>>>>
>>>>>> Anyway, it would be more consistent and more simple to just
>>>>>> have a setting on the ProductStore, and perhaps one with 3
>>>>>> options: keep CC #s, keep only last 4 digits of CC #s, don't
>>>>>> keep CC #s.
>>>>>>
>>>>>>> Recurring billing is the other thing I'm not sure about, I
>>>>>>> guess I'd need to leave the card data alone in that case but
>>>>>>> I've never worked with recurring payments so I'm not sure how
>>>>>>> I would detect if the card is being used for them.
>>>>>>
>>>>>> If an organization wants to avoid keeping CC #s then it will
>>>>>> certainly limit certain otherwise automated things. Recurring
>>>>>> orders or recurring billing would be something that is not
>>>>>> possible, unless a third party payment provider is used that
>>>>>> keeps the CC #. This is actually one of the very appealing
>>>>>> things about services like PayPal or GoogleCheckout where the
>>>>>> ecommerce site doesn't ever even accept payment information.
>>>>>>
>>>>>> In fact, for anyone who wants a feature like (ie remove CC
>>>>>> numbers after use), they might consider using a third party
>>>>>> payment site instead of the more transparent option of handling
>>>>>> it through their application.
>>>>>>
>>>>>> -David
>>>>>>
>>>>>
>>>>
>>>
>>
>
Re: Question about authorize.net and PCI compliance [ was on the dev list as Re: Clearing credit card data after capture ]
Posted by Scott Gray <sc...@hotwaxmedia.com>.
It actually never made it back into the trunk, the differences between
the trunk and revision I was working on were too large for a simple
merge and I was quite strapped for time.
Thanks for the reminder though, I'll definitely look at putting this
in there within the next weekend or two.
Regards
Scott
HotWax Media
http://www.hotwaxmedia.com
On 23/10/2009, at 5:11 AM, Tim Ruppert wrote:
> I hope this thread helps Scott.
>
> Cheers,
> Ruppert
> --
> Tim Ruppert
> HotWax Media
> http://www.hotwaxmedia.com
>
> o:801.649.6594
> f:801.649.6595
>
> Begin forwarded message:
>
>> From: Scott Gray <sc...@hotwaxmedia.com>
>> Date: June 5, 2009 5:12:47 AM MDT
>> To: dev@ofbiz.apache.org
>> Subject: Re: Clearing credit card data after capture
>> Reply-To: dev@ofbiz.apache.org
>>
>> Cool thanks, I'll look into it.
>>
>> Regards
>> Scott
>>
>> On 5/06/2009, at 11:10 PM, David E Jones wrote:
>>
>>>
>>> The more common recurring stuff in OFBiz right now is recurring
>>> orders using an auto-order shopping list. You could certainly
>>> check those before whacking the CC# and that would handle it.
>>>
>>> -David
>>>
>>>
>>> On Jun 5, 2009, at 4:58 AM, Scott Gray wrote:
>>>
>>>> Thanks David, ProductStore it is.
>>>>
>>>> About the recurring billing I was hoping there would be someway
>>>> to check if the cc is being used for it and to leave the
>>>> information in place. That way we'd only be clearing unused cc
>>>> data. I'm going to need to check for any pending transactions/
>>>> payment prefs before clearing the data anyway, would that check
>>>> be sufficient to pick up on recurring payments do you think?
>>>>
>>>> Regards
>>>> Scott
>>>>
>>>> On 5/06/2009, at 9:54 PM, David E Jones wrote:
>>>>
>>>>>
>>>>> On Jun 4, 2009, at 11:59 PM, Scott Gray wrote:
>>>>>
>>>>>> Hi All,
>>>>>>
>>>>>> I plan to add a configuration option to clear credit card data
>>>>>> once there are no more auths pending against it. When I say
>>>>>> clear the data I mean remove the expiry date and credit card
>>>>>> number except for the last 4 digits.
>>>>>>
>>>>>> Any thoughts on where this should be configurable/how it should
>>>>>> be implemented? I think the card clearing logic may have to be
>>>>>> specific to the gateway being used, e.g. authorize.net needs
>>>>>> you to keep the last 4 digits for refunds but others may not.
>>>>>> I'm thinking perhaps I could add a new product store payment
>>>>>> service type enumeration record, something like
>>>>>> PRDS_PAY_CLEAR_DATA and the defined service would run after the
>>>>>> capture and release services.
>>>>>
>>>>> That sounds pretty complex, and I'm wondering if the complexity
>>>>> is needed. I guess to really answer more research would be
>>>>> required, or maybe not. Keeping the last 4 digits should be
>>>>> pretty safe, although these days I suppose that could be
>>>>> valuable information for a hacker since for authentication over
>>>>> the phone banks and others generally just ask for the last 4
>>>>> digits of your government ID#, the last 4 of your CC#, etc.
>>>>>
>>>>> Anyway, it would be more consistent and more simple to just have
>>>>> a setting on the ProductStore, and perhaps one with 3 options:
>>>>> keep CC #s, keep only last 4 digits of CC #s, don't keep CC #s.
>>>>>
>>>>>> Recurring billing is the other thing I'm not sure about, I
>>>>>> guess I'd need to leave the card data alone in that case but
>>>>>> I've never worked with recurring payments so I'm not sure how I
>>>>>> would detect if the card is being used for them.
>>>>>
>>>>> If an organization wants to avoid keeping CC #s then it will
>>>>> certainly limit certain otherwise automated things. Recurring
>>>>> orders or recurring billing would be something that is not
>>>>> possible, unless a third party payment provider is used that
>>>>> keeps the CC #. This is actually one of the very appealing
>>>>> things about services like PayPal or GoogleCheckout where the
>>>>> ecommerce site doesn't ever even accept payment information.
>>>>>
>>>>> In fact, for anyone who wants a feature like (ie remove CC
>>>>> numbers after use), they might consider using a third party
>>>>> payment site instead of the more transparent option of handling
>>>>> it through their application.
>>>>>
>>>>> -David
>>>>>
>>>>
>>>
>>
>