Declined eChecks are listed as authorized in Salesforce

[Perc-BRC]

Hello,

Recurring gifts echeck transactions from iATS are not posting the failure to either connect or salesforce. You have access: 00D80000000LajA
(note, we know the version is one out of date, will be fixed asap-- waiting to hear back from support on an incorrectly listed version number in the upgrade).

iATS does report the transaction when it declines, in iATS backed, we saw they had failed. It doesn't seem to be talking back to C&P at that point.

Here are 2 examples--

	Transaction Date: 1/1/2017 4:22:00 AM
	Order Number: 1711722010999977611
	Gateway Transaction Number: A96B3EBF

Declined from iATS: 5 Jan 17

Transaction Date: 1/1/2017 4:37:00 AM
Order Number: 17117364562999928300
Gateway Transaction Number: A96B45C3

Declined from iATS: 8 Jan 2017

Thanks
B

[CnP.Support]

Good day Perc-BRC

Our system shows Order # 1711722010999977611 was authorized and settled on 1/1/2017 and 17117364562999928300 was also settled.

We will contact IATS to determine why the system has reported Authorized and you are seeing Declined. We are not showing any irregular activity or messages with this post as it has settled without any issues.

[CnP.Support]

Good day Perc-BRC

We have reviewed this case and see the following at IATS:



With Check we do not know what happens to the check once we send the request. The same in US, checks are submitted but not verified. The status of the check may change in 3-5 days once the check has cleared the bank.

In this case the check was originally approved but was later declined by the bank. Once a bank declines a check it stays with the gateway and we no longer are aware of its status. It is similar to a credit card if it is disputed but it rarely happens with nonprofits, whereas with checks it is more frequent.

I hope that answers your question.

[Perc-BRC]

So, how do we manage recording the decline in Click & Pledge in salesforce? We have no access to edit any of the fields in C&P Recurring or the transaction to mark the decline after the fact ourselves and this screws up reporting. They have no way to know who to contact for declines from inside salesforce, where the contact and donation history live, all the credit card declines live, and the accounting is all off. When you process hundreds of recurring gifts a month, it's not feasible to hand manage a small pool in some different fashion. Can we at least request a feature that let's you mark the transaction and recurring record as currently declining?

[CnP.Support]

Good day Perc-BRC

Given we have no way of knowing and it takes 3-5 days for the gateway to know that a transaction has declined the only way to do this is to mark the opportunity as declined by changing its stage. If it was up to us we would (seriously) not offer echecks. eChecks are handled in a completely manual basis by gateways- the ACH is sent to the bank (& there are so many of them) and then a response comes to the gateway in a file. We have no way of knowing what happens during the cycle.

We have added echeck based on client repeated requests and have tried not to offer it many times but have not won the battle. Anyone (in US) that has a checking account has a Visa or MasterCard check card. Those cards are in real time but checks are not.

For now the only solution is to change the opportunity to Closed / Lost and cancel the recurring. We can allow for the field to be updated but that will create discrepancy with the C&P Data. I guess that will not be too bad-- I still think the Opportunity stage change is the most viable solution.

[Perc-BRC]

If you have the ability to mark the C&P Transaction as declined by hand, will existing code update the C&P Recurring correctly? If you manage your recurrings from their native object-- the C&P Recurring -- only changing the opp stage leaves you unable to report on which are actually in declining stages (next transaction date in the past). These folks manage everything from the Recurring because it makes the most sense in terms of the broadest overview of the recurring program-- you see how much has been given, which transactions have authorized, you can take notes on the overall object instead of having to manage notes across all the opps, All the tasks you need to do (cancel, recharge, etc) happen in that screen.

[CnP.Support]

Perc-BRC

Thank you for the feedback.

Please note that there is no such thing as native recurring object. Salesforce does not have an object for recurring - the object you are referring to is NPSP's and it has a lot of problems, especially with indefinite recurring - that is why we do not use it. Also a lot of our clients do not use NPSP so we cannot rely on those features, given any change in the design by NPSP will adversely affect our code.

We will see how we can make the recurring management a bit easier. There is a lot that needs to happen behind the scene and given an indefinite recurring we run into SOQL errors easily.

I will work with our team to see how we can add this in a future release.. we have to figure out exactly how to deal with a lot of behind the scene issues when large data is present.

[Perc-BRC]

It was a semantic error; I mean Click & Pledge's Recurring object, the object YOUR software is using to manage all the recurring gifts, and that it makes the most sense as a user to manage your work/reporting from there as well. Native is also a word in english, not just tech speak.

It would be really helpful for me to help find them some kind of interim solution if there was some description of how the data flows for EFT in and out of salesforce, merchant account, etc. Is it the merchant account that handles the subscription and it will just stop after the first payment fails, or does C&P keep trying to send because it doesn't know the account is bad? (and therefore they must cancel it from inside C&P to avoid fees).

I think I may test having them delete the C&P Transaction w/ the maintenance tool at least so it doesn't skew the data; I assume it will recalculate the total paid, etc. I hope it will anyway!

Thanks for considering the user-friendly improvements!

[Perc-BRC]

So, is it correct functionality that deleting a transaction doesn't recalculate any of the data on the C&P Recurring record (amount paid, etc) or should I open a new ticket? Where does those calculations come from if not the transactions? Thanks!

[Perc-BRC]

Hi! Just to reiterate the last question: Should deleting the transaction for the declined echeck recalculate the amounts and last date on the C&P Recurring? It doesn't seem to, which would have been a semi-usable workaround for this issue for now, so hoping it *should* and there is something easily fixable. Not sure where those dates come from-- rollups from salesforce records or straight from the C&P API? Thanks!!