
Why we ditched PayPal for Stripe - gtaylor
http://gc-taylor.com/blog/2011/12/8/why-we-ditched-paypal-stripe/
======
michaelschade
The post is spot on.

My initial attraction to Stripe was because of a reason mentioned in the post:
not wanting to redirect or otherwise interrupt the normal order process of my
site with another company's (branded) checkout form just to handle credit card
payments. The other reason for initial attraction was of course their elegant
API, which was very refreshing to see after having dealt with Intuit's QBMS
API ( _shudder_ ) in the past.

Stripe really sealed the deal though when I tweeted them to ask my first
question about signup and one of the co-founders reached out to me. Since
then, I've been in contact to share my feedback or ask other questions, and
the quality and timing of their responses is one of the best I've ever seen.

When a customer of ours had an issue placing his order, I wrote Stripe to see
if they could offer any insight as to what errors they might be seeing on
their end. While the error was unrelated to Stripe itself, they were so
awesome that they actually took the initiative to browse through our checkout
page and point out the spot that they thought to be the issue.

A company that stands beside you when debugging your checkout page,
maintaining swift response times on an issue that isn't even theirs? _That's_
customer support.

I probably sound like I'm gushing right now, but I just have mad respect for
this company. The product isn't the only thing that's top notch, the people
behind it rock too.

~~~
saurik
You almost always get amazing customer support from early stage companies. I'm
certain people got amazing customer support from people high up at PayPal when
it was just starting. You cannot judge a company on whether a co-founder
responds to you on Twitter in a short period of time, and if you did, you
should probably judge it negatively: I would wonder what was wrong with PayPal
if someone that high up had enough time to be sitting around checking Twitter.

(edit: I typed this over too long a period of time, and some of this post
appeared after I had already submitted a draft with the above paragraph that
received some upvotes, so I've now edited again to add this edit paragraph to
explain that everything after this point was added after I received said
upvotes. ;P)

Also, I'm very curious about their API... I didn't see much information on
chargebacks. Processors like Litle & Co make it very easy to fully automate
the chargeback representment flow. PayPal, incidentally, does /not/ provide
this either, but they do have APIs that let you (with only some hoops to get
through bugs that I've filed with them, and we may see fixed fairly soon)
correlate and track all of the chargebacks and how they relate to your
transactions.

Yet, when Stripe first started appearing on Hacker News, their website seemed
to have almost no information on chargebacks. I asked after this, and the page
"appeared" with an apology that it was supposedly there but not linked, but it
then had very little information on it. I still (checking again now) see no
information on how I'd determine /which/ transactions had chargebacks
automatically: they seem to seriously rely on sending an e-mail? Why does
their API page never once mention the word "chargeback"?

~~~
michaelschade
That's somewhat a fair point, but I'll disagree.

In that instance, the co-founder replied, but I've heard from a number of
Stripe's other employees since then, and in every case the customer support
has been wonderful. Perhaps that's solely because they are still a startup,
but given what I know now about the people themselves, I don't believe that to
be the case.

I don't mean my original comment to suggest that the co-founder will always be
the one to respond to a tweet as Stripe grows, but I do suspect that their
standards for customer service will remain high, and _someone_ in the company
will give a quick and quality response. That said, with Stripe, I believe
that–even if they aren't the ones responding to every tweet, which is
admittedly much to ask–the co-founders will continue to have an eye on what
people are saying about them and interact appropriately, not wall themselves
off.

 _Edit to reflect your edit_ :

I remember that HN thread where you brought up chargebacks. For anyone
interested, they discuss how they handle chargebacks here:
<https://stripe.com/help/chargebacks>

I can't attest as to why they manage chargebacks that way, and will not
speculate beyond the note that they are still new and seem to be developing
their service in response to customer feedback and perceived needs.

For you, or anyone else who might be interested in requesting features
regarding chargebacks or any other aspect of their service, I highly recommend
writing in: support@stripe.com or <https://stripe.com/help/contact>. As I
mentioned, they're very responsive, and seem to love the feedback.

~~~
saurik
I am curious if you've ever actually called PayPal. I have received nothing
but high quality support from them. You can call them throughout most of the
working day (until 8pm PST, I believe), and they seem to have somewhat
knowledgable engineers available at that tech tier. They also have a merchant
technical support site that seemingly no one knows about where you can often
get answers in the middle of the night (I often get responses back at 12:30).
If you are even reasonably sized you can also ask for a dedicated account
manager: I have the cell phone number of someone at PayPal whose job it is to
find me answers to problems I have.

Though, I cannot say PayPal is perfect. I have run into a bunch of annoying
issues correlating settlements (bugs filed recently, will be curious to see if
they get fixed), and their pricing is not the best that is out there (although
is still better than Stripe). I am curious if you've looked into any
alternatives. I've spent the last few days talking to Litle & Co, and I must
say that the people there /love/ talking to you about payments... their booth
at ad:tech was the most enjoyable conversation I've had about payments in a
while, and I got to spend another half hour on the phone with them yesterday
learning more about how bank ACH settlement works.

 _Edit to reflect your edit ;P_

That is the page I just had gone and reviewed now. It still seems incredibly
manual. I would not feel comfortable running a site at scale where I'm dealing
with receiving e-mails in an undocumented (probably designed-for-humans)
format as my only source of notifications for chargebacks. :(

It is often these "at scale" issues that are seemingly not handled by them;
example: per their API page, Stripe does not resend webhooks if there is an
error in the response... doesn't this make them useless to rely on? Am I
required to sit around and poll my transactions to feel 100% certain that I
didn't miss something because my load balancer accidentally gave them a 503
during some traffic spike? :(

~~~
michaelschade
I have called PayPal once before. The experience wasn't horrible, but it
didn't leave me enthusiastic like Stripe's does. I'm not holding that against
them though: it's only one mediocre experience, and I have not used them much
because of the whole payment redirection thing (I did not know about their
_Pro_ account then).

To be clear: I'm not actually saying that PayPal is bad. I don't have enough
experience with them to weigh in one way or the other. I am merely saying that
I _do_ like Stripe.

I'm not sure of Stripe's reasoning behind not resending webhooks, but I don't
know that I care for them not resending them either. Perhaps this is something
they'll be addressing in the future or otherwise have a legitimate reason.

~~~
kamaal
_I have called PayPal once before. The experience wasn't horrible, but it
didn't leave me enthusiastic like Stripe's does._

Well, talking of facts small companies with a small customer base will always
deliver better customer service than the larger ones. True test of these
companies will come when their subscriber and customers run into millions(In
paypal's case hundreds of millions).

Imagine a situation where where 283 million registered customers and probably
more unregistered buyers. Ensuring operations related to that magnitude of
people work fine for 99.99% of the people, 99.99% of the times. And then
ensuring the remaining get appropriate customer support is not just difficult
but requires a lot of work to maintain and run.

At that scale the founders will have a lot more different work to do. And
addressing one user out of those hundreds of millions by communicating them on
twitter might not scale properly. And the customer support employees are
working in call center shifts. They are not going to be any more enthusiastic
any more than other general call center employees.

Coming to arcane policies, Now for all those millions of users. There are
definitely going to some x% of crooks out there gaming the system. Frankly
speaking if you don't have such policies you may actually end up putting a lot
of your other buyers and other customers in trouble and expose them to fraud.
The problem is in programmatically handling hundreds of millions of users and
their problems is not easy. You can build a system to do payments et al, but
that's only beginning. So any good payment gateway etc will ultimately end up
looking like PayPal.

PayPal works at a scale, Whether a new competitor will work at scale is
question of time.

But don't write PayPal off, It actually works well for those hundreds of
millions of registered and more unregistered users.

------
templaedhel
The better question would be "why _wouldn't_ you ditch paypal for stripe?"

Stripe is much easier to integrate than the x.com/paypal.com family of
conflicting api's, all of which lack easy to read documentation.

[https://cms.paypal.com/us/cgi-bin/?cmd=_render-
content&c...](https://cms.paypal.com/us/cgi-bin/?cmd=_render-
content&content_ID=developer/howto_api_reference)

Compared to

<https://stripe.com/docs>

Stripe doesn't have a history of randomly locking accounts, and even if they
do (if you process payments, I can understand the legal need to now and then)
their customer support is so responsive and helpful I wouldn't really mind.

Stripe is easy to use. The web UI is fast, the api makes sense, I get joy out
of it.

Stripe sent me a real, physical letter, to thank _me_. I was one of the early
users of the beta, and we all got real letters, on thick cardstock, I wish I
had taken a picture of it. That may be a virtue of being a small userbase
startup, but if you start with that mentality, it means a lot.

Paypal does have slightly lower fees, but Stripe is worth it.

Paypal also makes it easy to add a paypal pay button to sites, but those a
fraught with stories of accounts shut down, and are ugly.

~~~
JoshTriplett
I can only see two reasons why someone might need PayPal rather than Stripe:
if the business resides outside the US, or if they need to take methods of
payment other than credit cards. Other than that, Stripe seems like a no-
brainer.

~~~
blantonl
Josh, you are failing to recognize other reasons why a business might still
consider using Paypal as their merchant account provider. Here are ours:

1) Costs. We pay 2.2% + $0.30 USD per transaction vs. Stripes' 2.9% + $0.30
USD per transaction. At our transaction rate, that makes a difference in
received revenue.

2) Moving. Refactoring a well established business to interface with a new
payment provider can be a costly and expensive process. Think of switching
personal banks.

3) Fraud. Paypal probably has the most advanced fraud protection in the online
business today. If you deal in any decent amount of online payments you will
find this to be a huge issue.

Additionally, we have our own dedicated Paypal account manager that actively
reaches out to us and keeps in contact, and we can instantly call a _direct
line_ to this person if we need assistance with an issue.

With that said, our team is actively looking at Stripe because we like the
ease of use when it comes to reoccurring payments, which we don't do at this
time but plan to implement in the coming year. From what we see, reoccurring
payments are a messy with Paypal and I'm not satisfied with Paypal's solution
compared to their competitors like Recurly, Chargify, and, well, Stripe. But I
am impressed with what Stripe has to offer on all fronts. Especially their API
which appears to be very easy to use. ...And, they have a nice looking
reoccurring payments process which fits our vision nicely.

Anyway, disclaimer: we run between 50K and 100K a month through Paypal, so
that is probably why we get fantastic support from them and better pricing.

------
LeBlanc
I'm the lead API engineer at WePay, so I'm definitely biased toward the WePay
API, but I do think Stripe is a great service.

The WePay API does allow you to embed the entire checkout experience on your
own site with our iframe checkout. The iframe contents are customizable
(header color, button color, etc), but as Greg mentions in the comments, it's
not quite as customizable as Stripe or another merchant account based system.

Unfortunately, even with Stripe, you are still liable for _most_ of the PCI
spec (our iframe checkout gets around this). We made a bet that there are a
lot of developers out there that who are willing to give up a little on the
customization side to not have to deal with the headache of PCI compliance
(we've gone through that process ourselves and it is complicated and
expensive).

~~~
mrkurt
Out of curiosity, how does an embedded iframe let you avoid PCI completely and
an external javascript lib not?

~~~
LeBlanc
The external javascript library is still being loaded on a page served from
your domain, so it's totally possible for you to grab the credit card data and
ajax it to your server (or for an XSS vulnerability to allow a 3rd party to
send it somewhere). Since the CC info is accessible to both the client and
Stripe, both are liable for PCI compliance. [edit: just to be clear, with
stripe, you aren't liable for _all_ of the PCI spec (just part), which is one
of the awesome things about the service]

With the iframe, the checkout form is served from WePay's domain, so
javascript on your page can't directly access elements on the checkout form.
There are still potential vulnerabilities such as clickjacking (we do some
things to protect against this), but since the CC form is served from our
domain, only we are liable for PCI compliance.

~~~
boucher
We at Stripe (and more importantly, our PCI auditors) don't agree with this
assessment of how the chain of responsibility works.

When you use Stripe.js, you need only serve your page over SSL and verify that
you aren't collecting credit cards through other means to be PCI compliant.

~~~
tptacek
We don't do PCI assessments (I have a generally low opinion of the process),
but we do the "real" appsec work for lots of companies that do, and the
impression I have is that --- counter to what you'd expect --- 'boucher is
right, and you can self-assess using their interface, despite the fact that
anyone doing so is in fact an XSS flaw away from giving up cards.

In particular, while I have no idea whether Stripe's implementation is letter-
of-the-law PCI compliant, I do know that 'LeBlanc's reasoning is not PCI
reasoning (particularly: you can't draw a line from architectural
susceptibility to "liable to audit") --- even though it's the reasoning I
myself would use.

~~~
lsh123
Interestingly, PayPal actually offers (or offered?) an iFrame checkout for
some customers and it was confirmed to be PCI-compliant. But again, another
PCI auditor might have another opinion on it :)

~~~
shivang
Paypal actually offer a Embedded payment experience which in no sense gives
the feeling of embedded payments on the website.
[https://cms.paypal.com/us/cgi-bin/?cmd=_render-
content&c...](https://cms.paypal.com/us/cgi-bin/?cmd=_render-
content&content_ID=developer/e_howto_api_APIntro)

On this link you can find the experience of Embedded payments, i implemented
it on our site but the docs on the api are not complete on paypal, rather
complete they are not present at one place.

------
james33
I don't really consider Stripe a replacement for PayPal. You don't accept
PayPal because it can process credit cards, you accept PayPal because millions
of people want to pay with it. Don't get me wrong, I hate PayPal just as much
as the next guy, but unfortunately it isn't a viable option to stop using it
in favor of simply accepting credit cards right now (though Stripe is an
awesome product!).

~~~
garyrichardson
Very true. Here's another example:

My wife sells knitting related things (patterns, books, yarn) on ravelry.com.
They collect the payment for her and transfer the money to her paypal account.
I suspect it will be a while before stripe can do such a thing.

~~~
latchkey
If ravelry.com used WePay, each time someone bought one of her amazing works
of art, the money would be deposited directly into a FDIC insured account that
your wife controls.

From there, your wife could transfer the money directly into her own regular
bank account.

If ravelry.com goes out of business before they transfer the money to her
paypal account, there is no chance that they can take any of her money with
them. (While highly illegal, I've seen this happen elsewhere with a similar
setup.)

~~~
slashclee
*ravelry, not raverly

~~~
latchkey
Fixed. Thanks. Must be my old school raver roots. Heh.

~~~
holdenk
raver you say? Do you know of any good bay area raves?

------
dcaldwell
From what I understand, one of the differences between WePay and Stripe is
that WePay allows marketplace transactions where the app creator can take a
cut of the transaction (similar to Paypal's adaptive payments API). I don't
believe that Stripe allows marketplace transactions. WePay doesn't currently
handle the dunning process for recurring payments but they plan to do so at
the beginning of the year. Stripe currently handles the dunning process. At
Bellstrike, we use WePay's API and have had nothing but good things to say
about them. Their customer service is outstanding and we always have access to
their developers, usually within minutes. We're getting ready to implement
their iFrame solution as well. I've talked to some others that are using
Stripe and they are pleased - particularly with the fact that Stripe only
requires the credit card number and expiration date for a transaction - no
other info. I guess it just depends on what you're looking for but I'd
recommend WePay from my experience. We had a terrible time with PayPal.

~~~
gtaylor
I too heard lots of great things about WePay. They seem like a great shop.

As you've noted, there are some differences in feature sets on both sides.
However, perhaps there will be some convergence in the future. Both services
are very young, and improving very rapidly.

------
wenbert
Both WePay and Stripe are US only.

[https://www.wepay.com/Does-WePay-allow-international-non-
US-...](https://www.wepay.com/Does-WePay-allow-international-non-US-payments)
<https://stripe.com/help/faq>

So for now, I am stuck with Paypal.

~~~
decadentcactus
I'm starting to think though, that it's a good opportunity for others in other
countries. Stripe, Twilio, Google Voice, probably a bunch of others.

------
MattBearman
I would love to be able to use stripe instead of PayPal, can't wait until it's
available in the UK.

Unfortunately they don't even have a timeline for availability outside of the
US yet - <http://twitter.com/#!/stripe/status/144951134795218945>

------
latchkey
WePay doesn't require you to redirect them to their site.

<https://www.wepay.com/developer/tutorial/iframe>

~~~
gtaylor
Perhaps "redirect" wasn't the best word to use. WePay does interrupt the flow
of your site with their own system, however:

"The iframe checkout lets you embed an iframe on your own site that will
contain the WePay checkout system."

With Stripe, we have 100% control over presentational stuff during checkout.

~~~
latchkey
Sure, if you want that level of control. In my case, I was happy to not have
to implement that part of things. It isn't a trivial amount of work to deal
with the credit card / address forms and get everything correct. I made the
iframe look like a part of my site well enough that people can trust it and it
saves me a ton of development time.

Your app appears to be in private beta, so I can't test that form to see if
you missed anything and post about it here. ;-)

~~~
billclerico
hey guys - bill from wepay here.

we contemplated building a JS solution as well, but using JS can place your
site within the scope of PCI compliance. (this is somewhat up for debate) the
reason we went with an iframe implementation is because it is firmly outside
the scope of PCI, and we are working on making it even more customizable.

either way, you are in good hands with stripe or wepay. (at wepay we are big
stripe fans - they rule!) to me, the big difference is whether or not you want
the money to settle to someone's bank account directly (stripe), or whether
you want it aggregated and stored in an online account first (wepay).

------
alapshah
I feel like I am becoming a ridiculous Samurai supporter in a world of Stripe
supporters on HN (odd because we know they have many large customers), but my
large (seasonal business, 8-figures a month for 5 months a year) contract
employer chose Samurai last month and we've been very pleased. We still are
splitting our transactions between them and another provider but we've been
very satisfied w/ Samurai thus far and will probably migrate all of our
transactions to them over the next couple of months. They have an amazing API
- can do the stuff referenced in the above article... See:
<https://samurai.feefighters.com/developers/samurai-js> and were fantastic to
work with. They also have a campfire room that is usually staffed and helpful

I ended up choosing them for my non-day-job gig as well (saas business) and am
very happy. Happy that both of these services exist, really.

------
moses1400
We switched to Stripe from Paypal and Google Checkout a month ago and so far
I've been very, very pleased. I plan to do a writeup of why we switched soon -
wanted a bit more results first. FYI, Stripe launched a new web interface 2
days ago.

The net bottom line was this: 1\. our customers (business people who are not
super tech savvy) just don't understand that you can pay with a credit card on
paypal and google checkout requires a google account 2\. the "go off and pay"
somewhere else and come back to the main site is messy

I have no real complaints with paypal over the years we used them so I can't
bash them but I found that over time, we lost sales because people were
confused. Now there is no more confusion - fill in a few fields and instantly
you are done.

We also considered Braintree which I was also impressed with but decided on
Stripe because of the non-need for a merchant account.

I am happy to answer any questions here or privately if needed.

~~~
philipsflat
Stripe does provide you with a merchant account (<https://stripe.com/terms>).
They just make it a simple process by asking for as little info up front as
possible. There's advantages to this such as a quicker sign up process. But
the disadvantages are that you may have issues if your company grows too fast,
if you get too large of a transaction size or a host of other risk issues.
Your best protection against these is giving the bank the option to perform a
thorough underwriting. Disclosure: I work at Braintree.

~~~
pc
I work at Stripe. This is pure FUD. If fast-growing companies really did
encounter problems with Stripe, don't you think at least one would have talked
about it?

------
mattmillr
"We investigated some traditional payment processors like Braintree and
Authorize.net ... A lot of traditional gateways have long, complicated setup
processes, often involving sales calls and working with banks. ... They also
typically require you to send credit card data through your servers, which
means obtaining a level of PCI Compliance (not that we aren't already
security-conscious)."

I've used both of these. Braintree may not have been the right choice in their
situation, but grouping them with Authorize.net for these reasons isn't really
fair. Braintree's bundled merchant account and gateway services are much
easier to set up, and their transparent redirect eliminates the need to handle
card data on your own servers.

And in my experience, their "We (heart) developers" motto is, well, true. They
have really great, friendly support. Braintree and Authorize.net are miles
apart. At least as far apart as Stripe and PayPal.

------
foxylad
The usual gripe - my company is based in New Zealand, and it's well nigh
impossible to open a US bank account so we can't use Stripe or Wepay. I'd love
to know how many of PayPal's merchants are non-resident, it's the only reason
we use them.

In fact, if it wasn't for PayPal non-US websites selling to the US would be
almost impossible. The US has a massive advantage in that the rest of the
world is happy to pay in US dollars, but US citizens won't pay in other
currencies.

So here's a very lucrative challenge, Stripe and Wepay: the one that figures
out how to allow non-residents to set up an account first simply has to post
the news to HN and will be flooded with new accounts. I'd switch within 24
hours if there was a viable alternative to PayPal.

~~~
Vivtek
In tepid defense of US customers - even US banks can't really figure out
foreign currency. We went to the bank in Bloomington, Indiana to exchange some
Euros we had laying around and they literally had no way to handle them. The
best they could offer was to _mail_ them to American Express. Or drive to the
airport in Indianapolis. And this wasn't a local bank, it was Chase
Manhattan's branch in Bloomington.

We ended up driving to the airport in Indy. No way am I just going to put a
few hundred Euros in cash into the mail.

------
jinushaun
More positive news about Stripe since the last time they were posted on HN.
<http://news.ycombinator.com/item?id=3053883>. I will give them a try on the
next e-commerce project I work on.

------
pbreit
I hear you. However I would like to point out that the two PayPal services I
designed 10 years ago, Web Accept and IPN, continue to work in the same way
they did a decade ago. I was fanatical about not breaking and not needing to
version.

------
adamtmca
Can anyone recommend something similar to Stripe or WePay for Canadians.

------
plasma
Please come to Australia; I'd love to use Stripe for new projects.

------
jakejake
I'm eager to try stripe myself but it wasn't right for our business due to the
transaction costs. We do anywhere from a quarter to half million per month in
transaction fees and it's amazing how those fractions of a percent and one
penny turn into thousands of dollars! We looked at losing about $20k per month
so it didn't make sense.

But I have a generic payment processor API that I wrote and I plan to add
support for stripe into that for personal projects.

------
JulianMorrison
Redirects are a _good_ idea. Redirects mean that you don't have to juggle
legally sensitive credit card data yourself, and your customers see a browser
indication that they are talking to the genuine Paypal (or whomever).

Paypal sucks, blocks your account and keeps your money on the least excuse,
and is a bureaucratic hell, those are good reasons to not use them. Redirects
aren't, IMO.

~~~
gtaylor
You don't need to choose between safety and no redirects. One of the major
points of the article is that you can not touch the credit card data yourself,
AND still get a 100% uninterrupted payment experience for the user.

Again, it's still early, but we are seeing better conversion rates so far. The
PayPal redirect gave some of our less technical users fits.

------
kemo
So how exactly do you replace Adaptive Payments with Stripe?

I'm probably missing out on something here.. I know that flaming PayPal is
popular nowadays but I can't find an alternative with both Authentication and
Adaptive Payments (which our app is completely based on)

------
edawerd
Can someone explain why Stripe doe not allow marketplace transactions but
WePay does? Is this primarily due to issues of fraud? If so, how does WePay
get around it?

------
80cols
Sounds like one of the main advantages of stripe is the API.

I wonder if anyone is working on making payments platform-independent so it's
easy to switch between payment providers.

~~~
gtaylor
Most of the gateway-style services operate very similarly. We wrote some
abstractions to allow us to eventually add Braintree or Authorize.net, since
the payment cycles are much alike (from the API perspective). It only gets
difficult when you try to mix-and-match something that uses redirects/iframes
with services that deal directly with credit cards from your server to theirs.

We just don't want to get into PCI audits and scans just yet, but once we do,
we'll probably use Stripe's direct server->server APIs like
Braintree/Authorize.net do instead of stripe.js.

------
phatbyte
Why on earth Europe doesn't have something like Stripe or WePay ?? This is
such an amazing opportunity, and I can see lots of people who would invest in
it.

~~~
gtaylor
Dealing with all of the banks, currency, and laws sounds like an absolute
mess. Each country does business differently.

------
treelovinhippie
US only. The only reason I hate living in Australia.

~~~
jandy
Or the UK. Bane of my existence.

~~~
Ankur84
We should setup a payments service that works everywhere, except the US.
Revenge ... kidding. Although given how dodgy the PayPal APIs are and that
future economic growth is likely to be based outside the US, it might be a
very viable business.

------
ssgrfk
Sigh. another great looking payments service thats only available in the US.
doesn't anyone want my ruples?

------
ggwicz
I'm not enough of a developer to integrate completely with stripe, but we've
been making the change to Dwolla.

Anything is better than PayPal. I appreciate their contributions to epayment,
but their time has passed.

Other great options out there include Square, MoneyBookers, and Dwolla (if
anyone is looking to leave PayPal after this article and the recent Regretsy
one).

------
irunbackwards
I was absolutely enthralled with the support I received in their Campfire
chat.

------
fastspring
You may want to also consider SaaSy.com: \- All-inclusive – hardly any
development work needed - More functionality - GUI-based for the most part -
Global tax/VAT management - Works with vendors in most any country - 10
currencies - 20 languages - Best customer service experience of your life

~~~
gtaylor
To be perfectly honest, this is pretty far from the discussion. SaaSy looks
expensive, and their website isn't even clear enough to see if they offer the
redirect-less single payment checkout.

I'm assuming this is just a shameless plug? Nothing wrong with that, but it
looks like you don't even have the feature set the original article is
discussing.

Edit: Oh, I see what's going on:
<http://news.ycombinator.com/threads?id=fastspring>

------
_exec
I cannot recommend Stripe enough. We will be posting a blog post about our
(seamless, instant) transition very soon. Kudos!

EDIT: By seamless, I mean "Sign up and get an API key", and by instant, I mean
"Read this article, sign up, instant activation, plug in API keys, start
charging, switch complete!"

------
LilValleyBigEgo
Why you'll be losing a lot of business

------
hm2k
<https://twitter.com/#!/hm2k/statuses/119216249774411777>

<https://twitter.com/#!/stripe/status/119221741259206656>

