FWIW, when Stripe launched they did not have any way to correlate chargebacks at all, nor did they offer separate authorization/capture phases (which is required to ship physical goods: you are not allowed to actually charge someone's credit card for a purchase you are shipping until you're about to actually ship the product). They also had rather weak webhook retry support (it would retry a couple times over short periods of time, if I remember correctly). They have since fixed these issues, but in the mean time their main benefits have been cloned by PayPal (easier to read documentation, and a JSON-based API that can be used from a browser).
Their prices were also fixed at the highest end of PayPal's fees (2.9% + $0.30), and while they now mention you can get volume discounts, they make it clear you shouldn't even attempt to discuss this with them until you are looking at over a million dollars processed every year. PayPal and Amazon, in comparison, list discount pricing on their websites for volumes as low as forty thousand dollars a year. Meanwhile, if your average receipt price is less than about $12, you probably aren't even considering Stripe, because PayPal will offer the same service to you with "micropayments" pricing: on a $1 purchase this will save you over 20% of revenue on processing fees.
I have not evaluated Balanced as a payments provider (I only remember them being usable for outgoing payments, not incoming ones; is this feature new? regardless, their pricing is as high as Stripe), but for the purpose of payouts you are looking at a tradeoff: they charge $0.25 per transaction, with $1 if the payment fails; in comparison, using PayPal MassPay costs 2% of the transaction cost, but is capped at $1. If you are building a large marketplace, and end up having to do a lot of dinky payouts, PayPal is going to be more cost effective. You also will have to file less paperwork using PayPal (you don't need to 1099-MISC someone if you use a third-party payment network, as PayPal will send a 1099-K instead, but you do if you use ACH), and will more easily be able to support international merchants.
I can't speak for anyone else, but the reasons we've chosen other providers over PayPal had nothing to do with their fees. I expect I'd pay 5% and shift all my existing business in a heartbeat, given a payment service that had:
1. a data model that wasn't oversimplified or awkwardly reported,
2. a decent API that also supported comprehensive automated integration tests, and
3. solid documentation and customer support.
No large, established company would pay 5%, obviously, but running small, on-line businesses without physical products, our priorities are different. A couple of percent of profit margin either way is nothing compared to the pain caused by accounting hassles and the lack of confidence if it's not possible to test an integration properly. In a small company, we're all doing everything, so any time we have to spend on accounting details or manual testing before we roll out an update is time we're not spending on things like marketing or feature development that actually make money.
Sure. I was responding to "It surprises me that anybody uses Amazon or PayPal when Stripe and Balanced exist.", not attempting to make the argument "It surprises me that anybody uses Stripe or Balanced when Amazon and PayPal exist.". You are welcome to make the choices you want to make, and if Stripe actually manages to accomplish that first bullet point for your use case, that's awesome (seriously). However, treeface was making the argument that the opposite was not true: that working with PayPal and Amazon never made sense due to the offerings of Balanced and Stripe being somehow better; I was explaining (with a "FWIW" even) why companies would want to choose these solutions.
Apologies if I misunderstood your point. You seemed to emphasize fees above almost anything else in your earlier posts, including suggesting that this would probably be the deciding factor in a PayPal vs. Stripe choice at a certain price point. I was only trying to point out that for the kinds of small business that a lot of these payment services are chasing, the rate they charge isn't necessarily the only relevant factor, nor even the most important one.
Sadly, I have yet to find a payment service that is anywhere close to meeting all of my three criteria, and that includes many of those that get mentioned a lot on HN. That is why if anyone made one, they would have my companies' business faster than you can say "integration". For now, we settle for a combination of helpful customer service and APIs that we can make work with enough effort, and we hope that in time the services offering those things will improve their limited reporting and testing facilities.
As for the underlying data models that most of these services use, I'm afraid most of those are probably beyond redemption, and sooner or later I can see that being a significant liability to the kinds of service that are useful primarily because they're low-hassle and let you get on with other stuff. (Friendly advice to payment services: If you bundle up a charge to my customer, any tax we have to charge them that you may or may not record, any fees you charge on that transaction, any tax you're including with those fees, any refunds that may be made on a later date and therefore in a different tax reporting period, any tax to my customer included in those refunds, any fees we get back as a result, any tax that no longer applies on those fees, any chargebacks that occur, any tax that no longer applies to my customer as a result of the charge back, any fees you're no longer collecting, any tax on those fees, any chargeback-related fees and how much you're spending on my Christmas present for putting up with this lot all in the same single transaction record in your database/API, then our accountants probably don't like you, and neither do the guys here who have to reverse engineer all of the real data that we need to do real accounts in order to make our accountants happy again. There is simple, and then there is too simple.)
You certainly don't do any real volume, because you can't pass 5% onto customers and if you absorbed it and did any real business it would be huge $$$.
Just curious, what do people do when part of their order can be shipped out now, and part of their order is being shipped by someone else in a different state and can't be shipped yet? And you might not know all this at the time of the order?
Authorize.net doesn't support partial captures on an authorization.
Is the best alternative to store their credit card and use that saved card to capture partial amounts? This would mean you couldn't do a full authorization upfront to ensure the customer has the funds available.
You are going to hate me for this, but: I guess you switch to PayPal ;P. The DoCapture API has a field CompleteType that can be set to NotComplete (as opposed to Complete) that lets you implement partial capture functionality.
1) Use a payment processor that supports partial capture.
2) Only capture when the shipping is complete.
3) Do a full capture, and refund promptly if you/seller can't ship the rest. This is technically not allowed but some merchants/platforms get away with it. The "prompt refund" part is very important, you don't want to end up with chargebacks.
> PayPal will offer the same service to you with "micropayments" pricing
Just a warning to anyone that reads this: Last I tried (February 2013), micropayments were completely broken. Payments would fail for any customer that didn't have enough to cover the transaction as positive PayPal balance (eg. everybody - I never have more than $0 in my PayPal account).
I'll have to agree with this. Don't get me wrong PayPal is not great and the horror stories are well horrifying BUT it has a pretty global adoption and customers are fairly likely to know it.
In fact in Germany (which I think is one of the most "anti credit card" countries) I know many people that will only buy stuff online if they can pay via bank transfer or PayPal because PayPal is simple and has a recognizable brand name.
I own a CC but there have been times where I had checked out stuff and didn't buy in the end because it was CC only.
Amazon has that same brand name advantage if it's easy to use for customers they have a good shot imo.
Stripe is still in private beta or non existent in many countries. I'm rooting for them but there are already clones coming out in countries where they are not available which might not be great for them long term.
I use both Amazon and PayPal but not Stripe or Balanced, mostly because I already have accounts set up with Amazon and PayPal. This is a huge barrier for new payment companies. To succeed, they need to both (1) be so much better than the competition that it's worth the hassle of making a new account and (2) communicate that to millions of people. These are not small problems.
I use Stripe for Draft, and I know I'm losing money. I get emails everyday from people outside the US who can't use a credit card or they don't trust any vendor with their CC. I'm probably going to have to add Paypal too :/
> I use Stripe for Draft, and I know I'm losing money. I get emails everyday from people outside the US who can't use a credit card or they don't trust any vendor with their CC.
I think you need to make a judgement (in the absence of hard data, which you often won't have before launching something!) on the types of users that might use your service.
For example: I'm building a service where the sole demographic is developers, and typically fairly savvy ones at that. I feel that I can get away with Stripe (credit cards) being the only payment option available because most of my users aren't going to be particularly averse to buying things online.
If I were selling physical goods, or SaaS with a diverse userbase, then I would certainly consider other options.
I am a developer, in Mexico. I have to jump through hurdles to pay some sites (Browserstack, dnsimple). I want to give you my money and even though I loathe PayPal it's the only solution that always works.
I agree with the other reply. Stripe would be ideal but when looking for international solutions, they just aren't there yet. We are looking into payment solutions to cover our LatAm customers and it is very difficult right now.
As a game developer who sells virtual goods, I don't care how hard it is to implement my payment solution. I care how easy it is for my users to use and how many will use it. Stripe claims they are easier to implement. I don't care. They have to show more people will buy if I use Stripe instead of PayPal and that just isn't true. PayPal has far more people who already have accounts and who just have to type in a pin or password to pay. Compared to typing in a whole card, the increased number of users who will buy is really big. Make your users have to do anything difficult and they just won't most of the time. That's the facts of life on mobile. They especially don't like to type.
Their prices were also fixed at the highest end of PayPal's fees (2.9% + $0.30), and while they now mention you can get volume discounts, they make it clear you shouldn't even attempt to discuss this with them until you are looking at over a million dollars processed every year. PayPal and Amazon, in comparison, list discount pricing on their websites for volumes as low as forty thousand dollars a year. Meanwhile, if your average receipt price is less than about $12, you probably aren't even considering Stripe, because PayPal will offer the same service to you with "micropayments" pricing: on a $1 purchase this will save you over 20% of revenue on processing fees.
I have not evaluated Balanced as a payments provider (I only remember them being usable for outgoing payments, not incoming ones; is this feature new? regardless, their pricing is as high as Stripe), but for the purpose of payouts you are looking at a tradeoff: they charge $0.25 per transaction, with $1 if the payment fails; in comparison, using PayPal MassPay costs 2% of the transaction cost, but is capped at $1. If you are building a large marketplace, and end up having to do a lot of dinky payouts, PayPal is going to be more cost effective. You also will have to file less paperwork using PayPal (you don't need to 1099-MISC someone if you use a third-party payment network, as PayPal will send a 1099-K instead, but you do if you use ACH), and will more easily be able to support international merchants.