charge on Braintree

[chadwhitacre]

Closes #3287.

[chadwhitacre]

I don't see that we had tests for fetch_card_holds that actually hit Balanced. I ran this test and it canceled a few dozen card holds in our Balanced sandbox.

[rohitpaulk]

@whit537 - I'll take this over, you could focus on using the Balanced -> Braintree migration data. Sound good?

[chadwhitacre]

@rohitpaulk Roger that.

[chadwhitacre]

It looks like customer id is an editable field. The id for customers brought over from Balanced is their Balanced customer id.

[chadwhitacre]

In other words, we don't need a separate Participant ID in custom_fields. We could just use Gratipay's participant.id as the customer id at Braintree.

[chadwhitacre]

Moving to #3391 ...

[rohitpaulk]

@whit537 - 59ca2f3

[chadwhitacre]

Good look.

[rohitpaulk]

The transaction has been submitted for settlement and will be included in the next settlement batch. Settlement happens nightly — the exact time depends on the processor.

Looks like we can't capture card holds immediately like with Balanced.

[chadwhitacre]

Looks like we can't capture card holds immediately like with Balanced.

Yeah, Balanced floated us the money (i.e., they made it available to us in our escrow immediately, even though they didn't actually get the money from the acquiring bank until the next day). This came up in my meeting with Citizens last week. It's not a big deal for now since we have enough in escrow to float the different for a day. As we gain more experience with Braintree and as we reduce escrow (#1383) we'll have to maybe rethink our timing of card captures vs. payouts.

[chadwhitacre]

The main point is that card captures are almost certain to settle without incident, so there's little risk in floating for a day if we can make it work cash-flow-wise. Once we have a hold/authorization, we can count on the funds landing in our bank account sooner or later.

[rohitpaulk]

Once we have a hold/authorization, we can count on the funds landing in our bank account sooner or later.

Cool, so I'll proceed with the assumption that a transaction that is authorized and then submitted_for_settlement is good enough to add to the user's balance.

[chadwhitacre]

Cool, so I'll proceed with the assumption that a transaction that is authorized and then submitted_for_settlement is good enough to add to the user's balance.

Yup. We'll keep an eye out, and if we end up getting burned by this assumption down the road then we'll adjust.

[chadwhitacre]

@rohitpaulk One test failure, ya?

[rohitpaulk]

@whit537 - Has to do with how we cleanup stuff in the Braintree test sandbox, I'm working on a fix.

[rohitpaulk]

Since I was in a hurry, I neglected changing to Braintree's nomenclature (and I probably left a few import pdb; pdb.set_trace()s around). We aren't running on Braintree today, I'll revisit this tomorrow.

[chadwhitacre]

Are we in danger of float errors here? Why type is cents?

[rohitpaulk]

cents is an int.

[chadwhitacre]

You positive? I thought it was a Decimal here. Regardless, if Braintree accepts dollars we should just pass dollars. We only convert to cents in _prep_hit because Balanced wanted cents (though does ach_credit also use _prep_hit)?

[rohitpaulk]

If I'm reading correctly, cents comes from _prep_hit - and https://github.com/gratipay/gratipay.com/blob/master/gratipay/billing/exchanges.py#L288

We only convert to cents in _prep_hit because Balanced wanted cents

True. I wanted to minimize the code changes here, that's why I reused the function.

though does ach_credit also use _prep_hit

No, it doesn't.

[chadwhitacre]

I wanted to minimize the code changes here, that's why I reused the function.

Yeah, we can clean that up later.

[chadwhitacre]

Reticketed as #3500.

[chadwhitacre]

!m @rohitpaulk