
Ask HN: How are lean startups easily accepting CC payments? - rkalla
As a single developer that has only given "online payments" a cursory glance the whole dance of gateways, merchant accounts and front-end recurring management platforms like Chargify or Recurly make my head spin.<p>I'm not the biggest fan of PayPal (reading enough horror stories over the last decade tends to cool you on some companies), but if it's the best option out there I'll use it.<p>I'm curious what the other single-person startups or small team startups that don't have the expertise to do full integrations with authorize.net/Braintree/etc. are doing to collect recurring/subscription payments?<p>I am hoping I'm missing some amazingly simple "all in one" company out there where a user can just enter credit card details and be done. I'm avoiding Amazon Payments and Google Checkout because of the required "create an account" step that a few companies have blogged about mucking up their follow-through with new customers.<p>Any tips would be much appreciated.<p>Links for reference (for anyone else in this boat)
Intuit's full solution:
http://payments.intuit.com/products/online-credit-card-processing.jsp<p>PayPal's full solution:
https://www.paypal.com/us/cgi-bin/webscr?cmd=_wp-pro-overview<p>BrainTree's full solution:
http://www.braintreepaymentsolutions.com/services/recurring-billing<p>If anyone is using any of these successfully for subscription-based payments I'd love to hear about it. I spoke with someone at Recurly who (fairly?) pointed out that subscription management isn't the primary feature of any of these services, so some of the implementations are awkward; on that note I'm not ready (since I have little idea of how this business will do) to purchase more management layers like Recurly into my billing process until business picks up.
======
patio11
My opinion on this: it is _very_ difficult for me to add value via coding the
world's best possible rebilling user experience and backend admin code. It is
_orders of magnitude_ easier for me to add value via either marketing (which I
need to do more of) or adding features to the product that get it in the hands
of more customers.

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?

~~~
bryanh
I do believe a blog post about how to practically implement such things into a
framework (say Rails or Django) would do well.

~~~
TamDenholm
This is one of those instances where I wish everyone (specifically patio11)
could see how much karma bryanh's comment has.

~~~
kwis
I didn't mean to upvote you, I misclicked.

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.

~~~
rahoulb
Do the credit card numbers ever travel via your server? Even temporarily in
memory? If so you are liable for PCI-DSS section C, which is a LOT of hoops to
jump through.

Spreedly saves you from that.

~~~
kwis
It took us a couple hours to be in compliance with section C. If memory
serves, we dealt with a vendor who did a scan, made us install AV software on
our Linux boxes, and one or two other minor process adjustments. It wasn't a
big deal.

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.

~~~
dangrossman
I don't understand how Spreedly is somehow providing you a "return". They sit
on top of your payment gateway so you pay everything you would've paid
withluan in-house integration, plus Spreedly's fees. Coding your own
subscription billing is a one-time thing as well. Where are you saving money?

~~~
rahoulb
It may be a one-off cost but writing a billing system is still a few weeks
work. Pro-rataing on upgrades/downgrades, support for one-off overage fees,
refunds, credits. Plus dealing with the fallout when you get a decimal place
wrong in a tax calculation and accidentally charge a customer a hundred times
what you were supposed to (guilty).

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.

~~~
dangrossman
Maybe the math works out like that when you bill four weeks for a two day job.
Startups can and do find programmers that write robust billing code with those
features in a day or two. I've done it more than once. I run both ecommerce
sites and subscription web apps -- the billing code handles upgrades,
downgrades, pro-rating, one-off overage fees, refunds and credits. Once you've
done it once, doing it again and testing for another site is a few hours work.

------
lwalley
Hi there,

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...](http://support.chargify.com/kb/merchant-accounts-payment-gateways/how-
do-merchant-accounts-gateways-work-with-chargify)

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

------
qeorge
Horror stories you may have heard aside, I've setup PayPal's website payments
pro for many clients, with tremendous success. Never had any trouble with
them, and my PayPal rep has always been reachable by phone and very helpful.

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.

~~~
kingofspain
_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._

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!

------
tgriesser
Braintree is great, the API, docs, and client libraries are all great. I'm
using it for a subscription based product and couldn't be happier with the
choice, even if the minimum fees are a little higher than most, if you aren't
going to be able to cover a $75 minimum per month then you probably have
bigger issues with your business plan than your payments provider.

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...](http://www.braintreepaymentsolutions.com/services/multi-merchant)

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.

~~~
rkalla
Are you processing any international charges with BrainTree? In tsz's post he
mentioned that they don't help with that until you are doing serious volume of
sales and then they will handle international charges for you.

~~~
tgriesser
No, no international charges with BrainTree and none in the foreseeable
future. If that is a concern then it might be good to look at other options,
I'd assume you'll face similar difficulties with other processors (I could be
wrong).

------
kieftrav
My personal strategy has been to start out with paypal because it's super easy
to integrate, and then when you have enough sales, upgrade to something like
braintree. That way you wait until proof of concept and revenue before you put
down money on a better solution.

~~~
bigiain
+1

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

------
fastspring
Sounds like SaaSy.com may be what you're looking for. You can see a comparison
of SaaSy, Chargify, Recurly, etc. here: <http://saasy.com/matrix.php>

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...](http://techcrunch.com/2011/03/17/online-subscription-billing-is-
still-a-hassle-saasy-aims-to-change-that/)

------
teuobk
I know you mentioned not liking Amazon for the sign-up step, but in practice I
haven't noticed much of a fall-off because of it. I use Amazon's Flexible
Payments Service for taking small payments (<$2), and I've been pretty happy.

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.

------
speleding
My 3 year old site depends on recurring billing so this is something I've
researched pretty well. If you have many non-US customers, as I do, the short
story is that PayPal is really your only option. All alternatives depend on
credit cards, which are not nearly as common outside the US.

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.

------
andymurd
Payment processing is hard, so please give it more than a "cursory glance".
Put yourself in the shoes of a brand new customer - they have lots of
questions regarding your trustworthyness, billing process, refunds, pro-
rating, discounts, invoicing and more. It's your job to alay those fears and
be flexible in meeting their needs.

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.

------
sahillavingia
I use Stripe for Gumroad and it's amazing. Unfortunately, it's still private
for now.

~~~
dmazin
I'd give my left arm to get to use Stripe. I'm in the situation of the OP and
I'm neither ready nor capable of dealing with PayPal and merchant accounts.

~~~
robflynn
Same here. I'm gnawing at my face waiting on an opportunity to use Stripe.

------
salsakran
I'm using Paypal Pro payments + Recurly. Between the ease of opening an
account and ease of integration it made the slightly higher charges well worth
it. Recurly doesn't have drop in django integration, but I'll eventually clean
up and open source the subscription/registration app I'm using.

~~~
IgorPartola
I am doing something similar with Spreedly. There is a Django app for it, but
the API code is pretty messy (what do you imagine get_info() does?) If anyone
is interested, I can post my API wrapper to github.

------
MichaelGG
Are any of the solutions out there comparable to BrainTree? It's easy to
process CC's, even recurring, but it's a pain to do PCI compliance. If the CC
info hits your server, you're in PCI scope. BrainTree has the browser send the
info direct to them, then redirects with a token you can use to check
information and perform charges.

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?

~~~
IgorPartola
I am no expert on this, but from what I gathered of previous discussions of
this topic, is that if you are serving the form HTML, you need some form of
PCI compliance, even though the CC never hits your server. This makes sense as
any XSS attack would allow an attacker to lift the CC straight from the page.

~~~
pyre
Some processors ofter an option that allows you to redirect to a page that
they host for the cc information, and then back to your page for checkout.

------
gsiener
We went through this recently and decided that Braintree was a nice one stop
shop. Great hand holding through the set up process and lots of api/library
support out there.

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

~~~
robflynn
Chargify does not work with Braintree v2 API, as far as I know.

------
bitsm
Spreedly Core is a simple API-based product for processing payments and is PCI
compliant via transparent redirects (like Braintree). If all you're doing is
processing one-time charges, it might be a good option to consider.

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

------
ScotterC
I'm using Braintree combo-ed with Recurly. Makes it simple to start accepting
subscriptions. I'm a big fan of recurly and if I ever feel like coding my own,
I can use Braintrees. I built my own subscription payments for Paypal before
and to be honest I'd never want to use that code again. Subscriptions have a
lot more headaches then appear at first glance.

~~~
JoshTriplett
Braintree has their own system for recurring payments too; what made you
decide to use Recurly instead?

~~~
ScotterC
Knew the guys and realized how easy their product is to drop in with no setup.
Full interface for any non coder to use easily. Braintree's setup and site
aren't that easy or simple. If I want to put in the work, I'll fully switch to
Braintree

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

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

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

~~~
drndown2007
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

~~~
guac
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)

[https://www.pcisecuritystandards.org/merchants/self_assessme...](https://www.pcisecuritystandards.org/merchants/self_assessment_form.php)

------
MicahWedemeyer
Been very happy with Chargify, except that it's expensive, especially at the
start. However, it's scaled incredibly well with us. It's easy to update
subscriptions, look up transactions, and basically do everything we need to
do.

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

------
tzs
[Breaking this into multiple comments, because it is too long. The subsequent
parts will be replies to this]

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.

~~~
tzs
You get billed by your PAYMENT GATEWAY and your ACQUIRING BANK. (Open
question: if you got your MERCHANT ACCOUNT through an ISO/MSP, I am not sure
if you are billed directly by your ACQUIRING BANK, or if your bills will come
from your ISO/MSP). For pretty much all practical purposes, these are the only
entities you directly care about, I think.

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.

~~~
tzs
Now let us talk about recurring billing. I have not used any recurring billing
service, so can't comment on how those work, but here are some thoughts on
handling it yourself.

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!

~~~
rkalla
tzs, your write (tomb) was _unbelievably_ helpful... just finished reading all
of it.

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.

~~~
tzs
I'm glad it helped. Keep in mind that I don't know if I have it right. I
marked several open questions, and I probably missed many. I'm still hoping
someone with better information will offer corrections.

------
fierarul
Just wondering -- how many of the solutions discussed here are available in
the EU?

------
nickpinkston
We use BrainTree - who really worked with us more than others with our non-CC
optimal payment risk (manufacturing custom parts). Although, I don't like that
they're phasing out their ACH/EFT services...

------
seanharper
I started FeeFighters, which is like Kayak for merchant accounts.

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

------
colin8chSE
There's a lot of good options and great providers, each having their pros and
cons dependent on where you are in your lean startup "lifecycle".

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

------
colin8chSE
Especially important for lean startups when considering payment providers for
subscriptions is the ability to "take your customers with you" as you grow.
When using Paypal, Clickbank, Fastspring/ Saasly, they are the merchant of
record, so they "own" the customer data. If you ever want to move to a
different provider, get your own or switch merchant accounts... the customers
that signed up with these providers will need to signup for a new subscription
and submit their CC data again to transition them to your new provider. The
other option is you can continue to use these old providers for your existing
subscribers, and use your new providers for new customers, but that adds a
bunch of complexity for technology, customer support...

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://community.developer.authorize.net/t5/Integration-and-
Testing/Any-way-to-export-data-from-CIM/td-p/6264)

[http://www.braintreepaymentsolutions.com/blog/open-letter-
to...](http://www.braintreepaymentsolutions.com/blog/open-letter-to-the-ceos-
of-paypal-and-authorize-net-help-end-the-credit-card-data-hostage-situation)

~~~
fastspring
It's SaaSy.com, as opposed to Saasly :)

------
chrislomax
I don't think the payment process is anything that you can just glance over.
The CMS I have written accepts two forms of payment, SagePay and Commidea.

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

------
MBlume
We're using Braintree here at Loggly, and like it quite a lot. The API has a
neat little Python library that we use on our backend, and is pretty well
documented.

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.

~~~
rkalla
Thank you for the heads up on the technical aspects of integration. Will take
a peek at the JS.

------
pstack
I haven't setup payment processing since around 2002 or 2003, but it sounds
like things have improved considerably. Back then, around the only option was
Paypal. To get that to work (in any sort of automated fashion), you had to
utilize their API and write your own custom code to process all of the
communication with Paylal and your site and your database and to update
accordingly (to acknowledge payments, subscriptions, user status change, re-
ups, etc).

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.

------
marilyn
I have been considering FastSpring (<http://www.fastspring.com>), which has
recently added subscription payments as a feature. I'm interested to hear
about anyones experiences with them.

~~~
dcheong
I believe you are referring to <http://saasy.com/>

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

~~~
seanharper
The terminology of payments is so weird:

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

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

------
jerrya
I saw this company <http://www.memberdesk.com/> give a presentation last night
to tieaz. <http://www.tieaz.org/2011/04/13/rapid-angel-pitch-winners/> (they
were not the pitch winners).

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

------
wmboy
One option is Clickbank.

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.

------
rms
Paypal Pro is better than people assume. The rates are ok.

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.

------
pilib
I don't have much real world experience with card processing, but the last
time I looked, RBS worldpay offered a nice subscription models. I was planing
to delve into that, but the project I was involved in fell apart, and there
was no need for me to pursue more info.

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

------
ANH
I'm going to be launching soon with PayPal's Digital Goods Express Checkout
dealio. In theory, integration is simple, but I've found the documentation to
be lengthy, incomplete, and just plain wrong in some cases. I've had speedy
support responses, though. The Sandbox is handy, if clunky.

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

------
thankuz
Might want to check out: Chargify, Spreedly or Recurly

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.

------
willheim
Wow! The glowing reviews of Braintree really got my interested in them. So I
went to their site. The best I've seen yet! Really top notch. Info flows
clearly and plainly. Love it... except I'm in Canada. They don't service
Canada.

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

------
plasma
There are many payment gateway's out there (for example an Australian one is
<http://www.eway.com.au> \- never used them/no affiliation) that let you
process payments via API.

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

------
skprice
I am using cheddargetter and gravity payments for a soon to be launched site.
www.turlytag.com

------
iantimothy
As a developer based in Singapore, it seems that PayPal is the best option.
Would like to ask the international developers what options have they used and
to the US based companies - when are you bringing your awesome services
internationally?

------
MadQA
Take a look at 2checkout, they have some recurrent billing functionality out-
of-box.

------
base
most of the payment gateway integrations can be done in 1 or 2 days. For the
main ones like authorize.net/braintree/etc, you have tones of libraries and
snippets all over the web.

check activemerchant if you use ruby.

------
rgrieselhuber
Stripe

------
simonhamp
If you want to integrate with Spreedly, I'll do it for $500. Just say you saw
this post here on HN

------
mleonhard
Is anyone here using Money Bookers?

------
zackattack
assuming you already have a merchant account and gateway (which takes like a
day to get approved, assuming you don't have your social security card on
hand)... you can get integrated with Recurly in two days of intense
concentration.

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.

~~~
portman
>> which takes like a day to get approved

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.

~~~
zackattack
citibank business account

------
suking
Chase Paymentech. End of story. If you need to do recurring it's trivial to
write - no need for these subscription companies.

------
smil3y
google "square".

~~~
wiradikusuma
CMIIW, but square is for physical world transactions (that is, you swipe the
card).

