[LRUG] Recurring Payments and subscriptions

[Daniel Barlow]

Lee Irving wrote:
> Hi Marcus,
> 
> It was my understanding that if you used the direct method then this
> was classed as storing the creditcard numbers as they pass through
> your systems memory  and therefore you got hit by the stricter PCI
> standard. ( having to be hosted on a PCI compliant host etc) You also
> have to be very careful with what goes into your Webserver and
> Application logs.
> 
> I find the whole PCI standard is very confusing and different people
> have different takes on it of what you need to do.

Yes, it's a horrible mess.  The requirements specify solutions without 
actually defining the problems - it's like getting a contributed patch 
without the test case or bug report -  leaving the implementor to 
attempt to guess what particular threat was in the head of the PCI 
people when they said you need a DMZ or a virus checker or whatever. 
And as different QSAs interpret the rules in different ways,  I suspect 
the only way to categorically find out what the requirements are is to 
get investigated after a cardholder security breach.  Which you don't want.

We used to use Sagepay Direct (the API version of Sagepay) until about 
12 months ago when our merchant services gave us an immovable deadline 
for PCI compliance, and we decided that the easiest and least-hassle 
compliance strategy would be to move to SagePay Server.  In Server, they 
host the payment pages (so card numbers never touch our site) and we 
skin them using some really rather ugly XSLT stuff - net effect is that 
the customer sees the URL change but the branding remains ours.

Be aware if you have any other routes to accept card payments (e.g. a 
call centre or over-the-counter transactions) that they also will fall 
within the scope of PCI.  You have to consider any computer or device 
anywhere in your organisation that cardholder data passes through.

Would I recommend Sagepay?  Certainly not strongly, and possibly not at 
all, but I haven't yet found an alternative that's sufficiently better 
to be worth moving to.  They've had a few well-publicised outages, their 
support is generally fast for simple questions but not very technically 
astute, and the page skinning system involves mailing them a zip file of 
the xslt files you want them to apply then waiting 24 hour for them to 
install them by hand, which is not exactly "rake install" in its 
simplicity.  The actual API stuff is just HTTP POSTs - I wouldn't bother 
to go looking for libraries because most of the time they are not 
well-supported and lag the API version.  That said, I was using Perl to 
do this work and can't specifically comment on Ruby support

The https://support.sagepay.com/forum/ is a useful resource: have a look 
at the Server and Direct subforums for a flavour of the integration work 
others have done and/or issues they encountered.  There are probably 
still a few rants by me in there somewhere ;-)


> From what I could tell if you used Sagepay forms then you were ok as
> you did not take the credit card payments locally, Sage handle that on
> their platform and you never take the card details, and it was this
> scenario that meant that you fell under the less strict version.
> 
> I would be glad to be proved wrong on this though.

For Server (which is approximately half API and half forms-based, but 
doesnt require you to see cardholder data at any time) my understanding 
is that you still need to do the PCI self-assessment questionnaire but 
the short version (I think we filled out "C") suffices.  It's possibly a 
good thing for many businesses as it force them to think about incident 
response procedures and data security standards in general.



-dan