Open Source Events Get Burned By PayPal

How easy would you say it would be to get a loan with "I have $N-thousand dollars stuck in my Paypal account, expected to clear" as collateral?

...actually, wait, that sounds like a [banking] startup idea:

> "We accept payments for an event into an escrow pool, then lend you (with interest) a percentage of the escrow-pool as an advance to set up the event, then release the escrow-pool to you automatically if-and-only-if there aren't too many complaints after the event [otherwise the issue goes to a set-length arbitration, and then we either release the money to you, or refund it in its entirety.] For trusted repeat event-creators, we may increase the loan percentage up to 100%, and may delay loan-interest accrual until after the event-date. We're also partnered with an event underwriter who you can allow us to ensure your event with automatically, in case of black-swan event failure."

Is anyone doing this? Is it even feasible?

Imagine that instead of the current Paypal interface, you had the following:

> Instead of having one email address to accept all payments, you created a new sub-account for each event/product/other "stream of payments" that you want to send/receive.

> Creating a "receive payments" sub-account pops up a wizard, that asks you what these payments are expected to be relating to--a product you sell, a subscription service, an event, donations, etc.

> If you pick "one-time event"--the fraud department is called down to verify you and your business up-front. It all gets explained in the interface, your sub-account just will be in a "verifying" state for a few days/weeks, you'll get phone calls and have to submit paperwork to make it "active." Meanwhile, the rest of your account continues to work and none of your other payments get frozen.

> This is on top of the fraud detection that already happens. If you suddenly receive $50k, no matter what the sub-account said it was for, then sure, pause that sub-account and have the fraud guys take a look. But if they pull up the account and the payment pattern exactly matches what they themselves already OKed you to do up-front--then turn right around and unpause it.

...

Now, this all already happens with Paypal! Big corporations know what to do to make Paypal work like this--create a new Paypal account for each venture, get Paypal on the phone yourself and submit all the paperwork and get them to OK it before you declare it safe to start using that account, etc.

But none of this is obvious to the average small-business owner who may have never used an online payment system before. They just use one account for everything, get popular for whatever reason, accept a bunch of payments or donations all at once, and get their entire funding stream suddenly frozen while Paypal does due diligence that should have happened at the beginning of the process, not right when the money is needed most.

I'm surprised nobody has made a service that transparently uses bitcoins to send someone not-bitcoins:

[For the purposes of the example, let's call the sender of the money Alice, the receiver Bob, and the two instances of this Exchanger service Eddie and Edna. Eddie is local to Alice's legal/financial jurisdiction, and Edna to Bob's.]

1. Alice, living in America, visits Eddie and tells him that she wants to send Bob, in Canada, $50 USD. Bob is only identified to Alice (and thereby to Eddie) by his bitcoin deposit address.[1]

2. Alice pays Eddie $50 USD (cash, Paypal, ACH, pre-deposited funds, an IOU, whatever);

3. Eddie buys bitcoins with those dollars, and transfers the bitcoins to Bob's address.

Then, separately, Bob set up his bitcoin bank with an "on deposit" webhook that calls Edna. When triggered,

4. Edna, acting under an access token Bob granted her through the webhook, withdraws the deposit into her own bitcoin bank account;

5. Edna immediately sells the bitcoins for CAD, thus preventing any currency volatility;

4. Edna sends Bob an email saying "you've got $51.42 CAD[2]", with a URL;

5. Bob visits the URL, and enters his [real, physical] bank account routing information;

6. Edna does a wire-transfer from her account to Bob's bank account.

In this example, Bob and Alice never meet. Eddie and Edna never meet, nor have to trust one-another. The money is exchanged anonymously and securely. And yet, neither Alice nor Bob ever touch a bitcoin, or deal with the volatility of the currency.

Why doesn't this exist yet?

---

[1] This could be encapsulated further if Eddie and Edna both subscribe to Ronald the name-Registrar; then Edna could transparently register Bob as "bob@ronald", and Bob could tell Alice to send her money to that alias.

[2] Assuming neither Eddie nor Edna take a cut of this transaction.