detecting eCheck chargebacks via API

[Xy]

greetings,

we have highly automated software (non-website) that processes card & eCheck transactions through your API's (which are very well designed). for our software to know about any chargebacks after the initial transaction, we are using your "getSettledBatchListRequest" with "includeStatistics=true", which gives us 31-days of transaction batches that we sift through to find any "chargeChargeBackCount" within the statistics of each batch. this would be absolutely perfect if it included either the original transId or refId or customerId (something we can link back to the original transaction and/or customer). so for step-2, we use your "getTransactionListRequest" with the batchId from the first API call and that has any "chargeChargeBackCount". this gives us the customer's first & last name and the last 4-digits of their account number, but this is not enough to make a solid identification (other customers with this same data). we then use the "settleAmount" and "submitTimeLocal" given by the 2nd API call, to search for possible matches on our side. our step-3 uses your "getTransactionDetailsRequest" with the original transId from our records, to see if the results have a "returnedItems.Description" to confirm they were the one with the chargeback.

if the "getSettledBatchListRequest" with statistics, gave us 'something' to link to any known data we have (original transId, or the original refId, or customerId) that would make life great and avoid our rather convoluted solution outlined above. is there a better way to tackle this scenario (automation to detect all chargebacks), i would be very excited to hear (maybe i'm doing it all wrong?).

thank you very much for your time and knowledge.

[Renaissance]

@Xy

Regarding the process you described below, how much of it is automated?
Each individual api call obviously is automated. Do these successions of API calls happen on an automated process? Or is each called individually?

I have built a feature for my clients where they can compare the records on their backend to the records of authorize.net that follows a similar process. The purpose of this is to check for webhooks that have not delivered or where there was some server issue that prevented the automated records updates that are triggered with a delivery.

For your chargebacks I have a rough idea in my mind that you might make a relational database that stores the original transaction I’d (you already have this I think), then I would build a script that runs through all of your transactions, indiscriminately. Have all of these API calls run on them all. Then have the script aggregate information on all of them and use a conditional to pick out the ones where chargeback = true (I’m using not actual programming but the concept). Have all of those inserted into a separate table.

I would suggest limiting your batch queries to 3 to 7 days. When you run a massive automated process like this it will tax your server. If you have a backend that you log into everyday, you may put in some Javascript to run the operation for the past 3 days, on the first page load everyday.

If you have a extremely large volume of orders, I would say that it is possible that 31 days would time your browser out. I pull 7 days transactions with my process and It takes the page 4 seconds or more to process.

So the short answer is it can all be automated. It requires some work but is 100% doable.

[Renaissance]

And it’s late. I missed the detail that your app is non-website. I think most or all of what I said would still stick.

[Xy]

many thanks for your input. i'd say 'fully automated' with virtually no human involvement other than to respond to automated notices for things it detects needing the human touch. in short, customer's incur charges throughout the month and we bill everyone on the 10th by performing a long series of API requests to process each transaction (either charging a card on file, or a bank/eCheck withdraw). we store all the transaction responses in case someone needs a partial refund or even complete reversal - we'd have the transID on file to make this a single button click.

we do see the chargeback reports within Authorize.net's backend area, but want to make sure our software knows the customer is not paid-in-full and needs to be fined for the reversal. we thought about searching our database and requesting "getTransactionDetailsRequest" on each transaction (using the transactionID we have stored) but these requests take 4.8 - 5.6 secs each and would take an excessive amount of hours to complete (even when multi-threading the requests). so we decided to go with the "getSettledBatchListRequest" which just summarizes each batch, and if there's no chargeback quantity in that batch, then we can safely skip all those transaction investigations (for now; recheck again tomorrow). the only issue i have with "getSettledBatchListRequest" is that it only gives batchID's so we then run those through a 2nd API "getTransactionListRequest" which give us a customer name and partial card/bank number. from there we search internally to try to match things up and perform more API calls to confirm we targeted the correct customer & transaction (since we didn't have anything for a perfect identification). it's a lot of convoluted API calls but we can at least check all transactions throughout each night.

so one solution is to run "getTransactionDetailsRequest" on our known/stored transactionID's but takes far too many hours to make that many API calls. we'd ahve to split up customers and chack some on mondays, others on tuesdays, wednesdays... and it could be a week before knowing of a chargeback (as worse case timing).

the other solution is to get the summaries of entire batches "getSettledBatchListRequest" but is very difficult to link that data back to the original transaction/customer (they issue a totally new transactionID on chargebacks and do not reference any of the original transaction/customer numbers).

i was hoping for a better, more efficient solution that i just wasn't seeing. or perhaps a way to get the original transactionID, or customer ID, or referenceID from authorize.net (a different API call, or parameter i missed).

[Renaissance]

Ok got ya. It sounds like each API call is initiated by your actual involvement. When you say software, this is a custom built proprietary software that you use for your business only, and not a piece of software that you market commercially to others for their use? And I’m not missing something in regards to your API calls having to be made over web servers, correct?

The reason I ask is that you can automate this whole thing if the answer to question one is it’s yours only and question two is yes you use a web server.

What you do want to do is set up a local environment (web server) on your computer. You could also use on a remote server if more than one person needs access to this function. Then you set up a database to store the data. Once you have that set up you want to set your servers timeout to some very large value, the default is 30 seconds and you want a lot more.

Next you would have to program a server side script that makes each api call in succession. So rather than making one, relaying info from that to the next one, and so on, you would want to have the first API call made, then an intermediate section of the script extracts the data from that API result needed to make the next API call. You can string as many API calls as you want together that way.

Then what you want to do is have a final section that organizes and compiles the data into what you need to issue the chargebacks. The transactions with the chargebacks will be inserted in your database. You can pull them up for view before making a decision, or if you want you could have the charge backs happen on an automated basis as well.

Once you have this set up, you will just run your individual API call and let your computer spin. That is why you set your timeout to an extreme value. The repeated API calls and data compiling will take at least a couple of minutes if you have a very large list of transactions.

And in regards to tying the orders together, it can be done. Everything I have described to you I have implemented or implemented in some roughly similar way, just not for the purpose of chargebacks. I couldnt explain it from memory as it took quite a bit of programming to get it right.

The end result I made for my clients is a table that shows their internal records side by side with what authorize has on file, with internal order and transaction numbers. The purpose is to see if their database is missing information (it never is).

To give a brief background, on our integrations on the web, the order is place BEFORE the customer pays, and then the customer is transferred to authorize to complete payment. This creates an obvious issue of having orders in our admin area that we don’t want to ship cause people did not pay.

the way to work this out is to have authorize send a webhook to our server with the results of successful transactions. Our webhooks endpoint does automated database updates to mark orders as paid each time a webhook is delivered. In the live environment we have never had one fail, ever. However out of the close to 1,000 tests I have ran in the testing environment, I have had about 10 where my scripts did not execute properly. This creates a tiny but annoying chance that there are orders in our database not marked as paid but that actually needs to be shipped because the customer is waiting on it and has been charged.

My clients are on top of their orders, but I wanted them to have a last resort if they are in doubt or want to double check. The 31 day data pull took quite a bit of time, so I have their button pull one weeks worth of data. It takes about 4 seconds to complete. I eventually want to automate this so that missing orders will automatically be detected and update as part of the script triggered by the button. They have a small business and you sound to have much more volume, which is why I recommend you set your server with the longest timeout setting allowed.