credit card statement should only be for the difference

[chadwhitacre]

From @nathany on Twitter:

If I’m giving and receiving, shouldn’t my credit card statement only be for the difference? Instead I have a +balance. Not impressed

This isn't #1419:

This is my first time receiving a gift. Presumably the balance received this week will be used next week? I'm non-US.

A little math upfront would not only lessen fees, but help avoid the 52K in escrow, which feels like a scam.

I've added a +1 to "escrow as little money as possible" (#1383).

[nathany]

I've only been with gittip a few weeks, but I've already helped initiate the quadrupling of the golang community.

This is the first week where I received a tip.

Reasonable expectations

Going into Thursday, my expectation was that giving $25 and receiving $10 would result in a $15 charge + applicable fees. That's not what happened:

Instead I was charged for all my gifts and the tips I received went towards a positive balance.

As someone outside of the U.S. [#126], a positive balance does me little good, and even with a manual Paypal transfer, Paypal charges exorbitant fees to move that balance to my bank account.

Give more than you receive

So long as I'm giving more than I receive, there should be no reason for my balance (and therefore gittip's escrow) to increase. Without a balance, there is no need for me to deal with Paypal or withdraw money.

If this is resolved, then next week should look like:

	amount
giving	$27
receiving	$10
balance	$10
total charge	$7 + applicable fees

Implemented across the board, this should significantly cut into the 52K escrow that gittip currently has.

If this isn't resolved, then I will always have a balance and you will always have an escrow, at least until everyone stops sending me tips! :-)

[chadwhitacre]

@nathany Thanks for bringing this up.

The current payday implementation works by looping three times over all participants (in the order they joined):

• In loop one we charge credit cards and transfer money within Gittip from one participant to another.
• In loop two we distribute money from teams to their members.
• In loop three we deposit money into people's bank accounts.

I'm seeing two challenges with improving this algorithm:

First, how do we compute what each person is due to receive each week without squaring the complexity (looping over all participants for each participant in the first loop, to calculate the amount each is due to receive)? One hunch is that we could compute receipts due at write time when tips are changed, so we have the info available when we loop during payday. A second hunch is that we could invoke the steady-state algorithm that @carsomyr implemented for us over on #449. Those are hunches, need to follow them up.

Second, credit card charges can fail. This means we can't guarantee how much you're due to receive until we actually attempt to charge everyone from whom you're receiving. Now, we do have the possibility of placing holds separate from actually charging cards (though "Balanced does not recommend holds and considers their usage as a very advanced feature as they cause much confusion and are cumbersome to manage"). We could place a hold on everyone for the max amount they're willing to pay in, and then charge them that amount or less, depending on the result of whichever algorithm we end up going with for computing receipts due. The hold would only last for an hour up to part of a day.

[nathany]

One hunch is that we could compute receipts due at write time when tips are changed

Given that every user's Gittip page says "this is how much you're receiving" it seems like a useful amount to store.

Second, credit card charges can fail.

Good point. I presume you don't want to get into a situation where Gittip has given more than it has received and people with NSF have a negative balance.

So in the above scenario, if I don't receive the $10 due to a decline, the desired outcome is that I am charged $17 to cover my gifts. That seems reasonable.

Of course if my card is declined then everyone receiving my gifts may need to be charged more, so another exponential problem.

[nathany]

@whit537 Do you have any numbers on declined credit cards?

The negative balance option might work if it was a temporary situation for a small pool.

• Anyone with a negative balance (or perhaps a history of NSF) is prioritized for next week.
• If declined, their gifts are disabled, and the receipts are recalculated for "how much they receive"
• Then run calculations for everyone with a zero or positive balance.

Though there are certainly still problems with this idea, particularly gifts within this pool of NSFers.

[mvdkleijn]

@nathany To be honest, this sounds rather complicated... seems easier and more logical to me to do a short-lived hold on the credit card to ensure a minimum level of funds is available. (for example: at least the amount they've pledged to give) Then we can run the team takes and finally process all of the personal gifting. Whatever is left should be charged to the credit card.

Theoretically this should never be able to exceed the hold we already placed earlier. If any of the holds failed, we know that person has insufficient means to cover their gifts, so we can deal with that appropriately.

I understand Balanced doesn't like to use holds, however, they would be so short lived they'd more be like credit checks. In the hotel world, holds are very common. If you've ever stayed at a hotel, you've had a hold placed on your card.

[zbynekwinkler]

@mvdkleijn In the long run I also do not see other way except using holds. I don't see what's wrong with them.

[nathany]

I don't know what exactly is wrong with holds either, particularly if they are short-lived. Maybe some banks treat them differently? I've heard complaints of a double-charge in the past (the hold and the actual charge on a bank statement until the hold disappears), though this shouldn't happen... the amount settled should be against a txn id for the authorized amount (hold).

The only other option in the same vein is to do a partial refund, but Holds seem more appropriate.

[chadwhitacre]

@nathany Just this week we've started trying to prioritize our work better so we can make steady progress on Gittip overall while also being flexible enough to respond to emergencies and opportunities. This is definitely something we want to address, and the conversation started here is helpful. My sense is that this is not an emergency, though, and my preference would be to address this in the future when we're able to focus on tuning payments.

Here's a post about our approach to prioritization, the lay of the land, and our current focus (Infrastructure):

https://medium.com/building-gittip/7e898db3ae68

@nathany Do you see this as an emergency issue or highly perishable opportunity for Gittip?

[nathany]

@whit537 I don't think it's detrimental, but it does evoke some feelings of whether or not to trust that Gittip is doing "the right thing".

Outside of that, having the credits after the debits on the history page might make it more clear that this isn't a bug.

[chadwhitacre]

I don't think it's detrimental, but it does evoke some feelings of whether or not to trust that Gittip is doing "the right thing".

Okay, I agree. I implemented the current algorithm because it was easiest to get off the ground (for some of the considerations mentioned above). I agree that we're getting to the point where we should evolve it, and I'm glad to have this ticket to keep track of this. Thanks for using Gittip and for helping us out here! :-)

[ceboudreaux]

+1 from @elazar via Twitter:

@elazar: @ceboudreaux Know if @gittip requires a minimum amount before a deposit? I've got a verified bank account and balance, but no deposits.
@ceboudreaux: @elazar @gittip If you're giving as well as receiving, payout won't happen automatically until it reaches a threshold
@elazar: @ceboudreaux @gittip Gotcha, many thanks. This may be something good to add to the FAQ. I didn't see it mentioned elsewhere on the site.

[nathany]

Another week. The math is fine but the history is still organized in a peculiar way.

[chadwhitacre]

@nathany Yeah, you should expect this ticket to be open for a while. :-(

We are currently prioritizing infrastructure tickets:

https://github.com/gittip/www.gittip.com/issues?milestone=1

On Monday we were at 4 tickets closed out of 120 (3%) and right now we are at 11 / 134 (8%). If you want to stay in the loop on our progress, the best thing to do is to sign up for our Monday newsletter. We're a small team and I'm the only one working on Gittip full-time. If you'd like to help us move faster and make future prioritization decisions, you're welcome to jump in on the infrastructure tickets. :-)

As far as the organization of the history page goes, transactions within a given payday are sorted by timestamp, and the three payday loops are in order of who joined Gittip first. So whoever gave you $10 joined Gittip before you; then we get to you, charging you and distributing all your tips; then we get to someone who joined after you that is tipping you $0.75. It might not be ideal but hopefully you can see it isn't random. :-)

[nathany]

Should I create a separate, much smaller, issue for simply sorting the history displayed to have charges before payouts? I think that would make it much easier to follow.

[chadwhitacre]

@nathany You're welcome to reticket that if you like, though you should still expect it to be fit in somewhere after the Infrastructure milestone is done.

[mvdkleijn]

@whit537 This and other tickets like is (for example #1589) would no longer be a problem if the whole payday algorithm was "internalized".

I.e. run through it in memory, without executing any actions. That allows the algorithm(s?) to be run in a more logical ordering and for us to reduce fees etc everywhere.

For example, this is a run I could imagine:

• Connect to payday DB
• INSERT starting balance amounts for each Gittip account
• INSERT one transaction per Gittip account for each donation they make to another Gittip account
• Recalculate balances
• Process all takes from teams (since teams don't pay-in, that shouldn't be a problem)
• Recalculate balances
• Calculate needed CC payins
• Charge cards
• In case charge fails, recalculate that account's donations etc
• Once final numbers are known, transfer data in regular Gittip DB

[chadwhitacre]

IRC wrt balanced/billy#15

[chadwhitacre]

A reason to escrow as little as possible (#1383, closed in favor of this ticket), a cautionary tale from the world of bitcoin:

I am now fully convinced that no hosted escrow service is safe.

[nathany]

This continues to feel like a scam... every time I get a credit card fee when there shouldn't need to be one... and the UI continues to be unclear about what is going on and why. (The only reason I know is from this ticket).

[bruceadams]

@nathany wow. I don't like the behavior in the first place, but the display you show makes it even worse. I believe that, in fact, the credit card charge occurred before any of the other credits kicked in. I have no clue why the history doesn't show it in that sequence.

I'd rather we didn't do hit your credit card with the transactions you show, but guessing what income will really land is hard to get right globally throughout Gittip.

[seanlinsley]

A discussion with @steveklabnik in #balanced suggests that the we're well-suited to use holds to determine in one fell swoop whether a given participant's credit card needs to be charged to back their tips.

[steveklabnik]

Yup! The 'advanced' warning stuff about holds applies to things like they're only seven days maximum, and if you don't capture or void them, the card networks get upset, etc.

Doing a hold for less than a day, in this kind of situation, is exactly what they're for.

[chadwhitacre]

@nathany Would you like to lead an effort to clean this up? It is going to be a significant project. Having worked with you on Shields I'd be comfortable having you lead the effort. Want to do a Hangout to discuss?

[nathany]

@whit537 Sorry, too many other things to do.

[chadwhitacre]

@nathany Okay, understood.

[rummik]

+1-ing this, since I frequently am getting charged card fees for tipping pennies

[duckinator]

+1 because this seems like a very significant issue, even though it hasn't affected me personally AFAIK. I'd argue this should be bumped up to ★★☆, even.

I'd be willing to take the lead on implementing it, if someone can help me get up to speed with how everything works with the payday stuff in general (including how it interacts with Balanced and how we test it -- please, Dear God, tell me we actually test this. Please.) and be available for me to poke every once in a while for anything that I get stuck on.

[chadwhitacre]

Okay, @nathany! Finally addressed this. :-) Let's keep an eye out this Thursday to see if we indeed fixed this, eh?

[nathany]

thanks @whit537 @Changaco