My beef is with aboloshing payment batching, which is the only wholesome value proposition of patreon (i.e. strictly creates or spreads wealth). Without that it's just another locked-down social graph.
The goal for this change seemed to be at-cost fee payments with no loss or profit, and to prevent chargebacks from customers who didn't remember/expect a payment total or payment date.
The first goal is acomplished with the patron-pays-cc-fee model, and the second one might be solveable enough with UX tweaks.
Showing how the total is calculated in a big, ledgible table, perhaps after every new pledge, seems like a useful start. Maybe even showing a calendar, granting the ablility to change the monthly charge date, and sending/offering reminders or adding an export-to-calendar button.
Of course those may be overwhelming to users, so maybe KISS and find out what can be improved later.
$patron_charge = $pledges_to_creators + $cc_fee + ($patreon_fee?)
$creator_payout = $pledges_from_patrons - ($patreon_fee?)
My beef is with aboloshing payment batching, which is the only wholesome value proposition of patreon (i.e. strictly creates or spreads wealth). Without that it's just another locked-down social graph.
The goal for this change seemed to be at-cost fee payments with no loss or profit, and to prevent chargebacks from customers who didn't remember/expect a payment total or payment date.
The first goal is acomplished with the patron-pays-cc-fee model, and the second one might be solveable enough with UX tweaks.
Showing how the total is calculated in a big, ledgible table, perhaps after every new pledge, seems like a useful start. Maybe even showing a calendar, granting the ablility to change the monthly charge date, and sending/offering reminders or adding an export-to-calendar button.
Of course those may be overwhelming to users, so maybe KISS and find out what can be improved later.