That's a good example of driver-centric thinking instead of holistic thinking that considers the paying passengers. Consider: what if the customers/passengers actually prefer the convenience of not having to mess with an extra payment transaction step before exiting the car?!? With service like Uber, passengers can just get out of the car immediately when they arrive at their destination. No whipping out the credit-card to swipe. No exchanging of QR codes.
Always think of game theory and consumer behavior preferences.
Adding "Square payments" as a driver-platform "solution to avoid complexity for the programmers" is adding another reason for customers to avoid using it because you added complexity to the customers -- and therefore you have less revenue. There are always tradeoffs.
Whenever anyone thinks "Problem <X> is trivial, and the solution is just to do <Y>," ... you have to think a few chess moves ahead as to what the actual paying customers will do that may negate your "solution".
Heck, a large fraction of the passengers won't even have to reach into their pocket to get their phone because they'll have been doing stuff on it during the ride.
Even for those who have to use an actual physical credit card I don't think it would be enough of a barrier to make a noticeable difference because they are also using that card for nearly everything else. It's so routine that they don't think about it or notice it. I don't think I've ever heard anyone complain about the complexity of paying by credit card at a non-waited restaurant, a grocery store, a hardware store, or any other retail place.
Also, note that with this approach the co-op would not have to make riders create accounts and associate payment information with them. That removes some complexity for the user, and is one less thing to deal with when the user gets a new credit card.
And I think you're falling into the same trap of believing other economic actors will happily agree to your proposed "solutions".
Disadvantages of NFC payments:
1) economic friction which lowers supply of drivers: drivers have to buy $50 NFC terminal from Square. $50 is not a lot of but it's extra financial friction which deters potential drivers
2) trust issues which lowers supply of paying customers: NFC payments puts the payment amount in control of the driver which makes potential customers fear getting scammed. In the Uber/Lyft model, this doesn't happen which is a significant psychological advantage because drivers are notorious for playing games with payment (especially with foreigners and travelers). By letting the "service in the cloud" pay the drivers on behalf of the passengers, it adds accountability.
I'm not claiming it's impossible to create a car-on-demand service that uses NFC and/or credit-card swipes. I'm saying it would be a disadvantage to other platforms that work more conveniently. This means less paying customers which leads to less capital to continuously improve the software -- which could then lead to more customers abandoning the co-op rideshare app for the more polished Uber/Lyft apps.
Again, see the failed non-profit RideAustin losing riders as somewhat analogous case study. And see the other comment about the apparent low quality of this thread's app (Drivers.coop): https://news.ycombinator.com/item?id=26592354
The co-op needs capital to improve the app software and you need a virtuous cycle of paying customers that don't avoid (or abandon) the platform to provide that ongoing capital.
>co-op would not have to make riders create accounts and associate payment information with them. That removes some complexity for the user,
This wouldn't be an advantage for commuters that use Uber/Lyft daily.
The obvious answer would be "so that the user doesn't have to have the app", but if the user doesn't have an app, how is that different from an old fashioned taxi service?
Beyond the fact that the credit card terminal isn't broken... but it's not like the rider would know that ahead of time.
This is partially true. It wasn't just that taxis couldn't be summoned through an app. It was that when you tried to summon one, there was at best even odds of one showing up within 30 minutes. Drivers could and did take curbside hails as they saw fit, and a dispatch often seemed to amount to no more than a polite request.
I've used taxis apps in the years since Uber's debut. Replacing a phonecall that gets ignored with an app's request that gets ignored is not an improvement.
> (2) their credit card terminals were often broken so that you had to pay cash.
They essentially never were. Cabbies just prefer cash. The real issue here is that cabbies had no compunction about lying through their teeth and there were no consequences for this. The whole system was set up so that there was in-theory accountability but no in-reality accountability. Uber took this away entirely by forcing payment to be handled entirely via the app.
> That should be good enough to make them a viable alternative to Uber/Lyft for probably 95% or more of the rides in a US city.
With the above points in mind, things take on a slightly different character. Using Square accomplishes nothing except giving cabbies a slightly different thing to lie about. Without the assurance that your driver won't make random other stops or otherwise not show in a reasonable timeframe, the request app isn't that useful.
Both of those specific problem are solvable for most rides without going anywhere near the level of complexity described in that post you linked to that details why the Uber app is so complicated.
Most of the Uber app complexity that post gives is because they want one app that works nearly everywhere and does a lot more than just let you summon a ride from A to B and pay via credit card.
For most US cities you could cover the payment needs of most riders with something from Square installed in the car. That gets rid of a huge amount of complexity (or rather, pushes it to someone else).
That should be good enough to make them a viable alternative to Uber/Lyft for probably 95% or more of the rides in a US city.