SagePay Gateway: needs PCI with tokenization

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

SagePay Gateway: needs PCI with tokenization

brajeshpatel
Hello All,

I am looking into Sagepay related stuff:

Currently we have Sagepay payment gateway integration in OOTB,

We have requirement for PCI with tokenization in sage pay.
I am thinking that we need to add 'SagepayPaymentMethod' entity, same as
Paypal have PaypalPaymentMethod entity that contains "expressCheckoutToken"
field that store token value for transactions.

Via this entity (SagepayPaymentMethod) we can manage history of Sagepay
transaction(response token).
We also need code related changes for payment stuff of Sagepay just like
Paypal.

Please provide opinion.

Big appreciation if anybody take initiative on this stuff

--
Thanks
Brajesh Patel
Salmonllc.com
http://bigfish.salmonllc.com/bfDemo.html
skype: brajesh.patel11
Cell:- +91 8750709907
Reply | Threaded
Open this post in threaded view
|

Re: SagePay Gateway: needs PCI with tokenization

Adam Heath-2
On 04/18/2012 03:28 PM, Brajesh Patel wrote:

> Hello All,
>
> I am looking into Sagepay related stuff:
>
> Currently we have Sagepay payment gateway integration in OOTB,
>
> We have requirement for PCI with tokenization in sage pay.
> I am thinking that we need to add 'SagepayPaymentMethod' entity, same as
> Paypal have PaypalPaymentMethod entity that contains "expressCheckoutToken"
> field that store token value for transactions.
>
> Via this entity (SagepayPaymentMethod) we can manage history of Sagepay
> transaction(response token).
> We also need code related changes for payment stuff of Sagepay just like
> Paypal.

For the record, PCI compliance doesn't say you *can't* store the PAN
ever; it's just that it needs to be encrypted.  The PIN, however,
can't *ever* be stored.  It's this latter that ofbiz currently does
incorrectly(the PIN is stored in OrderPaymentPreference).

I have a feature I will be adding to EntityCrypto, to support
key-encrypting keys(the idea comes from PCI).  Right now, if you can
access the database(or a dump of it), you can access the stored credit
card numbers.  A key-encrypting key would be stored in a file
somewhere in $OFBIZ_HOME, that would encrypt the key used in the
database, which is then further used to encrypt the column values.

As far as using a token, not all payment processors support such a
feature.  So, ofbiz can't require tokenized processing to reach PCI
compliance, so we need to support other variants.  Using
key-encrypting keys, and not storing PIN, and not print the PAN/PIN to
the log, would get us most of the way there.
Reply | Threaded
Open this post in threaded view
|

Re: SagePay Gateway: needs PCI with tokenization

brajeshpatel
thanks Adam for your valuable comments,

do we have any Jira issue for same, I try to find but not able to get any.

inline.


On Thu, Apr 19, 2012 at 2:30 AM, Adam Heath <[hidden email]> wrote:

> On 04/18/2012 03:28 PM, Brajesh Patel wrote:
> > Hello All,
> >
> > I am looking into Sagepay related stuff:
> >
> > Currently we have Sagepay payment gateway integration in OOTB,
> >
> > We have requirement for PCI with tokenization in sage pay.
> > I am thinking that we need to add 'SagepayPaymentMethod' entity, same as
>

We can add this entity or related changes for same.


>  > Paypal have PaypalPaymentMethod entity that contains
> "expressCheckoutToken"
> > field that store token value for transactions.
> >
> > Via this entity (SagepayPaymentMethod) we can manage history of Sagepay
> > transaction(response token).
> > We also need code related changes for payment stuff of Sagepay just like
> > Paypal.
>
> For the record, PCI compliance doesn't say you *can't* store the PAN
> ever; it's just that it needs to be encrypted.  The PIN, however,
> can't *ever* be stored.  It's this latter that ofbiz currently does
> incorrectly(the PIN is stored in OrderPaymentPreference).
>

> I have a feature I will be adding to EntityCrypto, to support
> key-encrypting keys(the idea comes from PCI).  Right now, if you can
> access the database(or a dump of it), you can access the stored credit
> card numbers.  A key-encrypting key would be stored in a file
> somewhere in $OFBIZ_HOME, that would encrypt the key used in the
> database, which is then further used to encrypt the column values.
>

are you going to contribute this feature in OOTB.


> As far as using a token, not all payment processors support such a
> feature.  So, ofbiz can't require tokenized processing to reach PCI
> compliance, so we need to support other variants.  Using
> key-encrypting keys, and not storing PIN, and not print the PAN/PIN to
> the log, would get us most of the way there.
>



--
Thanks
Brajesh Patel
skype: brajesh.patel11
Cell:- +91 8750709907
Reply | Threaded
Open this post in threaded view
|

Re: SagePay Gateway: needs PCI with tokenization

brajeshpatel
In reply to this post by Adam Heath-2
Thanks Adam for your valuable comment,

I found token related information for the sagepay from
http://www.sagepay.com/token-system site as follows:


Token System is a safe way of keeping card details without actually storing
them. We store and convert your customer's sensitive payment information
into a secure token or "alias". This gives you the flexibility to process
transactions as and when required, without compromising on card data
security.
due to this reason I raised this issue here, because I find jira issue for
same but not getting issue.

comment inline more:


On Thu, Apr 19, 2012 at 2:30 AM, Adam Heath <[hidden email]> wrote:

> On 04/18/2012 03:28 PM, Brajesh Patel wrote:
> > Hello All,
> >
> > I am looking into Sagepay related stuff:
> >
> > Currently we have Sagepay payment gateway integration in OOTB,
> >
> > We have requirement for PCI with tokenization in sage pay.
> > I am thinking that we need to add 'SagepayPaymentMethod' entity, same as
> > Paypal have PaypalPaymentMethod entity that contains
> "expressCheckoutToken"
> > field that store token value for transactions.
> >
> > Via this entity (SagepayPaymentMethod) we can manage history of Sagepay
> > transaction(response token).
> > We also need code related changes for payment stuff of Sagepay just like
> > Paypal.
>
> For the record, PCI compliance doesn't say you *can't* store the PAN
> ever; it's just that it needs to be encrypted.  The PIN, however,
> can't *ever* be stored.  It's this latter that ofbiz currently does
> incorrectly(the PIN is stored in OrderPaymentPreference).
>
> I have a feature I will be adding to EntityCrypto, to support
> key-encrypting keys(the idea comes from PCI).  Right now, if you can
> access the database(or a dump of it), you can access the stored credit
> card numbers.  A key-encrypting key would be stored in a file
> somewhere in $OFBIZ_HOME, that would encrypt the key used in the
> database, which is then further used to encrypt the column values.
>

are you contributing this feature to the OFBiz or you have customize this
feature at your end.



>
> As far as using a token, not all payment processors support such a
> feature.  So, ofbiz can't require tokenized processing to reach PCI
> compliance, so we need to support other variants.  Using
> key-encrypting keys, and not storing PIN, and not print the PAN/PIN to
> the log, would get us most of the way there.
>



--
Thanks
Brajesh Patel
Salmonllc.com
http://bigfish.salmonllc.com/bfDemo.html

skype: brajesh.patel11
Cell:- +91 8750709907
Reply | Threaded
Open this post in threaded view
|

Re: SagePay Gateway: needs PCI with tokenization

Adam Heath-2
On 04/20/2012 11:54 AM, Brajesh Patel wrote:

> Thanks Adam for your valuable comment,
>
> I found token related information for the sagepay from
> http://www.sagepay.com/token-system site as follows:
>
>
> Token System is a safe way of keeping card details without actually storing
> them. We store and convert your customer's sensitive payment information
> into a secure token or "alias". This gives you the flexibility to process
> transactions as and when required, without compromising on card data
> security.
> due to this reason I raised this issue here, because I find jira issue for
> same but not getting issue.

A possible way to implement this is using a new
paymentMethodTypeId=TOKEN, with hasTable=Y, then a new
TokenPaymentMethod entity.