TE
TechEcho
Home24h TopNewestBestAskShowJobs
GitHubTwitter
Home

TechEcho

A tech news platform built with Next.js, providing global tech news and discussions.

GitHubTwitter

Home

HomeNewestBestAskShowJobs

Resources

HackerNews APIOriginal HackerNewsNext.js

© 2025 TechEcho. All rights reserved.

Ask HN: Credit card payment within site

15 pointsby yetialmost 15 years ago
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..

8 comments

revoradalmost 15 years ago
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 (<a href="http://chargify.com" rel="nofollow">http://chargify.com</a>) are very useful to get up and running quickly (if you already have a merchant account).<p>Here's my list of bookmarks from earlier discussions on the subject on HN:<p><a href="http://news.ycombinator.com/item?id=1392842" rel="nofollow">http://news.ycombinator.com/item?id=1392842</a><p><a href="http://news.ycombinator.com/item?id=33322" rel="nofollow">http://news.ycombinator.com/item?id=33322</a><p><a href="http://news.ycombinator.com/item?id=526517" rel="nofollow">http://news.ycombinator.com/item?id=526517</a><p><a href="http://news.ycombinator.com/item?id=1206993" rel="nofollow">http://news.ycombinator.com/item?id=1206993</a><p><a href="http://news.ycombinator.com/item?id=12010" rel="nofollow">http://news.ycombinator.com/item?id=12010</a><p><a href="http://news.ycombinator.com/item?id=175186" rel="nofollow">http://news.ycombinator.com/item?id=175186</a><p><a href="http://news.ycombinator.com/item?id=294120" rel="nofollow">http://news.ycombinator.com/item?id=294120</a><p><a href="http://news.ycombinator.com/item?id=598920" rel="nofollow">http://news.ycombinator.com/item?id=598920</a><p><a href="http://news.ycombinator.com/item?id=530055" rel="nofollow">http://news.ycombinator.com/item?id=530055</a><p><a href="http://news.ycombinator.com/item?id=1065419" rel="nofollow">http://news.ycombinator.com/item?id=1065419</a><p><a href="http://news.ycombinator.com/item?id=975301" rel="nofollow">http://news.ycombinator.com/item?id=975301</a><p><a href="http://news.ycombinator.com/item?id=616417" rel="nofollow">http://news.ycombinator.com/item?id=616417</a><p><a href="http://news.ycombinator.com/item?id=526517" rel="nofollow">http://news.ycombinator.com/item?id=526517</a><p><a href="http://news.ycombinator.com/item?id=1381918" rel="nofollow">http://news.ycombinator.com/item?id=1381918</a><p><a href="http://news.ycombinator.com/item?id=432284" rel="nofollow">http://news.ycombinator.com/item?id=432284</a><p><a href="http://news.ycombinator.com/item?id=526517" rel="nofollow">http://news.ycombinator.com/item?id=526517</a><p><a href="http://news.ycombinator.com/item?id=948036" rel="nofollow">http://news.ycombinator.com/item?id=948036</a><p><a href="http://news.ycombinator.com/item?id=1515677" rel="nofollow">http://news.ycombinator.com/item?id=1515677</a><p><a href="http://blog.meatinthesky.com/introduction-to-online-payments-tldr-its-a-to" rel="nofollow">http://blog.meatinthesky.com/introduction-to-online-payments...</a><p>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.
评论 #1537322 未加载
wrsalmost 15 years ago
These threads always seem to need the following debunking: The PCI compliance requirements are not reduced just because your servers don't <i>store</i> CC numbers. If they even <i>see</i> 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".
arthurdentalmost 15 years ago
I am almost done implementing cc payments on a small app I'm doing, and it was my first time.<p>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".<p>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".<p>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.<p>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.
评论 #1532030 未加载
评论 #1537028 未加载
karsaalmost 15 years ago
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 : <a href="http://www.pcicompliance.org.uk/" rel="nofollow">http://www.pcicompliance.org.uk/</a><p>This site offers both for 198 GBP which is a bargin.<p>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.<p>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.<p>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.<p>for more advice contact <a href="http://www.merchant-advise.co.uk/" rel="nofollow">http://www.merchant-advise.co.uk/</a><p>best steve
waterside81almost 15 years ago
We use Website Payments Pro on our site (shameless plug - <a href="http://www.littleheroes.com" rel="nofollow">http://www.littleheroes.com</a>). 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.<p>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 &#62; $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).<p>Plus they allow you to export your entire transaction history to CSV so you can load it into your own accounting system.<p>Strongly recommend PayPal to anyone who (A) can program and (B) wants to keep customers on their site.<p>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.
评论 #1534248 未加载
shib71almost 15 years ago
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.<p>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).<p>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.
waivejalmost 15 years ago
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".
bmralmost 15 years ago
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?<p><a href="http://wufoo.com/2009/10/08/say-hello-to-paypal-payments-pro-and-usa-epay/" rel="nofollow">http://wufoo.com/2009/10/08/say-hello-to-paypal-payments-pro...</a>