Although I receive money via Gratipay, I can't give it away

[book]

Although I receive money via Gratipay, I can't give it away. Latest example: payday 165.

I started with a credit of $0.00, received more than enough to cover all the gifts I registered, but the amount was still sent to me in full (minus the PayPal fees) without making any of the donation I have listed.

I understand this is probably due to the way donations are resolved: my donation were taken from an empty account, and since I have no credit card listed, no money could be taken, therefore no donation was made in my name. Then the money given to my teams ended up on my account, and was paid to me.

I have no idea how payday computation is done at the moment, so I might be writing absurd and silly things below.

It should be possible to come up with an algorithm that would 1. allow me to give some of the money I receive through Gratipay to teams on Gratipay 2. minimize the total amount lost in fees.

By computing the graph of all people and teams (nodes) with the donations (edges) between them, one could come up with a "delta" for each person and team. The only issue would be people without a registered mean of payment, when the delta is negative. Some donations would not be honored, which would require another run of the graph computation, with the new data. I expect this would stabilize quickly.

Want to back this issue? Post a bounty on it! We accept bounties via Bountysource.

[book]

Looking at payday.py, I see this comment:

On Payday, we want to use a participant's Gratipay balance to settle their tips due (pulling in more money via credit card as needed), but we only want to use their balance at the start of Payday. Balance changes should be atomic globally per-Payday.

So indeed, one has to have a positive balance at the start of Payday, otherwise money will be drawn from their credit card. I haven't looked at the code in depth, but I expect that if the balance at the end is positive, no money is actually withdrawn from their credit card. (Otherwise, the only real beneficiaries of the system are PayPal and the banks...)

That algorithm won't work for people who have not set up a payment mean, since they can't make a "virtual cash advance" to the system. One option is to clearly state that it's only possible to make gifts when a valid payment mean has been set up (issue solved with no code change!). However, if you want it to be possible to give from the stack of money received within the system, that probably means a process with multiples passes, which hopefully has a stable end state.

An additional issue, obviously, is when someone with no payment mean has not received enough to cover all their gifts. How this is resolved (I'd go with either "don't give anything", or "give everyone a percentage of the planned gift equal to the ratio of amount_received / amount_needed_to_cover_all_gifts", but other options are possible, like using a list of preferred tipees and giving to them until money runs out.

As soon as the tipper gives less than expected, we run into more problems, since some of the money they receive could come (more or less directly) from someone they tip. And so the total amount they receive will have decreased with the next pass. Hopefully the algorithm will halt at some point, but I'm afraid there are more than on valid end state for the whole thing.

[book]

Thinking a little more about the "give everyone a percentage of the planned gift equal to the ratio amount_received / amount_needed_to_cover_all_gifts", that percentage needs not to be exact.

So if someone receive only enough to cover 83.47% of their planned tips, that would be rounded down to 80%. There could even be less possible percentages, for example 100%, 75%, 50%, 25%, 0%. (Note that the other option I mentionned is simply 100%, 0%.)

This should reduce the number of rounds needed to reach equilibrium.

[chadwhitacre]

@book

[chadwhitacre]

*sigh* Comment derp, sorry. :-)

[chadwhitacre]

@book The situation you describe, wherein we have a graph that needs settling out through multiple iterations, was indeed the case for our Gratipay 1.0 payday algorithm. With the introduction of the Team intermediary in Gratipay 2.0, I believe our algorithm is much simpler and guaranteed to settle in one pass with charges (fees) minimized. Here's where we first discovered this algorithm. I'd have to work it through again to make sure it's behaving as expected as currently implemented ...

[book]

Nice new UI. Seeing both the sum (Σ) and the number of givers/teams taken from (n) is also very nice.

Still, there seem to be a discrepancy:

According to my "Giving" page, I'm giving to two teams, but the summary seems to only take one into account. Also, I the "Takes" total is different from what I actually receive each week. I suppose it's because some of the tippers are in the same situation as me, and do not have a credit card attached to their account.

I'm not sure there's an easy way to convey the fact that the "Takes" total is a maximum, and not necessarily the real number (this is also true for "Gives", since for the past few weeks, I've actually been giving nothing, due to the way the Payday algorithm works).

[chadwhitacre]

Interesting. That could be because the ~owner of the other Team you give to doesn't have a PayPal attached (#3681), though if that's the case—and it probably should be, since we don't, in fact, move money unless there's a payout route—then we should a) treat this consistently across all the cached values (the Team in question displays a positive receiving Σ and n despite not having a payout route), and b) indicate both on your Giving page and on the Team's page that they aren't actually receiving because of the misconfiguration (no payout route).

[chadwhitacre]

That could be because the [...]

Where "That" refers to:

According to my "Giving" page, I'm giving to two teams, but the summary seems to only take one into account.

[chadwhitacre]

Also, [] the "Takes" total is different from what I actually receive each week. I suppose it's because some of the tippers are in the same situation as me, and do not have a credit card attached to their account.

I wouldn't expect their payments to be included in that case.

[chadwhitacre]

I've reticketed a review of our computation of cached values as #3729.

[book]

Not sure if this is related, but on September 17, 2015 (weekly payday 172), since there was some money left over from the previous payday, my tips could be processed.

The first one, to PerlWeekly, was processed correctly, but the second one, to Gratipay, had its amount doubled... Since both tips were of the same amount, maybe a running total was tipped instead of the configured value ?

I don't know what happened, but it looks like a bug to me.

[rohitpaulk]

I think I know what's happening here...

Here's what payday does (not entirely correct, but sufficient for this explanation)-

1. Process payments (from ~users to Teams).
2. Drain team balances to owners. (within Gratipay)
3. Payout (via PayPal)

According to the above, the money one receives through a team would never be used to fund one of their payments to another team (because payments are processed before team balances are drained).

The culprit here is the minimum payout. The minimum we can payout via PayPal is $0.5. So when the amounts involved are small, one could end up carrying a balance in their gratipay account which could be used in future paydays to fund payments to teams.

Walkthrough

Let's say I tip Gratipay a certain amount every week, and I own a team named Enterprise that receives a certain amount every week.

I start out with a balance of $0, and I have no credit card attached.

If the amounts involved are > $0.5

• My weekly tip to Gratipay - $15
• What I receive from my team Enterprise - $20

(I purposely chose amounts greater than the minimum charge to not bring the 'charging in arrears' logic in here).

Payday 1

• Payday tries to process my payment to Gratipay, but it can't. I don't have a balance > $15, and I don't have a credit card attached.
• Payday now transfers the amount I received from Enterprise ($20)
• I receive a payout for $20

This cycle repeats. I keep on receiving $20 each week, but my $15 payment to Gratipay never gets processed.

If the amounts involved are < $0.5

• My weekly tipe to Gratipay - $0.25
• What I receive from my team Enterprise - $0.45

Payday 1

• Payday tries to process my payment to Gratipay, but it can't. I don't have a balance > $0.25, and I don't have a credit card attached.
• Payday now transfers the amount I received from Enterprise ($0.45)
• I can't be paid out via Paypal since my balance is $0.45 (< 0.5).

So in Payday 1, I didn't receive a payout, and my tip to Gratipay wasn't processed. I end up with a balance of $0.45

Payday 2

• Payday tries to process my payment to Gratipay. I don't have a credit card attached, but I do have a balance of $0.45. The payment goes through, my balance is $0.20 ($0.45 - $0.25)
• Payday now transfers the amount I receive from Enterprise ($0.45). This brings my balance to $0.65 ($0.2 + $0.45)
• I get paid $0.65, since it's greater than the minimum payout.

In payday 2, I received a payout, but my tip to Gratipay was processed too.

[mattbk]

Similar comment on Freshdesk:

Thanks for your great site!

My username there is [redacted] and as you can see, I'm
currently giving .40 $ and receiving .05 $.
However, I still receive a payout every few months (and have to load up
my account again now and then), which is obviously pointless. Is this a
bug, or a setting I can change somewhere, or is it by design for some
reason?

[chadwhitacre]

Dropping from the Pivot because it's the last thing there and while this is still something that needs to be addressed, it's not critical to the definition of "done" for the Pivot.