RFC: What information should we be tracking for legal and taxation purposes?

[zspencer]

Payment processors such as Stripe, require collecting the social security number or EIN of the person collecting payments.

Since we are not doing payment processing at all, does this mean we don't need to collect EINs, since our party-hosts are expected to provide their own payment processor credentials?

Are there other things we should be tracking for legal reporting purposes that we're not aware of? Or can we safely state that since money never touches our servers, it's entirely the responsibility of the party host and payment processor to ensure appropriate information is sent to the IRS?

[bhaibel]

How are we using "party host" in this context? Are we using it to mean "instance maintainer" or are we using it to mean "anyone, not necessarily the maintainer, who receives money through a nourish instance?"

Since we're requiring instance maintainers to provide their own payment processor credentials, they should be the only ones who need to track their own EIN/SSN. We may need to require them to collect the EIN/SSN of anyone they do payouts to. We may be able to get around this by requiring payouts to be through PayPal, Square Cash, or another intermediary -- I don't love the number of middlemen taking a slice of the pie in this scenario, but I'm also really wary of setting up a situation in which semi-novice sysadmins are responsible for PII.

I'm pretty sure we can say that as long as the money never touches our servers, responsibility for tracking tax and other information lies on instance maintainers and payment processors. We may want to put features for making this easier on the roadmap.

This will likely become a more complex problem when we introduce federation.

[zspencer]

I'm using Party Host to mean the person who will be receiving the money, and working from the assumption that a single Instance will have many Hosts.

I believe we will want Party Hosts to provide their payment processor credentials, for two reasons:

1. We (probably?) don't want instance hosts to be able to be "middle people" taking a portion off the top
2. This puts the EIN/SSN/etc. in the hands of the payment processor, and all the Instance Admins only have the ability to revoke someones ability to take payments or to give money to a party host. It does mean that we will be storing the hosts "stripe app secret" in the database, but that seems significantly less dangerous than the hosts EIN/SSN.

Nourish would provide the UI for finding Parties to toast/support and embedding the Party Host's payment processor in the site, ala stripe checkout.

(party_supporter) -> (payment_processor) -> (party host bank account)

This does put the onus on the party host to create a stripe or other supported payment processor account, but it absolves the instance admins of responsibility and authority, leaving it squarely in the party hosts hands.

[bhaibel]

That's interesting! I had specifically been assuming that we might want to enable instance hosts to be able to be "middle people" who take a cut, probably on an attendee-driven optional basis a la either Humble Bundle or ActBlue. Administering an instance is labor, and I think that allowing people to take money for the sysadmin and community management work of instance admin is consonant with the goals of this project.

Under the model you're proposing, we might be able to solve that issue with multiple charges to attendees' cards. That isn't a great solution, though., but that increases the % cut that payment processors take in a way that, while it may be unavoidable, I am not enthusiastic about. We'd also need to be careful about messaging on folks's credit card statements to avoid chargebacks.

I'm concerned about UX for semi-technical party hosts if we make them provide their own payment processor credentials, especially given the chargeback issue (cryyyyyy), but we might be able to solve that with education.

These are probably acceptable compromises given the increase in administration complexity that we put on instance hosts if we store PII. I'm trying to expose, with this comment, the reasons that I think that's a "lesser of two evils" compromise, rather than something we get for free.

[zspencer]

Ahhhh, my understanding was that instance hosts were encouraged to have their own project/party on their instance and ask people to support them, instead of mandating a share.

I think once we want to really do sharing between people we'll want to look into Dwolla or similar since they support paying out across multiple people, whereas stripe is not set up for that.

One way we could do the "sharing" multiple users with Stripe would be to literally round-robin transactions. For example:

Project Dinosaur Revival has 2 team members: Ellie and Alan. Ellie and Alan target a 50/50 split from their backers/sponsors/toasters/whatever

So far this month, 9 people have provide $5 each, and Ellie has gotten 20 of that and Alan has gotten 25. A tenth person decides to provide $5. We route the $5 to Ellie's stripe account instead of Alans; bringing the total to $50 and each person has received $25 to their respective accounts linked to their SSN/EIN/Whatever stored in Stripe.

[bhaibel]

I like the idea of punting on this until Dwolla is set up. I fundamentally like encouraging instance maintainers to set their own norms around the financial support they need instead of trying to codify particular mechanisms -- the one thing that gives me pause there is that tips have been a really great revenue stream for other fundraising-software projects, so even if we don't try to solve that problem short-term I don't want to rule out tip-like mechanisms long-term.

I'd rather punt on sharing until Dwolla and/or just let Stripe eat fees rather than do round-robins; my guess is that round-robins would be hard to communicate about on people's credit card statements, and since we structurally can't assume chargeback risks for our creators I don't want to make charge-pattern decisions that will confuse backers in ways that might encourage chargebacks.