Skip to content
This repository has been archived by the owner on Feb 8, 2018. It is now read-only.

get our decline rate under control #3531

Closed
chadwhitacre opened this issue Jun 6, 2015 · 32 comments
Closed

get our decline rate under control #3531

chadwhitacre opened this issue Jun 6, 2015 · 32 comments

Comments

@chadwhitacre
Copy link
Contributor

From: Braintree

Hi Chad,

I hope this e-mail finds you well. We just received notification that our risk department flagged your Gratipay account as a result of a large amount of transactions being declined in your Braintree Gateway.

Of the 386 transactions recently processed, 222 have been declined. This is a huge concern for our Risk team and sponsoring bank, and our goal is to work with you to decrease the amount of declines on your merchant account so that you can resume normal processing.

In order to complete their review, the risk department is requesting:

  1. An explanation for the large amount of declines.
  2. The last three months’ bank statements showing beginning and ending balances to ensure that you are supportive of the increased risk exposure brought about by a large decline ratio.
  3. Any processing statements you may have from your most recent merchant processing relationship
  4. Itemized invoices complete with customer contact information and any applicable shipping documents for transactions [], [], and []

Funds are currently not on hold at this time. If I can be of any assistance whatsoever, please don’t hesitate to email me or call me directly at [].

Thank you in advance,

https://gratipay.freshdesk.com/helpdesk/tickets/2295

@chadwhitacre
Copy link
Contributor Author

To: Braintree

Hi, []!

Quick note to say that we've received your email, thanks for bringing the matter to our attention, and we're sorry for the trouble. :-(

The primary explanation for the large number of declines on our account is that our business model is based on weekly recurring payments, and we've simply accumulated a large number of expired or otherwise deactivated cards in the three years we've been operating, without a mechanism in place to stop attempting to charge failed cards. The easy solution for us to drastically reduce our decline rate will be to stop attempting to charge cards after one or two failures.

A secondary explanation for why the ratio is even higher than normal for us right now is that we recently started rebuilding our customer base from scratch (see Gratipocalypse and Gratipay 2.0 for background on that). I suspect that the customers for whom we have resumed processing under our new terms of service include some of our oldest customers (including Gratipay itself, which is funded on Gratipay), and, in virtue of their age, they carry a higher-than-normal decline ratio, which is skewing the overall figure.

Here's a ticket from a couple years ago when we first turned our attention to our decline rate. I've made a new ticket to address the current issue as you've raised it.

I'll follow up on Monday regarding the other three items you've requested.

@chadwhitacre
Copy link
Contributor Author

From: Braintree

Thank you very much for the explanation. We will look forward to receiving the documentation and assisting you further!

To: Braintree

Please find attached and below the remainder of the initial information you've requested. Could we schedule a call to discuss? I'd love to be able to put this info in context for you, and answer any further questions. I assume you're in Chicago, US/Central. Do any of these times work for you?

Wednesday, June 10 at 10:00 am (US/Central)
Thursday, June 11 at 10:00 am
Thursday, June 11 at 2:00 pm
Friday, June 12 at 10:00 am

2. The last three months’ bank statements showing beginning and ending balances to ensure that you are supportive of the increased risk exposure brought about by a large decline ratio.

We are a marketplace, so we keep separate operations and escrow/holding accounts. I presume you're primarily interested in the escrow. Our escrow is currently spread between five accounts. Our main escrow account is the one to which our Braintree account currently settles. It's a local credit union, and, unfortunately, I can't seem to find downloadable statements on their website. For now, I've attached a history export for this account. Let me know if you need actual statements and I will contact our credit union. Let me know, too, if you'd like to see statements for our other escrow accounts, or our operating accounts.

3. Any processing statements you may have from your most recent merchant processing relationship

We were with Balanced Payments. Their printable account statements are not the most intuitive, so for now I've attached a CSV export of our account history there. I can work on providing more detailed information if necessary.

4. Itemized invoices complete with customer contact information and any applicable shipping documents for transactions [], [], and []

Here's what I'm able to say about these three transactions:

transaction: []
customer: https://gratipay.com/~[]/
contact info: [social network link]
weekly payments:
  $[] https://gratipay.com/~[]/

transaction: []
customer: https://gratipay.com/~[]/
contact info: [social network link]
weekly payments:
  $[] https://gratipay.com/~[]/

transaction: []
customer: https://gratipay.com/~[]/
contact info: [social network link]
weekly payments:
  $[] https://gratipay.com/~[]/

@chadwhitacre
Copy link
Contributor Author

From: Braintree Risk

Thank you so much for following up and elaborating on your business.

Unfortunately, our sponsoring bank does prefer copies of statements for documentation purposes. Would you please be able to reach out to your credit union for the statements? Additionally, would you please be able to reach out to Balanced Payments for a copy of your previous processing statement?

Regarding invoices and customer information, are you able to provide us a copy of what the customers would receive as confirmation or what you keep internally for receipts? Do you collect customer phone numbers or emails when you accept payment? If so, would we please be able to have this information with the copy of the invoices?

We apologize for any frustration that may go into this additional work. We are looking forward to resolving this with you. If you have any additional questions, please let me know!

@chadwhitacre chadwhitacre added this to the Balanced Shutdown milestone Jun 10, 2015
@chadwhitacre
Copy link
Contributor Author

Adding to Balanced Shutdown because this is related to onboarding with Braintree.

@chadwhitacre
Copy link
Contributor Author

When we migrated from Balanced, we didn't bring over failure information. Consequently, we have cards in exchange_routes that we think worked last time, when in fact they failed last time.

network error = '' error > '' total
balanced-cc 3,541 125 3,666
braintree-cc 3,109 909 4,018

It looks like the address in Braintree is the card_id from Balanced, which means we should be able to update the db to reflect the most recent info we have about each card.

@chadwhitacre
Copy link
Contributor Author

Of the 386 transactions recently processed, 222 have been declined.

Do Braintree's numbers line up with our logs?

@chadwhitacre
Copy link
Contributor Author

157 was clean, so the logs should be clean and greppable.

@chadwhitacre
Copy link
Contributor Author

$ grep Holding gratipay-157.log | wc -l
     267
$ grep Holding gratipay-156.log | wc -l
     284
$

Hmmm ... where does the 386 come from?

@chadwhitacre
Copy link
Contributor Author

I called Braintree Risk and spoke with our rep there. I found in the Braintree dashboard that doing an advanced search for all transactions does show 386, though filtering by "All Unsuccesful" yields 221 results instead of 222. She said she usually looks at a "Reporting" interface that I'm not seeing, so she's going to see about the availability of that as well as the off-by-one discrepancy.

@chadwhitacre
Copy link
Contributor Author

Now to line up what we're finding in Braintree with what we've got in the logs ...

@chadwhitacre
Copy link
Contributor Author

!m @rohitpaulk

Let's pick up with numbers over on #3540.

@chadwhitacre
Copy link
Contributor Author

Actually, let's keep it here, I think.

@chadwhitacre chadwhitacre reopened this Jun 11, 2015
@chadwhitacre
Copy link
Contributor Author

156 was the only other week on Braintree, and it looks like it has a clean log as well.

@chadwhitacre
Copy link
Contributor Author

267 + 284 = 551

551 != 386

@chadwhitacre
Copy link
Contributor Author

At least failures line up:

$ cat gratipay-15{6,7}.log | grep "Holding" | wc -l
     551
$ cat gratipay-15{6,7}.log | grep "Holding.*failed" | wc -l
     221
$

@chadwhitacre
Copy link
Contributor Author

$ cat gratipay-15{6,7}.log | grep "Captured.*cents" | wc -l
     164
$

221 + 164 = 385 Off by one.

@chadwhitacre
Copy link
Contributor Author

So it looks like holds that neither fail nor settle don't register on the Braintree dashboard or reports.

@chadwhitacre
Copy link
Contributor Author

Okay! Our numbers line up.

@chadwhitacre
Copy link
Contributor Author

Let's close this after checking today's numbers (#3540).

@chadwhitacre chadwhitacre changed the title stop charging failing cards get the heck off Braintree/Wells Fargo's risk radar Jun 11, 2015
@chadwhitacre
Copy link
Contributor Author

Actually, we should keep this open until we're off the risk radar. :-(

@chadwhitacre
Copy link
Contributor Author

Declines are way down in #3540.

screen shot 2015-06-11 at 7 43 49 pm

@chadwhitacre
Copy link
Contributor Author

From: Braintree

Thank you for your call earlier today.

I was able to find the answers to the questions we discussed. The reporting tool where we quoted the “222 unsuccessful transactions” are taken from the “Transaction Summary” tab. The additional 1 transaction included in this report, which differs from the “Transactions Advanced Search”, is the 1 voided transaction, which would not be preselected for “Unsuccessful Transactions” under the “Transactions Advanced Search” report.

Hopefully this helps! Thank you for your patience and we look forward to assisting you further.

To: Braintree

Thanks for following up, I see the Transaction Summary now.

Our decline rate did end up being much lower today: 8%, compared to 59% and 56% for the previous two weeks. What's the acceptable range for our decline rate? What should we be aiming for?

Unfortunately, our sponsoring bank does prefer copies of statements for documentation purposes.

Okay, I intend to track down the New Alliance and Balanced statements tomorrow.

Do you collect customer phone numbers or emails when you accept payment?

No, we don't collect phone numbers when we accept payment. We do collect email addresses, but they're optional for buyers.

[A]re you able to provide us a copy of what the customers would receive as confirmation or what you keep internally for receipts?

I've attached an example of the email notifications (success and failure) we send when we charge someone and they have a verified email on file. Internally for receipts we use the user's so-called "history page." They have access to it as well. I've included an example screenshot for the user on the [] transaction. For successful charges, we do generate a receipt that is linked from the history page as well as the "Receipt" button/link in the success email notification. I've attached an example of that as well.

I will follow up with statements when I have them.

@chadwhitacre
Copy link
Contributor Author

To: Braintree

I stopped in at the credit union and asked for statements. Attached is what they were able to provide. Is this sufficient?

I will follow up when I have something from Balanced ...

@chadwhitacre chadwhitacre changed the title get the heck off Braintree/Wells Fargo's risk radar get our decline rate under control Jun 15, 2015
@chadwhitacre
Copy link
Contributor Author

From: Braintree

Thank you for providing the statements. We’ll provide these to our sponsoring bank to verify that they are sufficient. We’ll reach out to you Monday to follow up on your case. As for the decline rate, it should be as low as possible, ideally 0%. However, given our previous discussions about your business model, I’ll follow up with our sponsoring bank to verify an optimal range.

Looking forward to assisting you further.

@chadwhitacre
Copy link
Contributor Author

To: Braintree

Thanks, []. In addition to guidance on the target decline rate, could we also ask for guidance on the number of times to retry a failing card in a recurring payment scenario such as ours?

I've attached a ZIP file with weekly statements from Balanced going back through March (I only included statements that have credit card charges on them). With this, I believe I've provided all of the information you've requested. If I'm missing something or there is anything else that would be helpful, please let me know!

@chadwhitacre
Copy link
Contributor Author

From: Braintree

Thank you for following up with us about this review.

After speaking with our sponsoring bank, we suggest a decline rate around 15% or ideally lower. However, we understand that situations may arise where it would increase in the future. Let us know if you encounter any of these situations.

As for retrying declined cards, it does depend on the decline reason. You'll be able to view the decline reasons on the transaction page under "Processor Response Text" in the "Transaction Information" section. If the decline reason is one such as insufficient funds, or a generic decline with a reason code of 2046, we suggest trying the card again the next day. If it would decline after that, we suggest reaching out the cardholder directly to resolve the issue. However, if for another reason, such as Expired Card or Invalid credit card number, we suggest not retrying these declines and reaching out to cardholder directly to resolve it. You can see the decline reasons on the transaction page under Feel free to hover over the question mark for more detailed information about the decline.

Additionally, our sponsoring bank suggested collecting and saving cardholder information, such as phone numbers, in the future for cases where documentation may be necessary. These situations may occur if you have to dispute a chargeback and provide evidence for your supporting case.

We are closing the review at this time. Please let us know if you have any additional questions or plan to possibly have a spike in decline.

Thank you again for all of your help,

@chadwhitacre
Copy link
Contributor Author

Yesssssssss. 🐍

@chadwhitacre
Copy link
Contributor Author

Retrying cards reticketed as #3558.

@chadwhitacre
Copy link
Contributor Author

Reviewing decline rate during payday documented in gratipay/inside.gratipay.com@9a5a5a9.

@chadwhitacre
Copy link
Contributor Author

Collecting email noted on #3506.

@chadwhitacre
Copy link
Contributor Author

To: Braintree

That's good news! :D

I've added a review of our decline rate as step 24 of our weekly payday batch process. It calls or emailing [email protected] if the rate is 15% or greater for a given batch.

Now that we're not retrying failed cards at all, I've made a ticket about retrying failed cards in some circumstances as you suggest. Once we implement that it will probably increase our decline rate a bit. We'll keep an eye on it as mentioned.

We don't do a lot with phone numbers, but we do have a ticket open about requiring emails before charging users, so I've added your sponsoring bank's suggestion about collecting and saving cardholder information to that ticket.

Thanks for working with us on this, []. Let us know if anything else crops up! :-)

@chadwhitacre
Copy link
Contributor Author

From: Braintree

Thank you very much for the additional detail. This is great to have on file and we’re glad to hear that you’re taking proactive steps! That’s wonderful news. Please let us know if you have any additional questions. Don’t hesitate to reach out to us in the future.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

1 participant