search

SparkDevNetwork / Rock

An open source CMS, Relationship Management System (RMS) and Church Management System (ChMS) all rolled into one.
http://www.rockrms.com
576 stars 348 forks source link

"Abandoned" Transactions Try To Be Imported By Rock #4805

Closed JimMichael closed 2 years ago

JimMichael commented 3 years ago

A Picture Is worth a Thousand Words

image

Description

We recently switched to the NMI gateway and immediately noticed that the Download Payments job is warning about unmatched transactions. After some investigation, it looks like these are from what I call "abandoned" transactions. That is, they happen when the person goes to the giving or event reg blocks and just by STARTING a contribution/event reg, it creates a new transaction in NMI... one that has a status of Pending - 3 step

image

but 24hr later the transaction now shows as "abandoned", and these transactions DON'T exist in Rock, yet the Download Payments job tries to import and match them (and fails).

image

Steps to Reproduce

  1. Go to giving page (transaction entry block) set up for NMI gateway and enter an amount on a fund, then click Next to get to the payment details screen, but don't submit it.

  2. Close the browser

  3. Go to the NMI gateway and look at newest transactions, and see one for the amount you just STARTED to give, but abandoned.

  4. Run the Download Payments job (not sure if you have to wait overnight for this, or if it works immediately) and observe that the transaction ID of the abandoned payment cannot be matched, and the job gives a warning of such... because the transaction never actually happened in Rock, yet NMI has one...

  5. Note the exact same thing happens if you instead use the Event Registration block and get to the point where it wants your CC info, then abandon the page.

Expected behavior:

Rock would not try to import/match such abandoned transactions (or the giving/event blocks would not create such transactions in the first place when the form isn't even submitted)

Actual behavior:

Any time the transaction entry/event blocks cause the 3-step gateway pages to "start", it creates a transaction at NMI. If that transaction is not submitted (abandoned) then Rock still tries to import it the next time the job runs, and warns about not being able to match the transaction to one in Rock.

It could be argued that "this is just a cosmetic issue on the job, and doesn't really effect anything", which is technically true... no data or financial info gets messed up in all of this, as far as I can tell... however... the job "warns" of these unmatched transactions for a reason (presumably because they are supposed to be bad/unexpected/rare) and the fact that it warns for these un-match-able transactions every time a NMI form is abandoned means it will be almost impossible to notice real matching issues (such as in https://github.com/SparkDevNetwork/Rock/issues/4526) due to the high signal-to-noise ratio of these warnings.

It seems like Rock shouldn't even care about these "pending" transactions and try to deal with them or report on them in the job because it's just noise we can't do anything about.

Versions

mikedotmundy commented 2 years ago

I can confirm this is happening for us as well. This has been happening since we began with Rock (2019) and is still happening on v12.6 for us. I have never noticed any issues as a result of this, however I do agree that it would make tracing a real matching issue very difficult.

JimMichael commented 2 years ago

After looking at this further, I don’t even understand why Event transactions are being exposed to the download job at all. As far as I can tell, the Payflow gateway doesn’t work that way… event payments are “real time” CC transactions and either approved or declined. Why would Rock be trying to “match” them via the download payments job at all (which, to my understanding, only deals with recurring contributions)?

MikeDPeterson commented 2 years ago

@JimMichael Regarding your question about 'real-time' cc transactions. The DownloadPayments looks at all payments. For Real-Time transactions, that usually just amounts to updating status changes. If you are interested, here is where the relevant code is. https://github.com/SparkDevNetwork/Rock/blob/073175e7b9a95ce90453dcc44630ab1fe142c8a2/Rock/Model/FinancialScheduledTransactionService.Partial.cs#L549. As far as the 'abandoned' transactions, that is still (probably) a bug we'll have to figure out.