-
Notifications
You must be signed in to change notification settings - Fork 308
drop back to PayPal-only for payouts #3567
Comments
I've registered a separate PayPal account for Gratipay operations. There's a risk that we'll trigger a review because of that, and who knows where that will go? I've disconnected our Citizens account from Gratipay's Gratipay account, and have connected our operations PayPal there. |
How many people are signed up for Gratipay 2.0 with only a bank account and no PayPal? |
55 people are signed up for Gratipay 2.0. |
4 were rejected. 39 are approved, 9 of which (23%) have a bank account and no PayPal. 2 of the 12 unreviewed (17%) have a bank account and no PayPal. We can ask them to update before we approve them. What do we do with the 9? |
(I also now see two of the 39 approved who have neither a bank account nor a PayPal! Reticketed as #3577.) |
Proposal:
|
Here's my query: select slug
, is_approved
, owner
, (select 'yes' from exchange_routes
where participant=p.id and network='balanced-ba' and error=''
order by id limit 1) as
bank_account
, (select 'yes' from exchange_routes
where participant=p.id and network='paypal' and error=''
order by id limit 1) as
paypal
from teams
join participants p on owner=username
and (is_approved is true or is_approved is null)
order by is_approved; |
On second thought, I think we should only use the verified email we have on file for them. The risks here are that:
|
We should only use verified emails because then we're making fewer assumptions about where to send people's money. The worst-case scenario there is inconvenience (we sent it to the wrong address, we have to refund and resend—but it's still an address they control). The worst-case scenario with a publicly scraped email is that we send it to the wrong person. |
To: [email protected]
|
The case for it is from #67 (comment). This ticket is for implementation.
The text was updated successfully, but these errors were encountered: