Help, lost a few thousand dollars due to CC#'s disappearing????? I have been using aMember's recurring payment features with my Authorize.Net merchant account for some months. I had some problems last month which I believe was due to some recurring payment problems with version 3.1.0, or 3.1.1. After one upgrade payments started working again. But apparently a lot of payments stopped going through after that and I didn't understand the exact nature of the issue, except that the aMember upgrade was supposed to fix the problem. I upgraded to 3.1.2 but during the past month I had most of the payments not go through after that upgrade. After some research on the account errors the other day, I found more than 10-20 recurring payment accounts were coming back with the following error, which shows the credit card numbers disappeared from quite a number of accounts (which had billed successfully for a few months previously). Internal Error RESULT 3 RESULT_SUB 2 REASON_CODE 33 RESPMSG Credit card number is required. AVS P PNREF 0 CVV_VALID At first I wondered if users had used the update CC Info link to submit blank CC#'s to erase their number instead of canceling their account, but then I realized that feature will not allow the submission of a blank CC#'s. This leads me to believe the only way the CC#'s could have dissapeared from the previously successful billing accounts is through a problem in aMember, or during my upgrade which I wonder...Could an upgrade have deleted, or over written a file with CC#'s in it? I did some reading through this forum on aMember and Authorize.net payment problems, but did not see this issue addressed. I'm not an expert on code, or anything like that, but I know I've had this system working quite successfully with recurring billing for a while and need to know what's gone wrong and how to get the CC#'s back. So here's my specific questions: 1. How did those credit card numbers (and expiry dates) disappear from previously succesful recurring billing accounts? 2. Is it possible for a user, or myself to have deleted those numbers, it doesn't seem so? 3. If it was a problem with a previous version of aMember, how do I get those CC#'s back and would they exist in certain file of a previous backup? If they're encrypted, how would I read those numbers, or fix the accounts? 4. Was it a problem with an upgrade I performed overwriting a file with some of the CC#'s, if so, why didn't they all disappear and why are only some of them gone? Is that because some were added before the problem version, or after the problem version? I have no idea, because I don't even know exactly what the problem was with the problem versions. 5. Even if I can't find out at this point how the CC#'s disappeared from the accounts, is there any way I can get them back from a former backup by looking in a certain file, or since they would be encrypted is that out of the question anyway? I would not be able to replace my current file with the old one directly, because that would erase all the accounts I've gotten since then. A few days ago I upgraded to 3.1.4Pro and billing seems to be working again, but of course not for accounts without credit card numbers. So where to go from here and can I recover the few thousand dollars missing this month from failed billing?
Have you checked your existing database for the cc records? Do you have a backup of your pre-upgrade database to retrieve the cc records from?
Yes, I have a backup. Not sure if it's from the right time period when the records existed, but probably. The CC#'s are encrypted though and I can't overwrite all the current database, so how would having that help?
Now I understand where I made some wrong assumptions, because CC#'s are in the database and can not get over written by the aMember upgrade. So any other ideas where they went and was that particular version that was a problem not recording the numbers, or something? Any way to get them back? Anyone?
I don't store CC numbers.. but the last time I looked into it I tend to remember that they were not encrypted. Perhaps that has changed (suddenly I feel old) Either way, this sounds like an issue better poised for a support ticket with aMember.