EFT Transaction Process on Incorrect Payment Method
(Applies to SO, AB, and MGLY)
Users may report an eft transaction has processed on a payment method that was deleted or that was no longer setup for autopay, believing that the system did not properly remove/update the payment method. This is a common misunderstanding. Removing and/or editing a payment method does not affect any eft transactions that were already created prior to the change.
Whenever you make changes to a customer’s payment method always check so see if there are any pending eft transactions on the customer’s account. If there are, void them and re-create them using the new payment method information.
Here is an example scenario:
- On 1/15 the rmr cycle is run for the month of February and an invoice gets created for customer A.
- As of 1/15, credit card 1234 was flagged for auto pay, so the system creates an eft transaction for customer A for credit card 1234. This is for February billing so the eft transaction is not immediately processed. The eft sits in ready status waiting for the date of 2/1.
- On 1/20 credit card 1234 gets deleted from the customer account, and a new credit card 5678 is added and flagged for auto pay. This means all new auto-pay transactions will be created on card 5678. But the 2/1 transaction is not a new transaction, it's an old transaction that was already created and saved. The 2/1 transaction is unaffected by these edits to the cards.
- On 2/1 the transaction processes as intended to the original card 1234 it was created for.
The best way to avoid this is to void the 2/1 transaction when you delete the 1234 card, and create a new transaction manually for the 5678 card.
