Products A-Z All Services Can't find what you're looking for? Chat Live!
Products A-Z Can't find what you're looking for? Chat Live!
Can't find what you're looking for? Chat Live!
We are currently using IATS through RE batch, and have had instances where credit cards are charged multiples times, but have not been committed multiples times into the RE database. My understand was that IATS charges the credit cards on the commit process, so I'm confused as to why cards would be charged twice without two entries into RE. Has anyone seen this problem before?
Thanks,
Marisa
Unfortunately batch is not that seamless - it does not charge during the commit process. IATS charges the card when you use the authorize credit card transactions button in batch. You then get either a decline or approved code and you are back in batch but the batch is still NOT committed.
You can set up something in Batch so that if you commit credit card gifts then the card must have been approved which will stop you from committing unauthorized gifts (but this is an optional feature in batch you can turn on-off (or may even be defaulted to off!!!) allowing unapproved or uncharged credit card to be committed) .
But there is nothing in batch that says once you have authorized a charge that the gift MUST be committed. You can accidentally never commit the entire batch and still the cards were charged and no gifts are in RE and you can even delete a batch containing authorized transactions in it that have never been committed. I believe that you can also delete rows from a batch which contain authorized credit card transactions which have not been committed.
I would suggest that batch delete rights be limited to only one or 2 people and that they not be the same person who is responsible for processing credit card batches. This way there is a checks and balances - if a batch needs to be deleted some thought is put into whether or not it is a good idea. I am not sure how batch create rights and batch edit rights are different and you may even want to restrict batch edit rights if it stops rows from being deleted.
I guess because this has never happened to me before I have honestly never thought about this possibility. I would definitely contact BB and mention this to them as it may be something they may want to consider with their new push for PCI compliance. I would even not just leave it at the level of a "suggestion" and ask that you be able to talk to someone on the team working on the PCI compliance issues in RE.
We have had the same issue. We know for sure that we did not authorize the batch twice. We only caught the error when we were reconciling the deposits. We have also had the situation in which donors were charged and we were given a declined message. The whole thing has been a mess since they upgraded the system. At this point, we have not been able to process any credit cards for nearly two weeks. We have ten of thousands of dollars waiting to be processes.
We only use IATS for monthly recurring gifts and online gifts. However, I have found it helpful to generate an IATS journal to reconcile gifts recorded in RE. If there has been a duplicate charge - it shows in this journal. You can also generate a journal for "rejected" transactions, which I have found to be especially useful.
It is an extra step, but seems to be worth it. Donors appreciate it when they have issues making an online gift and you are able to tell them..."according to our records, your gift did not go through because x, y, z...or yes, I do see that IATS double charged you..."