This strongly suggests that I should not be writing billing code, ever.

You need a bunch of pieces to do billing. I use Paypal Website Payments Pro to physically charge people's credit cards, and Spreedly to tell them when to do it. I interact with Spreedly through a REST API that is wrapped with a Ruby gem. My entire interaction with them is one form, three model actions (which handle account creation, status change, and expiry), and a callback for when customer status changes. This took me a few hours to implement, once. Aside from a bug on my side (not charging Mastercards because I am illiterate and failed to read their documentation correctly), it has been pretty flawless.

This seems to come up way, way too often. Would anybody be interested in a blog post about how to do it in a practical, pain-minimizing manner?

You lose the ability to tweak and test one of the most important parts of the customer acquisition experience. There's a >10% conversion rate gap between different checkout flows I've tested on one of my ecommerce sites.

I've written my own subscription code for Authorize.net; it's around 200 lines, pretty straightforward (take the form data, POST to authnet to create a customer profile, POST to authnet to create a payment profile to store the card, POST to authnet to authorize the first payment, display any errors, otherwise save the reference token to the database and display a thank-you). It'd be smaller if you used a library like ActiveMerchant. Rebilling is a 15 line script as a nightly cron job.

I've also done integrations with Spreedly and Recurly. I didn't find they saved me any time; I had to write lots of code to send them information about the customers and process all their postbacks that you simply don't have to write if you do the charges yourself. Recurly was also changing its pricing and publicly arguing with its customers at the time, which killed my trust in the company.

Outsourcing your subscriptions to one of these startups is a business risk. They will forever be able to hold your cash flow hostage if they want to. If, however unlikely, your account is suddenly closed or they raise prices beyond what you can afford, you not only have to rip out all the integration you did and find another way to bill customers, but you will lose some of your customers while you're explaining why they can't manage their subscriptions at whatever.com anymore and begging them to fill out another payment form so you can continue billing them through someone else.

I read a few posts on forums that if the customer financial data is ever on a page you wrote, you come under the realm of at least some PCI compliance because of a possible XSS attack getting that information out of your forms.

That made the hosted "checkout" pages seem a lot more attractive to me... curious how you handled this.

Thing is, everything PCIDSS says you have to do when payment data passes through your servers is security 101. If you're not already doing 90% of these things, you're just waiting to be hacked anyway. Instead of thinking of it as a burden for payment processing, think of it as something every professional online business should have been doing anyway.

Lots of bark, absolutely no bite. There is not a single case where a bank will shut you off and stop getting your processing fees.

I disagree with most of what patio11 said, and have found (like bryanh) that using ActiveMerchant with Auth.net was no harder than when I tried Spreedly.

As such, I'd pass on patio11's advice and instead just get an authorize.net account, integrate that, and forget about it for the next five years.

Spreedly saves you from that.

Given Spreedly's current prices of the lesser of $0.20/transaction or 2%/transaction, this minute quantity of work is currently providing us with a return of approximately $12,000/mo. (We had over 60,000 transactions in March.)

Cost: approximately 3 man-days.

Benefit: currently sitting at approximately 1 man-year/year and growing.

It's true that if we'd gone of business within 25,000 transactions, we would've been better off with Spreedly, but given the time, energy and money that we were committing to the business, optimizing for that case seemed absurd. As such we made a small bet that we'd succeed, and that bet is currently generating enough savings (as compared to using Spreedly) to cover an FTE. Some people might say it's a rounding error on the revenue (and I suppose that's true) but I view it as a small bet that is paying off at an enormous multiple.

You basically just need to follow some reasonable security standards. Firewalls, ssh/ssl admin terminals, no shared credentials, and then follow a basic security policy.

If your ops/DevOps guys are experienced pros, they're probably going to be pretty close to compliant, just out of habit. That said I guess it's not terribly hard to envision a scenario where there's no firewall, bad user access controls, and a host of other crap that could be painful to fix if you only have junior-level ops talent.

One of my clients paid $700 for Spreedly kickstart plus their percentage transaction fees, plus a couple of hours for me to integrate it. Significantly less money then three or four weeks of my time to write a billing app from scratch.

This may have been recommended in the other thread, but I don't recall it.

Doing the charges yourself is exactly the same, except you have a nightly cronjob to find the accounts that expire today and rebill them. I don't think there's enough material in this to warrant a post.

I'm one of the founders of Chargify. Whether or not you choose to use us (our focus is the management of recurring billing, products, coupons, proration, etc.), here is an article I wrote to help startups and SMBs understand payment gateways and merchant accounts:

http://support.chargify.com/kb/merchant-accounts-payment-gat...

If you just need to accept credit card payments of any sort, this is the foundation you'll need. PayPal Website Payments Pro is their version of gateway + merchant account, but frankly, after seeing hundreds of merchants choose this or that solution, I recommend other gateway/merchant account combos.

I hope it's helpful info.

Thanks.

--- Lance

Additionally, I've used their recurring payments product (extra $30/month tacked on to Website Payments Pro). Its also really easy. You just send the transaction ID from a previous payment instead of the CC data , and PayPal looks it up in their vault.

Only shitty part with PayPal is you have to offer payment via paypal.com as an option ("Express Checkout"), which means you get to code an extra checkout flow! But maybe you were going to offer PayPal as an option anyway, so that's moot.

Authorize.net is great too, especially if you already have a merchant account setup with your bank. Their API is also super easy, and supported out of the box by most shopping carts.

I've chosen not to use Recurly or Spreedly. Handling money is a bitch, I want a partner with deep domain knowledge who lives and breathes payments. Keep in mind if you store your billing data with one of these guys, and they close up shop - you're fucked. Do you want to depend that heavily on a business with no 800 number and < 10 staff?

At the end of the day though, you'll have to make the call yourself. You've got no reason to believe me, the blog posts you've read, or anyone else you don't know personally. This is your business, your life - you can't just punt this one to the crowd.

As I remember it, you also have to have a direct Paypal link on your cart page (if you have one) - that bypasses any checkout process you might have (though you can redirect them back for address etc after). A bit of a pain all told!

The fact that they give data portability is great and the "transparent redirect" is super convenient, knowing that i have practically nothing to worry about from the PCI DSS side of things. If I ever get to the point of needing it (which I may soon) it looks like they have the ability to manage multi-merchant accounts from the same system http://www.braintreepaymentsolutions.com/services/multi-merc...

Although I have heard great things about Stripe, really want to check that out soon. Also, after looking at the prices for Chargify or Recurly, it really doesn't seem to be that much of a value add for something that can be easily accomplished with the Braintree API.

PayPal is _absurdly_ easy to set up and start collecting money.

You do though, need to understand that Papal's main business advantage over banks is their automated fraud prevention/detection - if you do anything that might come close to triggering their automated systems, you need to watch out. In my experience, that's almost always been accepting payments significantly before shipping something that can be tracked. Pre orders often get accounts locked. Non physically shipped products (thing "digital downloads" - software, music, or ebooks) often get accounts locked.

If you're not doing that kind of thing, or if you're doing it and are prepared to put up with Paypal holding on to your money until they believe your customers are happy, then PayPal is a reasonable solution (we have a client who starts accepting pre-orders for e new edition of his book every October, and PayPal hang on to _all_ money put into his PayPal account until 3 or 4 weeks after the books start shipping in early January. This has been going on for 4 years now, exactly the same every year, but the client is perfectly happy with that situation, he's mainly accepting pre-orders as a way to more accurately guage how many copies to print in the first run, he doesn't need to have the money up front but it's a great way for him to know really firm minimum order numbers for the first print run. It's only when he gets drunk over Xmas/new year and starts ringing PayPal up and screaming "give me my fucking money!" at anyone who answers the phone that it's a drama, unfortunately _that's_ been going on for 4 years now too...

Tl;dr, use PayPal to start with. Never leave more money in the PayPal account than you're prepared to lose. Never leave that money in a bank account linked to PayPal either. Make sure you've got a backup payment method at least planned, that you can switch in sufficiently quickly that you don't go broke between when PayPal cuts off your money and the new payment system is in place (that means get your merchant account and Internet merchant ID applications in process _now_, not after you have a PayPal problem.)

SaaSy is all-inclusive, and once you see the list of features and comparison chart you realize that the basic services like Chargify, Recurly, Spreedly, etc. are actually missing 90% of the solution you'll need, leaving most of the software development and administrative work for you to do over the next couple of years. As opposed to leaving everything to SaaSy and being able to instead focus on growing your business.

For basic integrations, you can launch your subscription service in about 3 days and have the solution fully outsourced and handled by SaaSy, from your global taxes to chargebacks, payments, PCI, order and payment support, global currency payments, localized language-based order pages, fraud prevention, branded order and customer subscription page, cross-selling, subscription trial periods, etc. The list goes on and on, as SaaSy is truly an all-inclusive e-commerce and subscription management service that frees you up to focus on your business, and keeps you out of the complex e-commerce infrastructure business.

To see TechCrunch's take on SaaSy ("Online Subscription Billing Is Still A Hassle, SaaSy Aims To Change That"), see: http://techcrunch.com/2011/03/17/online-subscription-billing...

About 10% of the people who click the "buy it" button on my product get to the Amazon sign-in/registration page and then bail. Abandoned funnels always sting, especially so close to completion, but is a 10% abandonment rate worse than it would be for a more direct credit card payment system? I doubt it, though I admit that I don't have any solid data to support that assertion. Might be worth trying.

I am aware of the horror stories around PayPal but I haven't had any serious problems in the last few years and I do hundreds of (recurring) transactions per day with them.

That said there is a pretty long list of annoying bugs in PayPal's recurring billing solution and most of the bugs have been in there for years. The technical bugs you can work around, but the "usability" bugs are quite annoying:

* If a user changes his credit card it will cancel all his subscriptions, unless he follows a specific set of steps that he won't find out about until it's too late

* If a user want to change a subscription and uses a different account to log into PayPal than the one he signed up with he gets the unhelpful error message that his "subscription has expired"

* If a user has two or more subscriptions and tries to change one PayPal will present him with a list of which one to change. This is a list of cryptic numbers. If he picks the wrong one it is near impossible to correct without canceling and resubscribing

* There is no way to pro-rate a subscription: if someone makes an annual payment for bronze tier and a day later decides to switch to silver tier PayPal will not charge the new price until a year from now.

I could go one. There are also internationalizations issues but I guess those only apply when you are outside the US like I am. (E.g. If you are outside the US then all the amounts in messages to your customers get formatted with a comma as a decimal separator, even if your customers are in US and you have your language set to US English). I've filed a bunch of bug reports over the years but I've never gotten a bug actually fixed.

Paypal is great to get started but my experience is that you'll take a hit to your cashflow at some stage. They'll freeze your account, chew up a lot of your time and make you angry. That's part of the cost of doing business with Paypal, so if you need cashflow, accountability and legal protections then go with a bank.

In the early stages, don't be afraid to do a chunk of your billing work manually (producing invoices, providing refunds, calculating pro-rated charges etc). This will give you important insight into customer pain-points and you'll learn a lot about online payments too.

I've coded with both Authorize.net's and First Data's APIs, and Stripe is much, much better in comparison.

can anyone get me an invite :-)

Anything else out there like that? That is, all the flexibility of being able to run charges programmatically, without the overhead of being PCI compliant?

You can always decide to put Chargify on top of that if you want. Bonus -- if you end up getting a merchant account with your existing bank you can swap that in later. (Though you probably will get a better rate w/ Braintree).

Basically, your payment form posts to SpreedlyCore, which posts back to your server with a token. Your app can then perform the basic payment actions, including validation of the user's posted payment data (minus the sensitive info, of course).

The service supports several gateways, and you never see the customer's payment details. The API simplifies dealing with responses. The biggest pain is that it's XML-based.

Regardless, I got it up and working in about a day, and I am slow. :)

It's very easy to use, and though new, the team is very responsive, and the API follows most conventions of their Spreedly subscription service, which is more mature.

The only thing you need to bring is an SSL cert, but you were gonna do that anyway. :)

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.

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.

http://developer.authorize.net/api/sim/

Pretty nice if you want to do things like "we'll bill your credit card only when item ships", etc.

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.

http://www.e-xact.com/hosted-checkout/

https://www.pcisecuritystandards.org/merchants/self_assessme...

“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)”

It's vastly, vastly better than our experience with Amazon SimplePay/FPS

We've been accepting credit cards for about 10 years, but I've recently been looking into all of this because (1) I'm pretty sure we are getting reamed on fees by some of our current providers, and (2) we are starting a new line of business under a different brand name and want to set up credit card processing for it.

The following brain dump of what I've found out might contain some things of use to you.

First of all, don't feel bad if you find payment processing confusing. I've found no site or combination of sites that is able to explain what actually goes on and who all is involved in credit card processing. Braintree has some good attempts at explanations, but they are not complete. Other resources I've found explain some of the other parts.

Two things complicate this. First, many companies provide many different services. If a company is providing both payment gateway services and merchant account services, they tend to merge those in any documents they write, because they want you to end up using them for both. Second, there is inconsistent terminology. Different companies sometimes use different names for the same thing.

Anyway, putting together all that I've been able to figure out so far, these are the entities that have their hand somewhere in your credit card processing. I would love corrections to this. I think I'll try to put together at some point some nice diagrams in OmniGraffle and put this up on the web (after any corrections are applied). When I first use a term I'll put it in quotes, and than put it in all caps in subsequent items.

I'll write this as if you are using separate companies for everything that can be separate.

1. Your "customer".

2. The "issuing bank". This is the bank that issued the credit card to the customer.

3. You, the "merchant". I assume no explanation is necessary for this item. :-)

4. Your "regular bank". This is the place you have your normal business account, and doesn't have anything particular to do with credit cards. It's just a place you keep your money.

5. The "credit card associations" are organizations like VISA and MasterCard. VISA and MasterCard are owned by the ISSUING BANKS. I'll get into their role in a bit.

6. Your "acquiring bank". You have a "merchant account" with them. When a transaction settles, this is where the money from the ISSUING BANK ends up. The ACQUIRING BANK then transfers the money to your REGULAR BANK, after deducting their fees. The ACQUIRING BANK is a little confusing because it is not really a bank. Their main role in this dance is to provide you with a line of credit in essence. If you sell a bunch of goods, the transactions settle, and you grab the money out of your REGULAR BANK and disappear without bothering to ship product, it is the ACQUIRING BANK that ends up coughing up the money when your CUSTOMERS call their ISSUING BANKS and demand that their charges be reversed. (Accordingly, this means that your ACQUIRING BANK is going to give you the biggest financial colonoscopy in this process).

7. A "member bank" is a financial institution that had a relationship with a CARD ASSOCIATION that allows them to function as an ACQUIRING BANK for cards from that association.

8. An "ISO/MSP". Those stand for "Independent Service Organization" and "Member Service Provider". These are essentially affiliates of MEMBER BANKS. They can sell you a MERCHANT ACCOUNT from the MEMBER BANKs they are associated with. I believe that ISOs and MSPs are basically the same. ISO is the term VISA uses, and MSP is the term MasterCard uses. You might think it would be best to get your MERCHANT ACCOUNT directly from a MEMBER BANK, but from what I've read it is often actually cheaper from an ISO/MSP. Also, just because an entity is a bank doesn't mean it is a MEMBER BANK. For instance, if you go down to a REGULAR BANK like BofA or Wells Fargo, they will happily sell you a MERCHANT ACCOUNT, but they will be doing so as an ISO/MSP for some MEMBER BANK.

9. A "front end processor". This is an entity that is hooked up the the CARD ASSOCIATION networks and can actually conduct credit card transactions. Your ACQUIRING BANK has a relationship with the FRONT END PROCESSOR.

10. A "back end processor". This is an entity that can actually initiate the transfer of money (via the Federal Reserve system) from the ISSUING BANK to your ACQUIRING BANK. Collectively, I've seen many people call the combination of FRONT END PROCESS and BACK END PROCESSOR a "payment processor".

11. A "payment gateway". This is what your shopping cart actually talks to, or (if you are actually physically accepting cards and swiping them) what your terminal is connected to. Its job is to accept requests from your cart ("Charge $49.95 to 5105105105105100") and then communicate with the FRONT END PROCESSOR that has a relationship with your ACQUIRING BANK in order to get the transaction conducted.

Here's what I've gathered is the actual flow of a payment. It is possible to do an "authorization", which in geek terms just puts a temporary lock on the funds at the ISSUING BANK which you then follow up with a separate "capture" transaction to finish the sale, or you can do a combined authorize and capture. Let's assume the latter.

1. CUSTOMER places order on MERCHANT's web site.

2. MERCHANT sends the information to PAYMENT GATEWAY.

3. PAYMENT GATEWAY talks to PAYMENT PROCESSOR.

4. PAYMENT PROCESSOR talks to the CARD ASSOCIATION.

5. CARD ASSOCIATION talks to the ISSUING BANK, which decides if it should approve the transaction.

6. The result goes back to the PAYMENT PROCESSOR, and then back to the PAYMENT GATEWAY, and back to the MERCHANT (and you presumably inform the CUSTOMER of the result, too).

7. The PAYMENT GATEWAY keeps track of all the approved transactions. At the end of the day, it takes all of these, and passes them to the PAYMENT PROCESSOR for "settlement". It is the BACK END PROCESSOR that deals with SETTLEMENT, by using the Federal Reserve system to initiate a transfer from the ISSUING BANK to the ACQUIRING BANK. (Open question: does the PAYMENT GATEWAY talk directory to the BACK END PROCESSOR for this, or does it talk to the FRONT END PROCESSOR, which talks to the BACK END PROCESSOR?).

8. A few days later, the money actually ends up at ACQUIRING BANK, they take out their fees, and deposit the remaining amount in your REGULAR BANK.

(Open question: is the ACQUIRING BANK involved anywhere before step #8?).

Now let's talk a bit about fees. The CARD ASSOCIATION takes a percentage. There are over 100 different rate categories the CARD ASSOCIATIONS have, based on all kinds of details about the transaction. Porn? Higher rate. Restaurant? Higher rate. No zip code? Higher rate. CUSTOMER using a rewards card? Higher rate. (You didn't think the ISSUING BANK paid those rewards, did you?) And so on and so on. This percentage is called the interchange rate. This only applies to approved transactions. You don't pay on declines (which can be significant for a business using recurring billing). You do not pay this directly to the CARD ASSOCIATION. It will be on your bill from your ACQUIRING BANK. This is often called the "discount".

The ACQUIRING BANK takes a per transaction charge. $0.30 is typical for VISA and MasterCard. You pay this for both approvals and declines. A typical ACQUIRING BANK is also going to hit your with a bewildering list of other charges that apply to some of your transactions but not others. Some of these will be fixed per transaction fees. For example, I'm looking at our bill from one of our ACQUIRING BANKS right now, about about 90% of the VISA transactions had something called a "VISA AVS FEE" of $0.01 added.

Others are percentages. 5% of our VISA transactions had something called a "VISA INTERNATIONAL ACQUIRING FEE". This looks like it was 0.45% of the amount charged. There was also a VISA INTERNATIONAL SERVICE ASSESSMENT fee of about 0.4%. I believe these fees happen when someone outside the US orders our product using a VISA or MasterCard. E.g., when a Canadian buys our product. I see MasterCard is only hitting us for one 0.4% fee for these, not two like VISA sneaks in.

(You also get screwed on charge backs from foreign customers using VISA and MasterCard. If you sell a Canadian something for $50, and they do a charge back, you'll find the charge back amount is something like $55. The bastard ISSUING BANK makes you pay the $5 they charged their CUSTOMER on the first transaction for doing currency conversion).

ACQUIRING BANKS have two different ways to deal with the INTERCHANGE rate. One way is called "interchange plus" pricing. The way this works is that they charge you whatever the CARD ASSOCIATION rate was for that transaction, plus their fixed fee. I've read that this option is generally only available to high volume MERCHANTS. For the rest of us, we get "tiered pricing". The way this works is the ACQUIRING BANK defines a set of tiers, typically called "qualified", "mid qualified", and "non-qualified" for a three tier system, and assigns a rate to each. For instance, the rates might be 2.3%, 2.6%, and 2.9%. The ACQUIRING BANK will take each transaction, and charge you the lowest tier that exceeds the INTERCHANGE rate for that transaction. The difference between INTERCHANGE and the tier rate goes to the ACQUIRING BANK, of course.

I suspect that some ACQUIRING BANKS kind of mix "interchange plus" and "tiered" pricing. The bill I'm looking at is hitting us for a 2.32% "discount", and then hitting us with an extra 2.4% on ones they call "non qual" and 0.9% on "commercial-rewards" cards. The "non qual" sounds like it is part of tiered pricing, but the separate ding for rewards cards, and the ding for international acquiring mentioned earlier, sound like things that would be factors in setting the interchange rate. Or these could just be how they do their tiers. In the summary they split the bill into two parts, "Discount Due" which is just the 2.32%, and "Fees Due" which is everything else.

As many who have looked at credit card processing have noted before, this is apparently not designed to be clear. If you can't figure out what things cost, it is hard to figure out if you can save money elsewhere.

The PAYMENT GATEWAY also charges. Their fees tend to be a lot more reasonable--typically a simple $0.10 per transaction. Looking at the PAYMENT GATEWAY bill for the PAYMENT GATEWAY we use for transactions destined for the ACQUIRING BANK I was using for my above examples, it is one page, with basically one line that says we had X transactions, and since their first 1000/month are free, we owe for X-1000, which is $X/10-100.

Remember when I said earlier that some companies play more than one role? If your PAYMENT GATEWAY is also your ACQUIRING BANK (or is the ISO/MSP that got you your ACQUIRING BANK), they often include the PAYMENT GATEWAY service for free as part of the package.

Now let's talk for a few moments about how you actually talk to the PAYMENT GATEWAY. You mentioned a lack of expertise to integrate with Authorize.Net or Braintree. I suspect it is a lot easier than you think it is. To integrate with Authorize.Net, you just do a routine post to a CGI. They give examples in ASP, C#, ColdFusion, Java, Perl, PHP, and VB.NET. I just looked at the PHP sample--it is literally just fill out a form and call curl. They have PHP, Ruby, C#, and Java SDKs, too.

Braintree is almost trivial, from what I've seen. (We haven't used them yet, but are considering them for our new product, so I've looked at their API). You want to charge a card from PHP? Include one PHP module Braintree provides, and then you just call one simple function to charge a card. The only flaw I can see in Braintree's API is that they don't have a Perl interface, and our back end software that processes orders is in Perl.

In the above I was assuming a model whereby you collect the card information via a post to your cart, and then something on your server makes the call to Authorize.Net or Braintree. There is another way, perhaps more suitable for you.

In this way, your cart does NOT post the credit card to your server. It posts to Braintree (I'll just do Braintree for this more, although the others all support something similar). Braintree's servers directly receive the information from the CUSTOMER, and do the transaction, and then they respond to the CUSTOMER's browser with a redirect that takes the browser back to your site. It includes information about the fate of the transaction, so you can respond appropriately.

The beauty of this is that you never touch the card, which really really really simplifies PCI compliance, and it looks pretty easy to implement.

First, there is the obvious way. Store credit cards yourself, and then you can run new transactions through when it is time to re-bill someone. You don't want to do this. This gets you all the way into the PCI cesspool. In fact, if you are a single developer, and there is no one else in your company, I'm not even sure it is possible to do this. PCI requires that for key operations on the encrypted credit cards that you use some kind of scheme that requires more than one person to authorize any operation. (We use Shamir's cool secret sharing algorithm to make it so no one person has access to the keys). Hard to do this when there isn't another person!

The second way is to use something called a "reference transaction". When you do a transaction, there is a transaction ID associated with it. Subsequently, you can do new transactions and instead of supplying the credit card number, you can tell the PAYMENT GATEWAY that you want to use the same credit card as a prior transaction, and supply the transaction ID of that prior transaction. (I believe you have to also supply the amount of the referenced transaction with some gateways). So, if you just keep track of the transaction ID of the last successful charge on a card and the amount, you can use that for your re-billing transactions. (Keep track of the last success, because you generally can't use a transaction more than a year old as reference transaction).

The main downside that I see for reference transactions is that you are stuck with that PAYMENT GATEWAY for subsequent transactions on that card. (Open question: if you use the same PAYMENT GATEWAY for more than one MERCHANT ACCOUNT, is the reference transaction tied to the original MERCHANT ACCOUNT, or is it just tied to the PAYMENT GATEWAY. I think it is just tied to the GATEWAY, because the way I've read it works is that the PAYMENT GATEWAY actually stores the credit card). For some businesses, you want multiple MERCHANT ACCOUNTS, and you want the ability to decide on a per transaction basis which one to use to bill or re-bill a customer, and so reference transactions won't work unless you have a suitable transaction at each gateway. (The reason for this is ACQUIRING BANKS can get skittish--remember they are the ones assuming the risk that you are going to stay around. If anything unusual happens to your business, ACQUIRING BANKS sometimes suddenly slap harsh limits on you).

The third way is to use Braintree and use their "vault" service. That costs $20/month plus $0.01 per card stored/month. Basically when you put a card in the vault (which you can do by setting a flag when you charge the card), they remember it for you. They give you a token that you can use on subsequent charges to represent the card.

You might wonder how this differs from using reference transactions at other PAYMENT GATEWAYS. After all, if PAYMENT GATEWAYS normally keep the full card information for each transaction, and let you do reference transactions, why should it cost extra for that service at Braintree. I think the key is that Braintree will let you get the cards out of the vault if you want. That's one of their big selling points--nothing you do with them locks you in.

As I said, we don't use any third party recurring billing service. When we got started, there really weren't any services specializing in that like there are now. There were recurring options at some of the gateways, but they were pretty simple, and unfortunately we had complicated plans, and let customers upgrade and downgrade between them leading to all kinds of ugliness that didn't fit in with any sane recurring billing system.

One other thing to be aware of with recurring billing (whether handled yourself of via a third party). Both VISA and MasterCard a service that allows MERCHANTs to get updated information on credit cards. For instance, suppose you try to re-bill someone, and it is declined. The last expiration date you had for their card was six months ago. You can query the updater service, and if the card has a new expiration date, or if the account has a new card with a new number, they might tell you the new information. They don't always tell you--the possible responses are (1) here's the new expiration date!, (2) here's the new card number and expiration date!, (3) the account is closed, or (4) no information is available. It costs nothing to submit a batch of cards to the update service, and something like $0.12/card for which updated information is returned, and they require you to run your entire database of stored cards through the service periodically.

I believe there are some restrictions on who can actually use this service, as it would obviously be a great boon to people who are doing credit card fraud. Ask any recurring billing service you are considering if they have any support for the updater service. If you can get access to it, it should easily pay for itself. We've found that it increased our success rates for recurring billing by around 2% or so.

Finally, let us consider foreign currency. Braintree offers a truly impressive number of currencies that they can accept payments in, and an impressive number of currencies you can have your settlements in. Unfortunately, you have to be doing something like $3 million a year (I assume they mean in the particular foreign currency you want to accept) before they will deal with you. (You need a separate merchant account for foreign currency, and the MEMBER BANK providing the foreign currency merchant accounts isn't interested in us small guys).

We use WorldPay for foreign sales (specifically the part of them that was once a separate company called Bibit). They will deal with much smaller companies than Braintree, but they have some pretty high fixed monthly fees--high enough that you'd almost surely want to get your business going well in the US before considering adding foreign support with WorldPay.

Based on all I've seen so far, I'd go with Braintree, for three reasons:

1. Assuming they are telling the truth on their site (and they get mentioned enough that if they were not on the level, surely someone would have posted about it), their prices are both very reasonable and actually understandable. You will pay one of the two tier percentages per transaction plus $0.30 + $75/month + $20/month (for the vault) + $0.01/month (per credit card in the vault) + $0.10 per recurring subscription billed. The only unknown in your costs will be what percentage of your transactions get the 2.29% rate and which percentage get the 2.89% rate.

You can find places that advertise less than 2.29%, but that will be just for the bottom tier of their tiered billing, and most will also stick on a ton of other fees (recall my example earlier from one of our bills from one of our ACQUIRING BANKs).

2. They offer both MERCHANT ACCOUNTS, PAYMENT GATEWAY, and a recurring billing system, so you will only have to deal with one company.

3. If you decide someday that you'd rather be elsewhere, you aren't under a contract so can quit with no penalty, and you can get your CUSTOMER's card data out of their vault to feed into whatever other provider you switch to (or to store yourself if you have gone insane).

Good luck!

As you walked through all the examples I was slowly leaning towards BrainTree and as you kept going through the reasoning I felt like I concluded at the same place you did by the end; sounds like the perfect thing to launch with and if I want better sub handling I can always add something like Recurly later.

I have no love for merchant account banks after reading all that.

I had no idea where the "points" on reward cards were coming from, very sneaky!

Fascinating read, I can't imagine how long it took to write up. I really appreciate that.

Regarding pricing, it's true there are less expensive-appearing services (though don't forget that without SaaSy handling everything for you you'd still have to pay 3.5-4% in e-commerce merchant fees for every order, once you factor in the true costs), but they end up costing you far more when you factor in software development costs and the years you will spend if you go it alone or use an existing basic service that appears to cost less. Remember, it's not just building what you think you need today, it's also adding on to it endlessly as your needs grow and change, and then there's the maintenance. That's just the tech development side, what about dealing with taxes, say in the EU if you have any EU customers, or a dozen other similar issues you'd otherwise be on your own to figure out and then develop a solution for? Take a look at this matrix to see what the cheaper, more basic solutions are missing that SaaSy provides for those launching or running existing SaaS businesses, and you'll see why SaaSy is actually quite a deal relative to the basic recurring billing services: http://saasy.com/matrix.php

In addition to saving you all the time, money, and hassle of building your own e-commerce system, the incremental profit you'll earn from utilizing our features for growing your average order size, lifetime value, and optimizing your conversion rate far outweigh the higher fees. Each feature you take advantage of can increase your revenue by a few percent, and it doesn't take too many increases of 2-4% here and there to add up to an overall profit improvement that far outweighs the few extra points that Saasy's all-in-one service costs. For example, cross-selling; upselling; add-ons; bundling; discounts & promotions; order pages in local currencies and languages; Facebook/Twitter referral management; a breadth of payment methods available for your customers; an order page customized to fit the rest of your site or designed to fit your preferences; the ability to test and tweak different order page structures and merchandising ideas; reseller management; analytics; outside help with PPC, SEO, affiliate, and general web marketing; fraud protection, and the list goes on. And then there's the impact our phenomenal customer service will have on your churn rate and the word-of-mouth sales it generates to have so many "wowed" end users out there talking up the customer experience of working with you. SaaSy also reduces your internal support expenses as they relate to order and payment customer support, since we handle that for you.

If you're up for spending up to a couple of years building and improving on an e-commerce infrastructure, SaaSy isn't for you. But if time to market is important and you'd rather focus on developing your product/service and doing sales and marketing instead of dealing with the distracting complexities of building your own e-commerce system either from scratch or by building all the needed functionality around one of the cheaper, more basic solutions, then you'll want to take a close look at SaaSy.

When you view our features list and the competitive matrix, think through the costs of developing your own infrastructure over the next few years vs. what your development team could instead be focusing on, factor in that you're not going to need to pay the 3.5-4% in e-commerce merchant fees for every order which you would be doing otherwise, consider not only the reduced expenses but the new revenue you'll now be able to generate, and you'll start to see why our rates are actually quite a deal, saving you money, helping you to significantly grow your revenue and to thrive relative to your competitors.

I have seen a lot of misery from folks who used the recurring API of the gateways (such as auth.net, braintree, etc).

If you are going to do recurring payments either roll your own using tokenization (its not that hard if your billing logic is simple), or use Recurly/Spreedly/Chargify.

A big advantage that a lot of people don't immediately recognize is that using R/S/C gives you a really good CRUD for your users/subscriptions/payments/etc. Building out that interface properly isn't a good way to spend your time (spend it on customer facing stuff!).

About Simplified Ecommerce: We specialize in subscriptions and our goal is to support a merchant throughout their entire lifecycle; finding product- market fit before they have a merchant account (similar to clickbank or fastspring), affiliate marketing to accelerate their growth, transitioning to their 1st merchant account and switching or adding merchant accounts as they scale.

Throughout their lifecycle, adding or switching a merchant account is as simple as submitting new merchant account credentials. All their custom hosted payment pages, integrations, pricing plans, affiliate relationships, reporting...remains intact. All customer data is stored in our independent level 1 PCI compliant gateway vault and is fully portable.

Our primary market is the non developer. Although Recurly, Spreedly/ Spreedlycore, Chargify and others have great, robust API's, we offer simple copy & paste "Buy Now link" type integrations. Merchants can customize hosted payment pages, switch merchant accounts, add subscription plans and set up affiliate programs in minutes, with just a few clicks. We also provide the consumer interface so subscribers can cancel, up or down grade their subscriptions without any additional integration or programming by the merchant.

I'd love to hear your feedback and happy to answer any questions. We are planning to expand our private beta in the next couple months, contact me if you're interested- Colin at SimplifiedEcommerce.com

This isn't a unique issue with "merchant of record" companies, gateways like Auth.net have a real issue with this too, check out: http://community.developer.authorize.net/t5/Integration-and-...

http://www.braintreepaymentsolutions.com/blog/open-letter-to...

There are lots of good examples for SagePay in most languages. I found Commidea to be the worst integration I have ever had to do.

If you use SagePay iFrame as I do then you do not ever touch the credit card, it all is handled in an iFrame and they authorise the card etc. This gets you round the PCI DSS requirements.

All you need is a couple of pages to handle post backs etc to tell SagePay where to send the authorisation details etc.

The problem you will have is with membership. If you're in the UK then its hard to get a bank or merchant to allow you to take 1 year memberships and take payment for them. If for whatever reason your site fails after 6 months then it is the bank who has to pay back the membership money. For this reason, I use Paypal for membership items

The indirection involved in posting billing forms to them means you wind up doing some interesting gymnastics if you want to include a billing form as part of a larger user signup form. You may want to check the JS on our paid signup page -- go to https://www.loggly.com/register/#woodpecker do an inspect element on the submit button, and expand the inline script a few lines down. The script creates an (unfunded, inactive) user on the server, receives a token pointing to this user to use in posting to braintree, and then posts the braintree form.

It wasn't as complex as I had feared it was going to be, but it was far from simple and farther from ideal. Especially since they had a habit of changing the API and the automated services over time.

I also never liked that you had to kick users out to the Paypal site at some point, to facilitate the payment.

It is a bundled payment gateway+merchant. You don't have to get PCI compliant and you don't need a merchant account (no min transaction volumes, fight chargebacks for you etc).

The down side is they only offer hosted payment pages and not suitable for everything... You need a finite set of goods/services you want to sell (eg monthly plans). You can't automate the process if you're building an online store where your customers can upload items for sale (eg AppStore).

Payment processors refer to their business customers as "merchants".

Entrepreneurs ALSO refer to their payment processors as "merchants".

Some samples: "I'm going to come out and say it: FastSpring is awesome. I haven't experienced customer service this good in my life. Every query I've had, from stupid questions to difficult questions to bug reports has been dealt with brilliantly." - Daniel Kennett, kennetnet

“FastSpring is definitely the best company I have ever interacted with (note: the best company ever, not just related to e-commerce).” - Ruman Stankov, Triland Inc.

Caveat emptor, I am merely passing the link along, but I believe what they are trying to provide is making subscription membership easy.

No need for a merchant account and they easily handle affiliate commissions (if that's something you want).

Downside is that people will see Clickbank.com on their credit card statement, not your merchant name (but that's the same with a basic PayPal account as well).

Upside is they have a very good track record at processing recurring payments successfully (much better than PayPal) and they don't freeze your account like PayPal or Google Checkout does.

There are lots of Paypal horror stories, but Paypal is actually on the side of merchants more than most merchant account providers. Yeah, chargebacks suck, but you have to deal with them with or without Paypal.

Also, with Paypal Pro you get your money right away; a lot of merchant accounts require you to wait a month or more before withdrawing your money.

I'm not doing subscriptions with Paypal Pro though.

I believe that since they would handle everything transaction wise, you don't have to worry about being PCIDSS compliant.

If Braintree had a micropayments option I would almost certainly have tried to go with them.

I also read a great post on setting up payments the right way, on the cheap, but I can't find it now. Will post if I do.

One nice thing about PayPal is you can use them for Offline, Web and Mobile payments - there are pros and cons to consider, might want to contact a few companies and explain your needs.

So, anyone got a Braintree-like company in Canada they can reco?

I'd be inclined to pick something like that rather than use Paypal.

check activemerchant if you use ruby.

but if you just want to start taking customers' cash ASAP, you can do that with a paypal hosted button in about 5 minutes.

WPP lets you accept credit cards w/ paypal - no paypal acct necessary - and there's tons of sample code out there that's basically copy and pasteable, and lots of code monkeys are familiar with the intricacies of paypal integration.

Which bank did you use? My experience has been that if you're doing ANYTHING other than e-commerce, it's a long uphill struggle. I've tried Chase, B of A, and Wachovia.