If you are using Authorize.net as your payment processor (or your clients are) for either one-time payments or automated recurring payments, then my guess is that like me you probably dread the phone call from a bookkeeper such as
"I found some Authorize.net transactions that went through and the money is in the bank, BUT there is no record of the contribution in CiviCRM. What happened?"
Researching these types of issues is very challenging because Authorize.net will never resend a Silent Post URL message, and the logging in CiviCRM about each message ( processed normally, or in error) is rather thin. As a tool to help research these issues, Pogstone Inc. created an enhanced logging feature where every silent post URL message is immediatly logged to a database table and a text file, before the message is processed. We also created a new custom search to query the new table. You can download the files needed HERE. You will need to use the SQL file to create the new database table, then put the file "AuthorizeNetIPN.php" in the folder "CRM/Core/Payment" in your custom civicrm code folder. And you will need to register the new custom search.
Warning: The message from Authorize.net includes the last 4 digits of the credit card number and the card type (such as Visa/Mastercard/Amex). I have no idea if this is allowed to be stored according to PCI rules. If you do not want this data stored, make sure you do NOT log "x_account_number" or "x_card_type" anywhere.
What I have noticed based on the data logged so far:
- When there is a failed one-time transaction, Authorize.net does send the message. However, this is not recorded as a "contribution" by CiviCRM.
- Authorize.net usually sends the CiviCRM contact ID, but not always.
What I am thinking as next steps:
- Creating a scheduled job that processes this new log file, and creates a contribution record for each transaction where one does not already exist in CiviCRM. (If the transaction failed, then the contribution status will be failed.) This would include transactions associated with subscriptions.
- If its allowable under PCI rules, store the card type and last 4 digits of the credit card on the contribution record. This info is extremely helpful for the bookkeeping staff for bank reconciliation and communicating with members/donors about credit card issues.
Would like to hear from anyone else using Authorize.net about what issues they have, and thoughts on next steps.
Once this is done, it seems like the current CiviCRM code in "AuthorizeNetIPN" that processes each message could be eliminated, as its now redundant. Also, this new approach will be MUCH easier to debug and troubleshoot, and have as part of an automated regression testing suite.
Comments
Hi Sarah I haven't looked at this solution you've posted in detail yet but I certainly recognise the requirement. Why Authorize.net can't resend like every other processor is a special mystery :-)
Hi Sarah,
We are having the same problem Were there any further suggestions as to how to deal with this?
Thanks
sj
Hello Sarah, thank you for the diligent work and contribution to the Authorize payment processor. So far I have only been testing Authorize prior to 'going live' with it, and your comments certainly give pause to using this payment processor as opposed to another, but it isn't my choice. I wonder whether you contacted Authorize.net and asked why, in fact, they won't re-send a Silent Post message? This must be an issue for users regardless of whether they use CiviCRM.
Thanks again, I will try out your contribution.
Should these files be packaged as a CiviCRM extension?