PayPal Website Payments Pro
Stephanie Powell
I see from the string
http://groups.google.com/group/spree-user/browse_thread/thread/59d914debc431e17/781dd4a36d41ae1c?lnk=gst&q=paypal+pro#781dd4a36d41ae1c
that some folks have integrated PayPal Website Payments Pro into Spree
in two sites
(mascotslingy and greenlandgardener).
Is the code used for this integration open-sourced? I'm not sure who
worked on these two sites, but I'd like to know if that code is
available to use or reference.
Thanks,
Steph
Stephanie Powell
PayPal Website Payments Pro requires the site to be PCI compliant. IIRC,
Spree is not PCI compliant. How was this handled for these two sites?
And if I'm wrong about PCI compliance, please correct me.
Thanks,
Steph
Sean Harper
quite minimal if you do not store the actual card numbers locally and
use the self assessment questionaire.
> --
> You received this message because you are subscribed to the Google Groups
> "Spree" group.
> To post to this group, send email to spree...@googlegroups.com.
> To unsubscribe from this group, send email to
> spree-user+...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/spree-user?hl=en.
>
>
Stephanie Powell
I'll explain my assumption. I haven't worked with PCI compliance in a
while, but if my memory serves me right, I believe you must store
encrypted credit card numbers on the system, you can't store the full
un-encrypted/"readable" credit card number in a database among other
requirements.
In the Spree edge code, there is a number column in the creditcards
module, but unfortunately none of this data is prepopulated in the
fixtures and I'm unable to checkout on the edge code to test a new CC at
the moment. Also, according to
http://groups.google.com/group/spree-user/browse_thread/thread/95fefae79db3a43/856054f1566c3a33,
credit cards are definitely stored in the database along with other
credit card information. Also in this thread there is a comment made
that the merchant is responsible for PCI compliance, but I believe this
is an incorrect statement because merchants using Spree won't always be
aware of the underlying data model nor will they necessarily be aware of
PCI compliance rules.
The other reason that I assumed numbers are stored in the database is
because refunds are now a part of the Spree edge and you would only be
able to refund if you have the original card number.
As I said before, if I'm incorrect about Spree's PCI compliance and the
credit card numbers are encrypted now, that's great - great for my
client who needs PCI compliance. I'm just trying to get some insight for
the client who would like to use PayPal Website Payments Pro which
requires PCI compliance. We are planning on working through / addressing
the PCI compliance issues somehow and we may have to resort to PayPal
Express if that's our only reasonable option.
~Steph
Paul Callaghan
We wrote something [1] a few months ago, and I think most of it is still accurate. It answers a few of your questions.
Regarding responsibility, I doubt that lack of awareness of technical details etc etc is a valid excuse. I expect that in the first instance, responsibility does lie with the merchant since they have the direct relationship with the payment processor. (But I'm not a lawyer...)
For refunds, only the authorize.net CIM gateway has implemented this at the moment, and it uses a customer profile as the basis of identification. (Spree does store gateway authorization info - can any gateways use this to do refunds?)
Paul
[1] http://spreecommerce.com/documentation/security.html
Paul Callaghan
Paul
Stephanie Powell
I didn't mean to suggest that the merchant does not hold responsibility
in PCI compliance when using an open source solution.
I just created a rails app running from the Spree 0.9.4 gem and see that
the Creditcard.number field does not get populated with checkout and now
I see the store_cc and store_cvv preference settings in
app_configuration.rb which explains things.
As I said, I'm happy to be wrong. Happy for my client :) I just didn't
get the feeling from the spree-user string I previously attached because
I don't see anything definitively announced regarding Spree's PCI
compliance. And yes, of course refunds can be run against the
transaction id returned by a payment gateway. Some gateways offer
refunds against different CCs on the admin side, but that also wouldn't
require CC storage. One issue I will have with my client is that they
want to delay credit card authorization until the item fulfillment,
which does present a requirement for CC storage. I'll have to talk that
through with him.
Thanks,
Steph
Paul Callaghan wrote:
> Hi
>
> We wrote something [1] a few months ago, and I think most of it is
> still accurate. It answers a few of your questions.
>
> Regarding responsibility, I doubt that lack of awareness of technical
> details etc etc is a valid excuse. I expect that in the first
> instance, responsibility does lie with the merchant since they have
> the direct relationship with the payment processor. (But I'm not a
> lawyer...)
>
> For refunds, only the authorize.net <http://authorize.net> CIM gateway
> has implemented this at the moment, and it uses a customer profile as
> the basis of identification. (Spree does store gateway authorization
> info - can any gateways use this to do refunds?)
>
>
> Paul
>
>
> [1] http://spreecommerce.com/documentation/security.html
>
>
Sean Schofield
specifically enabled. We'll also eventually remove that setting I
think b/c its too misleading and will likely raise more concerns than
its worth.
So whenever we say "store" we really mean its stored offsite, secure
storage with a PCI compliant service. The upcoming release of Spree
will use Authorize.net CIM profiles and probably Beanstream profile
support (patch is there and I just need to review it.)
You can also optionally configure the checkout to not use a stored
creditcard number and just post directly to gateway and discard. This
is the old way (0.9.4 and earlier.) Its also perfectly safe but makes
it more difficult to do refunds, etc. in some cases. Its also not
"enabled" by default so if you're not going to use secure payment you
have a little extra work to do.
Bogus gateway simulates this profile behavior so you can test just
fine and eventually we'll have the documentation and possibly even
configuration to show you how to do rig it to bypass profiles and post
directly to gateway (and discard.) Both approaches are PCI compliant
but not certified.
Sean Schofield
-------------------------------------------
Rails Dog LLC
2 Wisconsin Circle, Suite 700
Chevy Chase, MD 20815
voice: (301)560-2000
-------------------------------------------
Paul Callaghan
Just to emphasize that Spree never stored credit card numbers unless
specifically enabled.
Plus, the secure fields are blanked out when writing to log files.
A warning: if you are using hoptoad or similar in addition to Spree, do check that error reports will not include any sensitive information! The previous version of the hoptoad notifier needed to be configured specifically to omit information - it did not honor the filter_parameter_logging setup. I've not looked at the current notifier version yet.
Paul