Re: Question about authorize.net and PCI compliance [ was on the dev list as Re: Clearing credit card data after capture ]

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

Re: Question about authorize.net and PCI compliance [ was on the dev list as Re: Clearing credit card data after capture ]

Tim Ruppert
I hope this thread helps Scott.

Cheers,
Ruppert
--
Tim Ruppert
HotWax Media

o:801.649.6594
f:801.649.6595

Begin forwarded message:

From: Scott Gray <[hidden email]>
Date: June 5, 2009 5:12:47 AM MDT
Subject: Re: Clearing credit card data after capture
Reply-To: [hidden email]

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






smime.p7s (3K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Question about authorize.net and PCI compliance [ was on the dev list as Re: Clearing credit card data after capture ]

Scott Gray-2
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 <[hidden email]>
>> Date: June 5, 2009 5:12:47 AM MDT
>> To: [hidden email]
>> Subject: Re: Clearing credit card data after capture
>> Reply-To: [hidden email]
>>
>> 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
>>>>>
>>>>
>>>
>>
>


smime.p7s (4K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Question about authorize.net and PCI compliance [ was on the dev list as Re: Clearing credit card data after capture ]

Tim Ruppert
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 <[hidden email]>
>>> Date: June 5, 2009 5:12:47 AM MDT
>>> To: [hidden email]
>>> Subject: Re: Clearing credit card data after capture
>>> Reply-To: [hidden email]
>>>
>>> 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
>>>>>>
>>>>>
>>>>
>>>
>>
>


smime.p7s (3K) Download Attachment