Clearing credit card data after capture

[Scott Gray-2]

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.

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.

Any thoughts would be appreciated.

Thanks
Scott

HotWax Media
http://www.hotwaxmedia.com

[David E Jones-3]

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

[BJ Freeman]

as of July 2010 this will be a mute point.
the only payments systems that ofbiz can use will be Paypal IPN or
Google checkout by default.

the only way that ofbiz can be used with any other gateway and Visa CC,
is when a company takes the ofbiz code and makes it their own and
becomes responsible for the Certification. Certification currently is
quoted as $100,000.

Based on the certification process I think any effort should be how
ofbiz will pass the certification.


Scott Gray sent the following on 6/4/2009 10:59 PM:

> 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.
>
> 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.
>
> Any thoughts would be appreciated.
>
> Thanks
> Scott
>
> HotWax Media
> http://www.hotwaxmedia.com

--
BJ Freeman
http://www.businessesnetwork.com/automation
http://bjfreeman.elance.com
http://www.linkedin.com/profile?viewProfile=&key=1237480&locale=en_US&trk=tab_pro
Systems Integrator.

[Scott Gray-2]

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
>

[David E Jones-3]

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

[Scott Gray-2]

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

[David E Jones-3]

This isn't necessarily true. I'm not a lawyer, and I haven't read all  
of the docs... only a few articles on the topic, and I'm not even sure  
what is finalized at this point since a lot of these things seem to be  
tentative policies that aren't fleshed out yet.

There are always alternatives. This might cause certain retailers to  
not accept certain credit cards, for example (like only accepting AmEx  
and Discover and such since it is mainly Visa and MasterCard that are  
behind a lot of these things). Another likely thing is that in the  
future, just like now, the requirements vary depending on your  
transaction volume. Chances are the requirement you're alluding to  
won't kick in for the majority of OFBiz users... most of whom are  
probably in the transaction volume range where only a self-evaluation  
for PCI compliance (ie just filling out a form) is required.

-David


On Jun 5, 2009, at 4:58 AM, BJ Freeman wrote:

> as of July 2010 this will be a mute point.
> the only payments systems that ofbiz can use will be Paypal IPN or
> Google checkout by default.
>
> the only way that ofbiz can be used with any other gateway and Visa  
> CC,
> is when a company takes the ofbiz code and makes it their own and
> becomes responsible for the Certification. Certification currently is
> quoted as $100,000.
>
> Based on the certification process I think any effort should be how
> ofbiz will pass the certification.
>
>
> Scott Gray sent the following on 6/4/2009 10:59 PM:
>> 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.
>>
>> 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.
>>
>> Any thoughts would be appreciated.
>>
>> Thanks
>> Scott
>>
>> HotWax Media
>> http://www.hotwaxmedia.com
>
> --
> BJ Freeman
> http://www.businessesnetwork.com/automation
> http://bjfreeman.elance.com
> http://www.linkedin.com/profile?viewProfile=&key=1237480&locale=en_US&trk=tab_pro
> Systems Integrator.
>

[BJ Freeman]

You are correct at this time banks are requiring a scan from their
provider and filling out a form.
Your also correct that it is being lobbied in the Congress but Congress
is favoring even heavier restrictions.
http://chuvakin.blogspot.com/2009/04/thoughts-and-notes-from-pci-dss-hearing.html

here are some links that may help.
http://usa.visa.com/merchants/risk_management/cisp_payment_applications.html
http://www.pcicomplianceguide.org/pcifaqs.php#2
https://www.pcisecuritystandards.org/security_standards/vpa/

David E Jones sent the following on 6/5/2009 4:13 AM:

>
> This isn't necessarily true. I'm not a lawyer, and I haven't read all of
> the docs... only a few articles on the topic, and I'm not even sure what
> is finalized at this point since a lot of these things seem to be
> tentative policies that aren't fleshed out yet.
>
> There are always alternatives. This might cause certain retailers to not
> accept certain credit cards, for example (like only accepting AmEx and
> Discover and such since it is mainly Visa and MasterCard that are behind
> a lot of these things). Another likely thing is that in the future, just
> like now, the requirements vary depending on your transaction volume.
> Chances are the requirement you're alluding to won't kick in for the
> majority of OFBiz users... most of whom are probably in the transaction
> volume range where only a self-evaluation for PCI compliance (ie just
> filling out a form) is required.
>
> -David
>
>
> On Jun 5, 2009, at 4:58 AM, BJ Freeman wrote:
>
>> as of July 2010 this will be a mute point.
>> the only payments systems that ofbiz can use will be Paypal IPN or
>> Google checkout by default.
>>
>> the only way that ofbiz can be used with any other gateway and Visa CC,
>> is when a company takes the ofbiz code and makes it their own and
>> becomes responsible for the Certification. Certification currently is
>> quoted as $100,000.
>>
>> Based on the certification process I think any effort should be how
>> ofbiz will pass the certification.
>>
>>
>> Scott Gray sent the following on 6/4/2009 10:59 PM:
>>> 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.
>>>
>>> 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.
>>>
>>> Any thoughts would be appreciated.
>>>
>>> Thanks
>>> Scott
>>>
>>> HotWax Media
>>> http://www.hotwaxmedia.com
>>
>> --
>> BJ Freeman
>> http://www.businessesnetwork.com/automation
>> http://bjfreeman.elance.com
>> http://www.linkedin.com/profile?viewProfile=&key=1237480&locale=en_US&trk=tab_pro
>>
>> Systems Integrator.
>>
>
>

--
BJ Freeman
http://www.businessesnetwork.com/automation
http://bjfreeman.elance.com
http://www.linkedin.com/profile?viewProfile=&key=1237480&locale=en_US&trk=tab_pro
Systems Integrator.

[Vince Clark]

Why store it at all? Once you have the auth you don't need the cc# to do a capture. I suppose you might need it for a reauth, but I believe you can even accomplish that with the original authorization.


Vince Clark
[hidden email]
[phone]

----- Original Message -----
From: "Scott Gray" <[hidden email]>
To: [hidden email]
Sent: Thursday, June 4, 2009 11:59:44 PM GMT -07:00 US/Canada Mountain
Subject: Clearing credit card data after capture

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.

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.

Any thoughts would be appreciated.

Thanks
Scott

HotWax Media
http://www.hotwaxmedia.com

[carsonrotisserie]

Storing credit card numbers seems to be a recurring concern with many people.  I’ve tried to find out as much as I can on this issue in regards to ofbiz.  Here are the threads I’ve found so far.

http://osdir.com/ml/user.ofbiz.apache.org/2009-10/msg00706.html
http://www.mail-archive.com/[e-mail]/msg05735.html
http://www.pubbs.net/ofbiz/200910/58402/
http://n4.nabble.com/Address-update-issue-td278128.html#a278186

I'm fairly new to ofbiz but I've been developing in ecommerce and I've worked with different payment gateways for years now.   The gateway I've spent years working with is Cybersource.  I find it surprising that ofbiz has not built an option into the system for selecting to not storing credit card numbers.  I'm not sure about some of the other gateways but I know at least with cybersource, there is absolutely no reason to store the cc number.  After you make the initialize authorization, you receive a request token for that auth.  With this request token you can make any type of subsequent requests, whether it is capture, credit, re-auth, etc.  The request token is valid for up to 60 days.  Also cybersource returns a unique request token for each of these requests that can also be used to make further requests.  Having this feature really makes storing the credit card numbers useless, increases your PCI compliance level, and makes companies feel a whole lot better.  Cybersource also has support for recurring orders and payments, although I've never used them, I'm sure they could be built into the ofbiz recurring order functionality.
       
I've not really had a chance to dig into the code yet, but for someone who knows the code, this should be a pretty simple enhancement.  All you would need to do is make sure you store the request token from the initial authorization and then on the captures, credits, re-auths, instead of passing the cc number into it, you just pass the request token.

[BJ Freeman]

not all gateways in ofbiz provide the functionality of cybersource.
you can use paypal the same way.


=========================
BJ Freeman
http://bjfreeman.elance.com
Strategic Power Office with Supplier Automation <http://www.businessesnetwork.com/automation/viewforum.php?f=93>
Specialtymarket.com <http://www.specialtymarket.com/>

Systems Integrator-- Glad to Assist

Chat  Y! messenger: bjfr33man
Linkedin
<http://www.linkedin.com/profile?viewProfile=&key=1237480&locale=en_US&trk=tab_pro>


carsonrotisserie sent the following on 3/26/2010 9:28 AM:

> Storing credit card numbers seems to be a recurring concern with many people.
> I’ve tried to find out as much as I can on this issue in regards to ofbiz.
> Here are the threads I’ve found so far.
>
> http://osdir.com/ml/user.ofbiz.apache.org/2009-10/msg00706.html
> http://www.mail-archive.com/user@.../msg05735.html
> http://www.pubbs.net/ofbiz/200910/58402/
> http://n4.nabble.com/Address-update-issue-td278128.html#a278186
>
> I'm fairly new to ofbiz but I've been developing in ecommerce and I've
> worked with different payment gateways for years now.   The gateway I've
> spent years working with is Cybersource.  I find it surprising that ofbiz
> has not built an option into the system for selecting to not storing credit
> card numbers.  I'm not sure about some of the other gateways but I know at
> least with cybersource, there is absolutely no reason to store the cc
> number.  After you make the initialize authorization, you receive a request
> token for that auth.  With this request token you can make any type of
> subsequent requests, whether it is capture, credit, re-auth, etc.  The
> request token is valid for up to 60 days.  Also cybersource returns a unique
> request token for each of these requests that can also be used to make
> further requests.  Having this feature really makes storing the credit card
> numbers useless, increases your PCI compliance level, and makes companies
> feel a whole lot better.  Cybersource also has support for recurring orders
> and payments, although I've never used them, I'm sure they could be built
> into the ofbiz recurring order functionality.
>
> I've not really had a chance to dig into the code yet, but for someone who
> knows the code, this should be a pretty simple enhancement.  All you would
> need to do is make sure you store the request token from the initial
> authorization and then on the captures, credits, re-auths, instead of
> passing the cc number into it, you just pass the request token.
>

[carsonrotisserie]

Agreed.  However I can't imagine ofbiz would be that hard to customize a payment service to provide that feature.  I've been working with ofbiz for about 5 months now, just as a side job a few hours a week and everything so far seems to be very customizable.  I've been really impressed with it and its capabilities so far!  In regards to some gateways not providing the "request token" functionality would seem kind of irrelevant to the customer not wanting to store the credit card numbers because that customer would never choose that gateway to begin with.

[BJ Freeman]

check the CreditCard Entity in the
/application/accounting/entitydef/entitymodel.xml
also cruise the other entities.
Do a search of the code that interacts with CreditCard entity and the
ALias CC.
also check the schedule services to re-authorize cc
http://cwiki.apache.org/confluence/display/OFBADMIN/OFBiz+Source+Repository+and+Access
The only thing not done currently but able to be customized is selected
stored CC.

=========================
BJ Freeman
http://bjfreeman.elance.com
Strategic Power Office with Supplier Automation <http://www.businessesnetwork.com/automation/viewforum.php?f=93>
Specialtymarket.com <http://www.specialtymarket.com/>

Systems Integrator-- Glad to Assist

Chat  Y! messenger: bjfr33man
Linkedin
<http://www.linkedin.com/profile?viewProfile=&key=1237480&locale=en_US&trk=tab_pro>


carsonrotisserie sent the following on 3/26/2010 10:08 AM:
> Agreed.  However I can't imagine ofbiz would be that hard to customize a
> payment service to provide that feature.  I've been working with ofbiz for
> about 5 months now, just as a side job a few hours a week and everything so
> far seems to be very customizable.  I've been really impressed with it and
> its capabilities so far!  In regards to some gateways not providing the
> "request token" functionality would seem kind of irrelevant to the customer
> not wanting to store the credit card numbers because that customer would
> never choose that gateway to begin with.

[carsonrotisserie]

Great, thanks BJ!  I will give it a try.

[carsonrotisserie]

Just to give an update, I solved this problem by enhancing the method PaymentGatewayServices.processAuthResult to replace the credit card number after the authorization is complete.  

String number = (String)creditCard.get("cardNumber");
String lastFourDigits = number.substring(number.length() - 4, number.length());
String firstDigits = number.substring(0, number.length() - 4);
firstDigits = Pattern.compile(".").matcher(firstDigits).replaceAll("x");
creditCard.set("cardNumber", firstDigits + lastFourDigits);
creditCard.store();

I also had to modify the capture and refund methods in the specific processor code to use the request token instead of the credit card number.

I really do wish ofbiz would build this as a configurable option into the system as I have worked with some of the biggest online ecommerce retailers and in my experience storing credit card numbers is not the best practice.

[David E. Jones-2]

On Feb 28, 2011, at 2:53 PM, carsonrotisserie wrote:

> Just to give an update, I solved this problem by enhancing the method
> PaymentGatewayServices.processAuthResult to replace the credit card number
> after the authorization is complete.  
>
> String number = (String)creditCard.get("cardNumber");
> String lastFourDigits = number.substring(number.length() - 4,
> number.length());
> String firstDigits = number.substring(0, number.length() - 4);
> firstDigits = Pattern.compile(".").matcher(firstDigits).replaceAll("x");
> creditCard.set("cardNumber", firstDigits + lastFourDigits);
> creditCard.store();
>
> I also had to modify the capture and refund methods in the specific
> processor code to use the request token instead of the credit card number.
>
> I really do wish ofbiz would build this as a configurable option into the
> system as I have worked with some of the biggest online ecommerce retailers
> and in my experience storing credit card numbers is not the best practice.
>

Submit a patch and chances are it will happen...

-David