It surprises me that anybody uses Amazon or PayPal when Stripe and Balanced exist.
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.
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.
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.)
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.
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.
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'd love to use Stripe if I could, but they're nowhere even remotely international enough.
Last I checked, one were restricted to Paypal, if using a Brazilian checking account.
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 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.