[LRUG] Recurring Payments and subscriptions

[Neil Middleton]

Working on the basis that people tend to use subscription management
services (Spreedly etc) with a merchant account, how do people tend to keep
that in sync with their app?

For instance, how do you validate an account locally, and on the sub service
before save? Do people tend to just let the subscription service manage
accounts, and keep calling back for info (which could be slow, and is a
major dependancy) or do people try and stay as far away as possible.

I can only see a raft of potential issues keeping the two sides of the
equation in sync so would be interested in seeing how others manage this...

Neil

On Mon, Sep 6, 2010 at 11:09 AM, Daniel Barlow <dan at telent.net> wrote:

> 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
>
>
> _______________________________________________
> Chat mailing list
> Chat at lists.lrug.org
> http://lists.lrug.org/listinfo.cgi/chat-lrug.org
>



-- 
Neil Middleton
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lrug.org/pipermail/chat-lrug.org/attachments/20100907/477e84a1/attachment-0003.html>