[saurik]

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.

[Silhouette]

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.

[saurik]

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.

[Silhouette]

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

[mattbarrie]

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

[joevandyk]

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.

[saurik]

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.

[nandemo]

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.

[tomlu]

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