brackishlake
In Stripe's case, you can make the business choice in your logic to pay out quicker to your end user, so long as you understand the risks (which you assume) and keep a comfortable account balance to cover it. Payouts to you, the Stripe account holder, is another matter!
When you pay money out to users, it is deducted from your Stripe balance. In that sense, the initial charge, and the transfer later, are not explicitly connected to each other. It's up to you to persist some business logic on the application side.
In our case, we build in Stripe's fees (the standard 2.9% + $0.30) and make an assumption about our transfer fees (25 cents per transfer) to make sure we come out on top. The payer (when we create the Charge object) is paying this fee.
That way, when I gift money to a couple, they are receiving EXACTLY what I intended to send them. We don't want the couple feel in any way like there's a "gotcha" — someone sent you $25, but you can withdrawal only $22! We are, of course, transparent to the payer about the additional fees they're covering.
We let users withdrawal their full amount. This is in part to encourage fewer transfer fees, but it also simplifies things for our end-user.
It's been great to work with Stripe. I can't say enough about the quality of their staff and the love and care they put into their API. It's something we should all appreciate and replicate.
Chris
For a fundraising drive to fix their debt problems.
— always —
prefer a higher margin and fewer customers.
Never.
For that matter, when was the last time you called up the IRS and said, "Dammit America, you're doing such a good job, I'm sending an extra $5,000."
Never. In fact, the most you or I have ever given extra is the $3 election fund.
Let's stop joking around, people. Companies, like people, are going to find ways to pay as little as possible, so long as it's legal. Let's stop blaming Apple and blame ourselves: reform the tax code to be simple, fair, and progressive.
This is an absurd statement. Stop wasting time solving problems that don't exist for 98% of the market. "More choice" is not a better than if the choices suck.
"Within 20 seconds or so of restarting, the machine was chugging away with all of its media files in the place they were when they were halted, as if nothing had happened."
This was really cool in the early days of BeOS. But that was more than a decade ago.
People of earth: there is a talent crisis right now. The world needs great developers to build awesome apps for a whole new class of machines. If you feel an urge to "start from scratch" — help rebuild everything for mobile. It's a big job, there are too many projects and not enough developers, and you'll be contributing to a seismic shift in computing.
Stop solving problems that don't exist for most people. Build apps that people will use. Do big things that address 98% of users. These guys clearly have dev chops that I admire, so don't waste them on a project like this.
This is nonsense.
Objective C is a fantastic language. Appcelerator Titanium, PhoneGap - it's all crap. Customers can feel the difference.
To make a native app, learn a native language.