Ask HN: Credit card payment within site | Hacker News Reader

Ask HN: Credit card payment within site

15 pointsyeti13 comments

We're running a web social network.

Right now our customers are directed to pay using Credit Card or Paypal on Paypals site, and redirected back after.

We'd like to keep customer on our site for credit card payments to increase completion rate.

How can we accept credit card payment directly within our site ?

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?

Appreciate any advice..

View on HN

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...

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.

Thanks, I have some reading to do :)

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

Cheers

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".

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.

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

+1 for Authorize.net. We've been using them for a few years and have been very happy with them.

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

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.

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

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

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.

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".

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...

Reply on news.ycombinator.com