refund advances

[chadwhitacre]

Reticketed from #3675.

[rorepo]

@whit537, following on from my earlier questions, it's clear that we would no longer have the scenario of charging a user and then immediately having to refund the same user. And possibly, the extent of the 'small balance' situation I'd been thinking of will have diminished after a few weeks of charging in arrears.

There's something else I'd like to clarify. Would refunds be made as payments back to the same credit card? Or to the paypal account of the user? If it's the latter, what do we do in the case of users who don't have paypal accounts? e.g. someone who is only giving and hasn't bothered to set up a paypal account?

[chadwhitacre]

Would refunds be made as payments back to the same credit card?

Yes. Balanced and Braintree have refund APIs that work even if the card was cancelled—though almost certainly not if the entire bank/card account was closed, a situation we'll almost certainly run into.

[rorepo]

Having a spot of trouble. When running make test, things getting stuck at recreating public schema .... Doesn't seem to have anything to do with my code changes - trying with a fresh checkout doesn't help. Wonder if my machine's got corrupted.

Also, a couple of questions. Found a MINIMUM_CREDIT value in exchanges.py. What is this meant for? And do Braintree levy a fee on credits as well?

[rorepo]

I've moved beyond the 'corruption' (was my code after all :-(), but now facing a seemingly intractable problem. I think possibly something to do with my (lack of) understanding of threaded_map/thread pool usage. Trying to figure it out.

[chadwhitacre]

@rorepo Possibly related to #3789?

[chadwhitacre]

I've moved beyond the 'corruption'

Cool. :)

I think possibly something to do with my (lack of) understanding of threaded_map/thread pool usage. Trying to figure it out.

How can I help? :-)

Found a MINIMUM_CREDIT value in exchanges.py. What is this meant for?

This is vestigial from when we did bank payouts via Balanced. It can probably be removed now.

And do Braintree levy a fee on credits as well?

Braintree doesn't provide credits (payouts). The payout route we offer is PayPal.

it's clear that we would no longer have the scenario of charging a user and then immediately having to refund the same user.

Actually, if a payout fails, we do want to immediately refund all of the cards the money came in on. No?

[rorepo]

Sorry, @whit537, looks like we got our wires crossed a bit.

Braintree doesn't provide credits (payouts). The payout route we offer is PayPal.

However, this earlier exchange suggests otherwise:

Would refunds be made as payments back to the same credit card?
Yes. Balanced and Braintree have refund APIs that work even if the card was cancelled—though almost certainly not if the entire bank/card account was closed, a situation we'll almost certainly run into.

To help things along :-), I've been trying credits with Braintree and as far as I can see, it was working (i.e. didn't get any errors - I expect we'd need to confirm at the Braintree end as well).

So now, where does this leave us - Braintree or Paypal? :-)

If it's going to be Paypal, my above problem may no longer be relevant.

[chadwhitacre]

However, this earlier exchange suggests otherwise:

Ah, yes. That's a subtle difference: Braintree does provide a refund API, but technically that's a refund of a payin, which is not quite the same as a payout.

So now, where does this leave us - Braintree or Paypal? :-)

Braintree for refunds! And Balanced, too ...

I've been trying credits with Braintree and as far as I can see, it was working (i.e. didn't get any errors - I expect we'd need to confirm at the Braintree end as well).

Cool. Was that using a sandbox or production? If a sandbox (as I hope ;), do you have access to the Braintree dashboard for the sandbox?

[rorepo]

Well, must be a sandbox - defaults.env says BRAINTREE_SANDBOX_MODE=true. Besides, I'm sure Braintree would've objected to transactions in the name of 'obama', 'picard', etc., if it had been otherwise :-)

How do I access the dashboard?

[chadwhitacre]

@rorepo I think your best bet is to sign up for your own account at https://sandbox.braintreegateway.com/login and set the relevant BRAINTREE_ keys in your local.env to point to your own sandbox.

[rorepo]

I got things working up to the point where the refund was being made and the participant balance correspondingly being brought down to 0. But there was one problem remaining - check_db. The expected balance was the (-ve of the) figure I had directly inserted into the participant balance in order to create the excess balance situation. I suspect this was because there was no corresponding payments record.

At this point, I thought I'd try my own Braintree sandbox credentials. Things didn't go well. Braintree returned an error, complaining that the custom field participant_id was invalid. Removing that didn't help either, so I put it back and reverted back to the old credentials. Now I get an authorization error. Haven't been able to move beyond that.

P.S. I hadn't used local.env to put in my credentials - made the changes in test.env.

[chadwhitacre]

Braintree returned an error, complaining that the custom field participant_id was invalid.

Ah, okay. You would need to configure that under "Settings > Processing":

---

If you're able to get a sandbox working, we should add docs to the README.

[chadwhitacre]

P.S. I hadn't used local.env to put in my credentials - made the changes in test.env.

Okay. The former is for the web app (make run), the latter for the test suite.

[chadwhitacre]

You might consider creating a tests/local.env file instead of modifying tests/test.env, since the latter is in source control and the former is .gitignored.

[chadwhitacre]

Turning to this.

[chadwhitacre]

Who do we refund, and how much?

[chadwhitacre]

I'm thinking about this in the context of 1.0 refund as well (#3539). I think we want to think in terms of "generations" of money. Given:

• Week 1—We charge Alice $10 and Alice gives $2 to Bob.
• Week 2—Alice gives $2 to Bob, and Bob gives $0.50 to Carl.
• Week 3—Alice gives $2 to Bob, and Bob gives $0.50 to Carl.

The goal on this ticket is to refund $6 to Alice: that's first-generation money, because it's still sitting in the balance of the account through which it first entered the system.

The goal over on #3539 is to refund—back to Alice, ideally—the $1 that Carl is holding, and the $3 that Bob is holding.

[chadwhitacre]

We need a list of accounts holding first-generation money.

And for that I believe we're going to need to backfill the status and route columns of exchanges first: #2779.

[chadwhitacre]

Who do we refund, and how much?

Actually, the question is, which transactions do we refund, and how much? That's why #2779 is prerequisite.

[chadwhitacre]

Tryin' to eek something out here ...

[rorepo]

OMG! Had to take a break and looks like I missed out on some serious fun. Looked at #3810 and my head's spinning.

Had got a bit lost at the end here in 3763, looked like I was missing some historical knowledge. Now I suppose that's just academic.

@whit537, any reason why this one hasn't actually been closed? #3810 does mention that it closes this one.

[chadwhitacre]

Gonna clean up and merge #3810, and then write a blog post.

[chadwhitacre]

And yeah, there was some serious fun on #3810 over the weekend. Landed it an hour before the Balanced cutoff. 🙀

[chadwhitacre]

Actually, we should refund advances on Braintree before closing this.

[rorepo]

In that case, there are two things I'd like some input on, both probably to do with historical knowledge I'm missing:

• The example you'd given earlier:

Week 1—We charge Alice $10 and Alice gives $2 to Bob.
Week 2—Alice gives $2 to Bob, and Bob gives $0.50 to Carl.
Week 3—Alice gives $2 to Bob, and Bob gives $0.50 to Carl.

How is it that all the $6 that Alice gave out has to be refunded? I was thinking of this as Alice giving to a team owner (Bob), who in turn distributed this to a team member (or the team member 'taking' it).

• I'm afraid I'm rather lost on this one as well:

And for that I believe we're going to need to backfill the status and route columns of exchanges first: #2779.

[chadwhitacre]

How is it that all the $6 that Alice gave out has to be refunded? I was thinking of this as Alice giving to a team owner (Bob), who in turn distributed this to a team member (or the team member 'taking' it).

Under Gratipay 1.0, ~users gave directly to each other.

I'm afraid I'm rather lost on this one as well:

We needed a connection between individual credit card transactions in our database and in Balanced's database. The status and route columns were actually just part of the picture: we needed a new ref column to link the individual transactions (route just links to the payment method).

[rorepo]

I'm still unclear, I'm afraid. Users giving directly to each other is fine, but my main confusion is that I thought it was only 'excess', i.e. whatever's not been distributed out to end recipients, that needed to be refunded.

And about the ref column - how would we go about filling this in?

[chadwhitacre]

And about the ref column - how would we go about filling this in?

We'll have to use logs from our various payment providers and compare them with our records in exchanges. This comes under #2779.

Users giving directly to each other is fine, but my main confusion is that I thought it was only 'excess', i.e. whatever's not been distributed out to end recipients, that needed to be refunded.

Correct. We only refunded the user's current balance, but the way refunds work is you have to perform them against a specific transaction. You can refund less than the original transaction amount. We wanted to refund Alice the $4 she's left with, and the way we do that is to refund here $4 against the $10 transaction where we originally charged her.

Anyway, this is done in #3810. :-)