

Ask HN: Credit card payment within site - yeti

We're running a web social network.<p>Right now our customers are directed to pay using Credit Card or Paypal on Paypals site, and redirected back after.<p>We'd like to keep customer on our site for credit card payments to increase completion rate.<p>How can we accept credit card payment directly within our site ?<p>1) Is Website Payments Pro (or alternative) easy to integrate with?
2) Does it allow recurring subscription as well? 
3) Can you remember credit card and then able to auto-bill people as part of a "top up" function?<p>Appreciate any advice..
======
revorad
I would like to know the answer to this too. I think WPP does allow recurring
payments and CC data storage. I hear services like Chargify
(<http://chargify.com>) are very useful to get up and running quickly (if you
already have a merchant account).

Here's my list of bookmarks from earlier discussions on the subject on HN:

<http://news.ycombinator.com/item?id=1392842>

<http://news.ycombinator.com/item?id=33322>

<http://news.ycombinator.com/item?id=526517>

<http://news.ycombinator.com/item?id=1206993>

<http://news.ycombinator.com/item?id=12010>

<http://news.ycombinator.com/item?id=175186>

<http://news.ycombinator.com/item?id=294120>

<http://news.ycombinator.com/item?id=598920>

<http://news.ycombinator.com/item?id=530055>

<http://news.ycombinator.com/item?id=1065419>

<http://news.ycombinator.com/item?id=975301>

<http://news.ycombinator.com/item?id=616417>

<http://news.ycombinator.com/item?id=526517>

<http://news.ycombinator.com/item?id=1381918>

<http://news.ycombinator.com/item?id=432284>

<http://news.ycombinator.com/item?id=526517>

<http://news.ycombinator.com/item?id=948036>

<http://news.ycombinator.com/item?id=1515677>

[http://blog.meatinthesky.com/introduction-to-online-
payments...](http://blog.meatinthesky.com/introduction-to-online-payments-
tldr-its-a-to)

EDIT: If you are based in the US, you have a lot of options to choose from.
I'm in the UK, for which I find it slightly more difficult to find
information.

~~~
yeti
Thanks, I have some reading to do :)

The company is based in HK, so have to filer out the non US company options..

Cheers

------
wrs
These threads always seem to need the following debunking: The PCI compliance
requirements are not reduced just because your servers don't _store_ CC
numbers. If they even _see_ the numbers, the requirements are essentially the
same. To avoid PCI hassles while maintaining control over the UI, you need to
use something like Braintree's "transparent redirect".

------
arthurdent
I am almost done implementing cc payments on a small app I'm doing, and it was
my first time.

Advice: First, read revorad's list. I basically found as many HN posts as I
could on the topic. They didn't help me come to a decision at all, but they
gave me some background information on the topic. They weren't helpful for
making a decision because for the most part it seems like a lot of people just
said "I did X and I'm happy with the solution".

There seems to be a lot of pricing misinformation on the topic. The threads
contain a good deal of "Braintree is the best and works with customers" AND
"Braintree is expensive and hard to work with".

My experience: I went with Authorize.net. It was easy to set up my account and
I had my account in 4 hours after an online application process. I found
shopping for the best pricing difficult because I really don't have a good
handle on how much (if any) business I'll be doing and the pricing structure's
seem to lack transparency. I got really close to spending 2 days researching
and I'd rather just take the easy solution now and work on the app.

I think its easy to get mired in "finding the ideal solution" especially at
this juncture, but its more important to find a good enough solution that lets
you move on.

~~~
revorad
Wow, 4 hours sure sounds fast! Do you know if I can use Authorize.net as a UK
company (with a UK bank account)?

------
karsa
You will need to be PCI compliant This can be done very cheaply if you know
what your doing and do some sys admin yourself. The tools to complete this
involve a PCI scan and SAQ wizard : <http://www.pcicompliance.org.uk/>

This site offers both for 198 GBP which is a bargin.

The next thing is you NEVER store the card details on your sever, instead your
(merchant account) payment gateway provider will issue you a tokenID or
sometimes you tell them the token ID that is used for recurring billing etc.
and that way you only have to verify the card details once, typically a charge
of £1 or something small then you get the token id store that in your DB and
use it for all transactions, that way you never store card numbers and all is
posted only once across ssl.

Depending upon the features you have on your site you may find it difficult to
get a merchant account and payment gateway provider to accept you.

For example if you have any live chat features or webcams that would raise a
flag and place you into a very high risk and potentially impossible place to
get an account.

for more advice contact <http://www.merchant-advise.co.uk/>

best steve

------
waterside81
We use Website Payments Pro on our site (shameless plug -
<http://www.littleheroes.com>). I cannot say enough about how great their API
is. I have Python code if you'd like, but it's really just straightforward
POST. You can do subscriptions and one-time payments, as well as doing pre-
auths.

And it's great because customers don't leave your site. You can withdraw the
money from your PayPal account to your bank account anytime for free, so long
that the amount is > $150. Otherwise they charge a small amount (can't
remember, $5 maybe?). PayPal's fees are much better than many merchant account
providers I've found. We pay $30/month for the account and then 2.9% + $0.25
for each transaction (so for a $100 transaction PayPal takes $3.15).

Plus they allow you to export your entire transaction history to CSV so you
can load it into your own accounting system.

Strongly recommend PayPal to anyone who (A) can program and (B) wants to keep
customers on their site.

As for PCI compliance and all that, why would you ever want to open up that
bag of hurt and store people's credit cards? Let PayPal do what it's good at
and stick to what you're good at.

~~~
damoncali
Just don't ever try to call them for support. It is awful. Simply awful.

~~~
Skyline
If you do enough volume, they assign you a dedicated support rep.

------
shib71
I can only offer my experiences: If you have a merchant account it is
relatively easy to sign up with a processing gateway and process transactions.
The ones I've worked with had clients we installed on our servers, but I
believe they were just wrappers for encrypted web services. The whole process
is complicated by two things: regulations about user information (particularly
credit cards), and international credit cards.

Storing credit card numbers - some countries have regulations around online
transactions. Simply not storing the numbers (or only the last 4 digits, for
auditing) was fine for us (Australia FYI). I think the alternative was a
number of encryption schemes. We also had to do an expensive audit of our
network/website security (because of our revenue? I can't remember).

International customers/cards - take this with a grain of salt (we were mostly
targeting domestic users), but I believe this depended on your gateway and
bank. I suspect it's because of the difficulty of identifying fraudulent
transactions - it's much simpler if the pool is a single country.

------
waivej
There was a good talk by the Adafruit folks at HOPE this weekend. They
mentioned using Authorize.net and not storing the cc numbers on their own
site. I don't know if the video has been posted yet, but check www.hope.net.
It covered all sorts of aspects of running their ecommerce site/marketing. I
think it was called "running an open source hardware company".

------
bmr
My understanding is that you can use Wufoo and PayPal Pro to keep users on
your site AND not worry about PCI compliance. Seems too good to be true. Am I
misunderstanding this page?

[http://wufoo.com/2009/10/08/say-hello-to-paypal-payments-
pro...](http://wufoo.com/2009/10/08/say-hello-to-paypal-payments-pro-and-usa-
epay/)

