Pay for package.json in aggregate

[chadwhitacre]

So far under #4427 we've deployed discovery via package.json, but the payment mechanic is the same one we've always had: recurring weekly payments managed individually for each and every package. This PR adds a new payment mechanic (our first in years—ever?): givers can set a single dollar amount to pay for their entire package.json in aggregate.

Todo

• replace listing with "How much?" prompt
• add Review page with receipt-y thing + credit card form
• add cron to process distributions daily
• add distribution customization UI
• email receipt
• email invitation to maintainers
• email distribution report

[chadwhitacre]

Email auth (#4539) would sure make this flow nicer.

[chadwhitacre]

Email auth would potentially allow us to charge people as "guests" without making them make an account. That moves us even further outside our current flow of funds, however (e.g., what are the fraud implications?). And I think the user experience would actually be fairly close in either case, because the email prompt would come at the end of the flow regardless (you don't want to put it anywhere else because then they have to go to email and come back—a high-drag maneuver).

In sketching up the flow given current auth (no email) I see:

1. Post package.json just like we have now.
2. Instead of listing of all packages (grouped by acceptance of funds), prompt for a dollar amount with only a summary of packages discovered ("10 ready to accept payments, 5 not ready, 85 unclear").
3. Prompt for sign-in.
4. Review screen with credit card form on it.
5. After payment, prompt for email address if missing ("To receive a receipt by email and a report in a week ...").

[chadwhitacre]

Here's a write-up of what's sketched there:

1. giver posts a package.json
2. giver enters a dollar amount and a distribution (default or custom)
3. giver signs up/in
4. giver reviews payment instruction, enters cc details if necessary
5. on post:
   1. store payment instruction
   2. charge giver immediately and increase their balance
   3. email receipt to giver
   4. if all specified packages are claimed-or-locked: distribute immediately
   5. else: email maintainers of unclaimed-or-locked packages and wait

Daily cron task:

1. review payment instructions
2. for each payment instruction that has been open for a week:
   1. distribute funds based to opted-in receivers
   2. email a final report to giver

[chadwhitacre]

From slack:

The basic idea for bulk pledging is that we immediately charge the company the $10,000 (or whatever) and hold onto it for a week while we automatically email the maintainers of unclaimed packages in the set of packages in their package.json. After a week we distribute the $10,000 based on who has claimed their packages by then.
It’s a new and different flow from what we’ve ever offered before (weekly recurring).
It’ll take some work to get there, and cleaning up our current npm integration moves us in the right direction.
The idea is to scale.
Email is the key.
But we have to tighten up the ship or it’ll come apart at the seams once it achieves any real velocity.
If we’re already getting phishing against npm [#4557], imagine what we’ll get once we start promoting (via the npm weekly, etc.).

[chadwhitacre]

Bringing back pledging means bringing back locking/hard-opt-out, which plays into phishing mitigation: #4557 (comment).

[chadwhitacre]

Closing in favor of #4598.