<font color="#333333"><font size="2"><font face="arial,helvetica,sans-serif">We rolled our own with Barclaycard and PayPoint (secpay).</font></font></font><div><font color="#333333"><font size="2"><font face="arial,helvetica,sans-serif"><br>
</font></font></font></div><div><font color="#333333"><font size="2"><font face="arial,helvetica,sans-serif">PayPoint have a token system for repeat billing so you don't need to store the card numbers. As others have pointed out, this means you probably only need to complete questionnaire C for PCI compliance - which isn't too difficult and is mostly stuff you should be doing anyway. I can also recommend SecurityMetrics who work with Barclaycard. They have an online questionnaire and report your compliance status back to barclaycard directly, which makes it a little easier. It only costs about £110 / year including the scans.</font></font></font></div>
<div><font color="#333333"><font size="2"><font face="arial,helvetica,sans-serif"><br></font></font></font></div><div><font class="Apple-style-span" color="#333333" face="arial, helvetica, sans-serif">The main reasons we rolled our own were:</font></div>
<div><font class="Apple-style-span" color="#333333" face="arial, helvetica, sans-serif"><br></font></div><div><font class="Apple-style-span" color="#333333" face="arial, helvetica, sans-serif">- Checkout optimisation - full control over payment pages was essential. We do lots of a/b testing and generally spend a lot of energy making these processes as frictionless as possible. "Skinning" wasn't enough, we needed control over the whole process.</font></div>
<div><font class="Apple-style-span" color="#333333" face="arial, helvetica, sans-serif"><br></font></div><div><font class="Apple-style-span" color="#333333" face="arial, helvetica, sans-serif">- Future plans for repeat billing for micro-payments. Once we have a token from the customer's initial payment we can repeat bill for other additional services without any significant user intervention. These are often impulse purchases, so simplicity really matters (think how easy AppStore purchases are).</font></div>
<div><font class="Apple-style-span" color="#333333" face="arial, helvetica, sans-serif"><br></font></div><div><font class="Apple-style-span" color="#333333" face="arial, helvetica, sans-serif">- Customer services - e.g. the ability to add free credit when there are problems. Our system re-bills when a previous subscription expires, rather than at a fixed time interval. We can alter expiry dates and add free time to customers accounts if they've had a problem with the service. This is really useful to defuse a difficult situation, and I imagine it's not so easy if you don't control the timing of the repeat payments.</font></div>
<div><font class="Apple-style-span" color="#333333" face="arial, helvetica, sans-serif"><br></font></div><div><font class="Apple-style-span" color="#333333" face="arial, helvetica, sans-serif">Even with just a few thousand subscribers, getting this right has meant many thousands/month in extra revenue. Maybe chargify can handle some of these points - I'd definitely look at them again now there is a UK option, especially for a startup (which this wasn't). For simple models, chargify is probably going to be enough though as their process is very smooth.</font></div>
<div><font class="Apple-style-span" color="#333333" face="arial, helvetica, sans-serif"><br></font></div><div><font class="Apple-style-span" color="#333333" face="arial, helvetica, sans-serif">It does worry me that we are now locked in</font><span class="Apple-style-span" style="font-family: arial, helvetica, sans-serif; color: rgb(51, 51, 51); "> to PayPoint with the repeat billing tokens. Moving to another provider overnight could mean a major hit in revenue. For a larger businesses I expect the only safe option must be to keep hold of the numbers so you can switch providers if they suddenly decide screw you. </span></div>
<div><span class="Apple-style-span" style="font-family: arial, helvetica, sans-serif; color: rgb(51, 51, 51); "><br></span></div><div><span class="Apple-style-span" style="font-family: arial, helvetica, sans-serif; color: rgb(51, 51, 51); ">I've heard StreamLine have recently been revoking merchant accounts that fall in to the "riskier" categories, even if the chargebacks are low. ugh.</span></div>
<div><font class="Apple-style-span" color="#333333" face="arial, helvetica, sans-serif"><br></font></div><div><font face="arial, helvetica, sans-serif">--<br>Sam Oliver<br></font><a href="http://www.thinkpigment.com" target="_blank"><font face="arial, helvetica, sans-serif">www.thinkpigment.com</font></a><font face="arial, helvetica, sans-serif"><br>
</font><a href="http://www.twitter.com/samoli" target="_blank"><font face="arial, helvetica, sans-serif">www.twitter.com/samoli</font></a><br>
<br><br><div class="gmail_quote">On Fri, Jan 28, 2011 at 3:44 PM, George Palmer <span dir="ltr"><<a href="mailto:george.palmer@gmail.com">george.palmer@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
My recent experiences might be useful here. A few months ago I<br>
integrated Chargify for a client on a project requiring monthly<br>
billing. It enden up taking a lot of effort and head banging because<br>
their service and API seemed to be designed with the assumption you<br>
could store credit card details. Without PCI compliance this forced<br>
you down their hosted pages route which wasn't nearly as functionally<br>
complete as the API. Whilst the Chargify guys were really good about<br>
answering my questions you could tell it wasn't their focus right now<br>
(understandably).<br>
<br>
A few weeks later I integrated recurring billing on my own<br>
application. I did this via PayPal adaptive payments and their<br>
recurring payments. It isn't perfect in the longest you can set a<br>
subscription up for is 1 year, but it did take much less time to deal<br>
with than Chargify. All the credit card number changes and refusals<br>
are dealt with by PayPal and you pretty much only have to stop/allow<br>
access when you get the various callbacks. That said there are some<br>
concerns with PayPal and most cases I've read of are where a sudden<br>
increase of volume of payments comes through in a short time. I'd be<br>
quite happy if they suspected dodgy behaviour on my account for that<br>
reason as I can see it raising a fraud flag. The problem I, and most<br>
other people have, is there's no way to contact PayPal and sort the<br>
issue out should it occur. 3 months seems to be the time it takes to<br>
get it sorted which isn't great. Ultimately I'd like to move away<br>
from them but right now the solution is good enough and not causing<br>
enough headaches to warrant the effort.<br>
<br>
With regards to getting approved at PayPal I used my ltd company<br>
account I've been freelancing through for 2 years and had no issues<br>
getting approved (although I did have to prod PayPal via twitter to<br>
get their arse in gear).<br>
<br>
George<br>
<font color="#888888">--<br>
George Palmer<br>
Founder<br>
<a href="http://www.digitaldeliveryapp.com" target="_blank">http://www.digitaldeliveryapp.com</a><br>
</font><div class="im"><br>
On 28 January 2011 15:30, Jason Green <<a href="mailto:jason.green@nogeek.org">jason.green@nogeek.org</a>> wrote:<br>
</div><div><div></div><div class="h5">> OMG that is a bad experience with google checkout.<br>
><br>
> We have built quite a number of sites here with many different types of payment gateways and billing management and I can say that the one that has disappointed the most is SagePay which has been consistently bad over the last year (service outages, invalid transactions etc,,,), paypal has been consistently good but thats just my experience.<br>
><br>
> I think you can create subscriptions in paypals merchant account to roll your own billing system?<br>
><br>
> Jason Green<br>
> <a href="http://www.dynamic50.com" target="_blank">http://www.dynamic50.com</a><br>
><br>
><br>
> On 28 Jan 2011, at 15:21, Paul Wilson wrote:<br>
><br>
>><br>
>> On 28 Jan 2011, at 15:13, Jason Green wrote:<br>
>><br>
>>> Maybe I am missing the point here, but why not use paypal, or google checkout (if you don't need recurring)?<br>
>><br>
>><br>
>> The plan up until this morning was to do recurring. Circumstances have forced us to reconsider, and we're kicking off with PayPal.<br>
>><br>
>>><br>
>>> Paypal does recurring: <a href="https://www.paypal.com/uk/cgi-bin/webscr?cmd=p/xcl/rec/subscr-intro-outside" target="_blank">https://www.paypal.com/uk/cgi-bin/webscr?cmd=p/xcl/rec/subscr-intro-outside</a> and also micro-payments.<br>
>>><br>
>><br>
>><br>
>> Yes, but that involves "rolling our own billing system".<br>
>><br>
>><br>
>>> When you get to the stage that paypals' 5% is loosing you more than it would cost to implement a proper payment gateway, the company bank account would be showing a healthy enough balance and history to get verified / credit checked.<br>
>>><br>
>><br>
>> The risky side of PayPal is that (in my experience of dealing with them every year for the Scottish Ruby Conference) they are a massive and faceless bureaucracy that frequently suspends accounts with little warning or explanation. I think they are risky to rely on. Google don't seem to be any better(*)<br>
>><br>
>> (*) <a href="http://slash7.com/2009/03/26/google-is-evil-worse-than-paypal-don-t-use-google-checkout-for-your-business/" target="_blank">http://slash7.com/2009/03/26/google-is-evil-worse-than-paypal-don-t-use-google-checkout-for-your-business/</a><br>
>><br>
>><br>
>><br>
>> _______________________________________________<br>
>> Chat mailing list<br>
>> <a href="mailto:Chat@lists.lrug.org">Chat@lists.lrug.org</a><br>
>> <a href="http://lists.lrug.org/listinfo.cgi/chat-lrug.org" target="_blank">http://lists.lrug.org/listinfo.cgi/chat-lrug.org</a><br>
><br>
> _______________________________________________<br>
> Chat mailing list<br>
> <a href="mailto:Chat@lists.lrug.org">Chat@lists.lrug.org</a><br>
> <a href="http://lists.lrug.org/listinfo.cgi/chat-lrug.org" target="_blank">http://lists.lrug.org/listinfo.cgi/chat-lrug.org</a><br>
><br>
_______________________________________________<br>
Chat mailing list<br>
<a href="mailto:Chat@lists.lrug.org">Chat@lists.lrug.org</a><br>
<a href="http://lists.lrug.org/listinfo.cgi/chat-lrug.org" target="_blank">http://lists.lrug.org/listinfo.cgi/chat-lrug.org</a><br>
</div></div></blockquote></div><br></div>