If you want something simple without writing much code, go with PayPal. You'd expect some "horror stories" from a payment processor with 232 million accounts. Virtually all of them involve someone doing something that'd raise flags at any merchant account provider or bank, it's just that people think PayPal isn't a bank so they should be able to get away with anything. 10,000 horror stories still leaves 99.99% of users happy.
If you want to accept credit cards on your own site, you need to learn about PCIDSS compliance, you need to apply for a merchant account, and you need to a payment gateway that works with that merchant account.
It's well within reach of a lean startup. The application is usually a page or two long, you'll get approval from the underwriting bank within a week or so, and most MAPs also resell the payment gateway accounts so they set that up for you and you get everything at once. The fixed costs will be a statement fee and a gateway fee, $20-30 a month total.
It's terribly difficult to understand the fees you'll be paying with a merchant account. They're far more complex than whatever you get quoted will lead you to expect, and it's absolutely common for providers to change the fees on a monthly basis such that after a year you have no idea what you're paying. There can be dozens of classes of credit cards each with different rates when you charge them. My only advice for dealing with that is to try not to tie your code to your processor so that, when you grow enough for the fees to matter, you can shop around for a better deal.
You don't get to take shortcuts with the PCI stuff. The fine for a credit card being compromised from your server because you weren't PCIDSS compliant start at $500,000 per incident (paid to Visa/MC) plus legal fees and costs to provide credit monitoring to the victims.
If you accept credit cards directly on your site, you'll be required to fill out a self-assessment questionnaire and have a compliance scan against your server run on some basis. For most ecommerce setups, it'll be quarterly. What that costs depends on your merchant account provider; some contract with and pay a compliance company for you, others you have to pay some or all of the costs yourself, which can be a couple hundred dollars a year. SecurityMetrics seems to be the most popular service for the scans.
The technical part is easy. An Authorize.net integration will take you a couple hours at most. There are libraries for the popular payment gateways in every programming language known to man, and prebuilt shopping carts will have plugins/modules/whatever written by people already.
It's just like any other API. You POST some data to some server to make a charge/authorization/refund/etc and get a response to parse. If your app integrates with Twitter, you've already done much harder work than integrating a form with a payment gateway.
Here's my horror story, let me know if you can figure out where I raised a flag because I can't. I was using Website Payments Pro with Spreedly for over a year, when I applied for access to their Adaptive Payments APIs. After getting approved a few days later, all of my spreedly subscriptions started failing with the error that I had to include the CVV. You can't store CVVs so it was now impossible to process recurring subscriptions with WPP.
Multiple calls to PayPal were useless. They told me that when I applied for adaptive payments, they reviewed my entire account and decided to require that I always include CVVs. In over a year, I had almost no chargebacks so fraud shouldn't be the reason.
The next day I applied for Authorize.net and was accepted the following day. It's about about the same price as when I was with PayPal, but with none of the hassle.
In summary, if you want credit card based recurring subscriptions, PayPal is just as expensive, significantly more restrictive, has terribly designed APIs, a sandbox environment that doesn't work as often as it does, and is kind of like smoking next to a barrel of gun powder.
Authorize.net also offers a hosted option so that the merchant doesn't have to deal with the burden of PCI compliance. In other words, the merchant (you) never sees the credit card number.
Yes - which is why what webapps do is only authorize AND charge when something actually ships. Most payment gateways (including Authorize.net's other products like SIM) support this workflow.
The reason is because, to do something like AIM or CIM, payment gateways need to store CVV numbers as well, resulting in a very expensive level of PCI compliance.
I'm not extremely well versed with fraud semantics, but IMHO placing an authorize on a card reduces the risk of fraud, refusing to pay, etc.
They also have CIM, Customer Information Manager, where you send the credit card info (thus never storing it yourself) and you get back a token. Anytime you need to charge that card, you charge the token instead. PCI compliance is then on Authorize.net
Even if you aren't storing card information you still are subject to PCI compliance if the card information passes through your application/server. In the case where you are processing but not storing you would need to complete the SAQ-C questionnaire and still probably be subject to quarterly scans (the self-assessment where are you storing data is SAQ-D)
Pretty much every gateway has some kind of tokenization solution (or reference transaction solution) that accomplishes the same thing. They all call it something different and try to make it seem like it is unique, which can be confusing.
Unless you're also using one of those subscription-as-a-service startups to host the payment forms, no, PCI compliance is on you with CIM. The payment information passes through your server, so you're 100% required to meet all 200+ of the requirements of the standard, quarterly scans of your servers, etc. Secure storage is only one small subset of the requirements.
I asked software vendors we work with who had previously used PayPal for their e-commerce to list any issues or limitations they experienced when using PayPal. The following outlines some of the issues that they experienced. No doubt there are countless happy PayPal clients out there as well, these are just issues some have run into that everyone should at least evaluate.
“PayPal’s reporting is extremely limited.”
“Virtually impossible to use for serious businesses without extensive external code or a system to manage customer flow/cross/upsells.”
“You spend too much precious time on e-commerce tasks and way too little time on marketing and dev.”
“For business-to-business products, clients do not take you seriously as a potential supplier if PayPal is your main payment method.”
“PayPal has very strict rules about the orders they are willing to let through, so merchants end up with fewer orders going through/lost revenue. They are quite picky about declining certain credit and debit cards other services would otherwise accept.”
“I log into my PayPal account and what do I see? “For my protection” they have limited the ability of my account to withdraw or send money but most severely, they also disallowed the account to receive payments! Frantically, I go to MacGraPhoto’s buy page, click buy and see a message “The seller can’t receive payments at this time”. At about the same time I get an email from a potential customer that says that he can’t buy the bundle. In the server log I see other people trying buy the bundle and leaving. Lost sales. Not good. Not good at all. My PayPal’s page lists lots of things that I need to provide to PayPal regarding my personal identity and regarding the sales. Some requests are totally not relevant to the case or to our business…And, it’s totally impossible to directly talk to the people who actually decide…I receive another email from PayPal. The subject was new: “PayPal appeal denied”…So, now the money (most of which is not even ours but of our bundle members) is held for 6 months. Sure, they are “making every effort to minimize any disruption to your business”. Sure, no disruption at all…Needless to say, I didn’t get any response not after 72 hours and not after a week. I called support again and was told that they won’t respond me because my appeal was denied and they don’t reopen cases…I won’t be using PayPal to sell anything from now. They have grown too big to be efficient and caring for their customers. Quick to make totally disruptive decisions and to dismiss legitimate businesses without really taking a look at what it is…They took the liberty to totally halt our business, to cause lots of lost sales and a major cash flow blow only because we got successful with one promotion, after being their customers for a long time. Right, they “regret any inconvenience this may cause”. They are “making every effort to minimize any disruption to your business”. If you’re selling anything and use PayPal as your only payment option, I urge you to reconsider. They can cut your oxygen supply right at peak of your success, of course “for your own protection”…we decided to leave PayPal as our e-commerce service at Apparent Software and moved to FastSpring.”
“No branding on PayPal order pages means fewer purchases! My order page needs to blend in with the rest of my site or too many people will bail on us”
“No fulfillment support”
“Revenue is lost because a decent number of customers are located in countries PayPal won’t accept payments within for whatever reason.”
“As much as I like rolling my own solutions, it’s too complicated to offer quantity discounts, coupon codes, and multiple currencies on top of the PayPal API alone.”
“Tax responsibilities are on the client, ugh.” (US and EU VAT)
“Huge problems with spam filters on PayPal — we automatically send out logins once an order is processed yet a higher percentage is not received than is received.”
“They have virtually no fraud screening.”
“(PayPal is) more difficult to set up – documentation spread all over the place, and forum answers sometimes misleading”
“There is no support for discount codes/vouchers (this really surprised me)”
“No experience with (PayPal) customer service yet- but I’ve heard bad things”
“Their system is very clunky, as far as looking up orders, pulling reports, checking a history etc…”
“PayPal heavily favors the purchaser not the vendor selling, as in chargebacks or disputes etc.”
“I don’t get notification of orders on a consistent basis, I have to login and check orders daily”
"We sell off multiple sites with the same PayPal account and the reporting to figure out which sites generated which sales is a nightmare”
“Lacks professionalism”
“Their UI stinks, it takes me a while to figure out how to do things in their system”
“I have heard too much about PayPal’s abuses to trust them. When I see something where the only payment option is PayPal, I select a different option: not buying.”
“No ability to offer upsells (at least that I can figure out)”
If you want to accept credit cards on your own site, you need to learn about PCIDSS compliance, you need to apply for a merchant account, and you need to a payment gateway that works with that merchant account.
It's well within reach of a lean startup. The application is usually a page or two long, you'll get approval from the underwriting bank within a week or so, and most MAPs also resell the payment gateway accounts so they set that up for you and you get everything at once. The fixed costs will be a statement fee and a gateway fee, $20-30 a month total.
It's terribly difficult to understand the fees you'll be paying with a merchant account. They're far more complex than whatever you get quoted will lead you to expect, and it's absolutely common for providers to change the fees on a monthly basis such that after a year you have no idea what you're paying. There can be dozens of classes of credit cards each with different rates when you charge them. My only advice for dealing with that is to try not to tie your code to your processor so that, when you grow enough for the fees to matter, you can shop around for a better deal.
You don't get to take shortcuts with the PCI stuff. The fine for a credit card being compromised from your server because you weren't PCIDSS compliant start at $500,000 per incident (paid to Visa/MC) plus legal fees and costs to provide credit monitoring to the victims.
If you accept credit cards directly on your site, you'll be required to fill out a self-assessment questionnaire and have a compliance scan against your server run on some basis. For most ecommerce setups, it'll be quarterly. What that costs depends on your merchant account provider; some contract with and pay a compliance company for you, others you have to pay some or all of the costs yourself, which can be a couple hundred dollars a year. SecurityMetrics seems to be the most popular service for the scans.
The technical part is easy. An Authorize.net integration will take you a couple hours at most. There are libraries for the popular payment gateways in every programming language known to man, and prebuilt shopping carts will have plugins/modules/whatever written by people already.
It's just like any other API. You POST some data to some server to make a charge/authorization/refund/etc and get a response to parse. If your app integrates with Twitter, you've already done much harder work than integrating a form with a payment gateway.