When a payment declines, via the payment processor, automatic retries, NSFs fee (Non Sufficient Funds) and emails are created in the platform.

 

Here is the process of what will happen, along with any suggested actions:

 

Quick Guide

 

In short, here is the flow:

 

• 1st payment attempt = This is considered the Scheduled 'normal' payment attempt. If declined then:
• 1st Retry  = 
  •  Scheduled payment is set to try again in 5 days. 
  •  An nsf is added and set to try in 6 days.
• 2nd retry  =
  • If the above scheduled payment declines, another nsf is added and both are put on Hold.
• If the 1st nsf declines (from day 6), that is also put on Hold.

 

Result is a scheduled payment and 2 NSFs to collect.

 

Detailed payment decline process

1st payment attempt = the 'scheduled payment' 

 

If a payment declines, the payment status shows as Declined.

A retry of the payment will schedule for 5 days later.

The NSF fee on the day after that, which is the 6th day*. 

Shown here:

 

 

In the above example, 27 Nov, 2022 was the date the payment was due, it was attempted, but declined.  The status shows that.

 

• This results in an Informational activity being created to advise the broker.
• An email is automated to the customer to advise when the payment will retry (5 days later, and NSF fee 6 days later). 
• The NSF fee would appear on the payments tab and is communicated to the customer in the email. (if NSF fee is charged).
• Also note that there will be some time on the 1st failed payment before the NSF is applied, in order to rectify possible incorrect bank details or alike.

 

* When NSF charges apply, their collection will be scheduled on the day after the retry payment. eg. If retry payment is on the 20th of the month, the NSF will be attempted on the 21st.

• This change (deployed September 7, 2022) will assist in the reduction of issues with banks flagging payments as fraudulent and reduces the volume of the policy payments also being rejected for this same reason.
•  The email that is sent to the customer, will provide appropriate dates.

Here is the email that goes to the customer:

 

 

The 1st 'retry' payment (includes NSF fee #1 on the next day)

 

• The retry payments are then attempted - with the scheduled payment and the NSF (NSF fee #1) 1 day apart as mentioned above.
• If the schedule payment retry (1st retry attempt) failed, there will be an additional NSF applied (NSF fee #2) ,  but description will change to Policy Payment Retry and will now be on HOLD, shown here in item 2:

 

 

 

• As that attempt fails, there is not a 3rd automated attempt at collecting a payment. 
• The customer does receive an email to confirm the failed payment.

 

IMPORTANT: What needs to be considered is that at that moment in time, you have the scheduled payment and the NSF #2 as declined, which happened that day. But the NSF #1 is still not due to go out until that evening, because of the way that they are scheduled to go out 1 day apart.  So the email represents that point in time and wont take into account what the outcome of that evenings attempt will be.

 

Here is the example, showing no dates are included now, there are no further automated retries but the customer must contact their broker :

 

 

• Then the next day, just the original NSF fee (NSF fee #1) will be tried.
  • You can see in the screen shot, of the payments schedule, this example. Marked under item 3 in the screen shot above (showing the Payments screen).
• If that NSF Fee declines, it is also set to Hold.
• The customer receives an additional email to confirm. This relates to just the NSF fees, example:

 

 

 

2nd 'retry' process (includes NSF fee #1 and #2) 

 

• There is no automatic retry at this point. You need to speak to your customer about collecting a payment.
• The customer will have received emails with regards to the schedule payment being missed along with an email relating to the NSFs that declined and the dates that related to.
• The status of all failed payments (including NSF fees) changes to Hold, this is to prevent the automatic payment attempt to trigger again (Payment Canada regulations).  The platform cannot simply keep trying to collect a payment. 

 

Below we see:

 

• Scheduled payment to be collected.
• 2 x NSFs

 

 

 

•  When the payment status is changed to Hold, then an activity is created (this activity will be closed automatically when the payment status is changed to anything other than hold).

 

Activity:

 

 

There are a few options at this stage:

 

• Option 1 = Collect a payment from the customer and post manually in bond.
• Option 2 = Agree with the customer that the payment processor can retry to collect the payment.
• Option 3 = Cancel the policy 

Important to note when cancelling: It is recommended to review cancellation calculations, as they may require adjustment.

 

Option 1

•  Collect a payment from the customer and post manually in bond.
• Go into the payments and post the manual payment using Pay (use the Actions icon - 3 dots) shown here:

 

 

• The status of the payment will change to Paid.
• Then the activity will be closed by the system. 
  • The activity will only close when the payment status changes to paid.

 

Option 2 

•  Agree with the customer that the payment processor can retry to collect the payment.
• Go to the payment and change the status from  "Hold" to "Unpaid".
• Then the payment processor will attempt to withdraw the payment again, later that night. 
  • If you have the permission to move payment dates, you can change the date for the customer and the processor will run the payment that night, instead. But remember, when you move payments, you will only be able to move the payments + or - 15 days from the static date (the static date is the original payment date on the policy and is the date the policy was arranged). 
  • The NSF fees dates can be changed independently to the the static payments and the other NSFs. 
• An Informational activity will be created to show the status is changed.

If this payment also declines, an NSF fee will be added (totaling NSF fee #3, if applicable) 

 

In both of the above options, if the payments are collected, the payments will continue as scheduled.

 

Option 3

• If you are unable to obtain the funds, it is recommended to cancel the policy.

• If you are unsure on the cancellation process, please refer to our articles here on Cancellations or Registered Letter Cancellations​​​​​​​

 

 

 

 

 

Every time a policy payment (whether a retry or an original scheduled payment, or taken off HOLD) declines, it creates an additional NSF fee. 

 

Here is an example of what COULD happen:

 

July 27th: Scheduled Payment – Declined

• system reschedules for a retry of the scheduled payment on Aug 1st.
• The NSF fee retry on August 2nd.

 

Aug 1^st: 1^st Retry   – Declined

• system shows on Hold
•  A second NSF fee is added (remember NSF fee retry are the day after). 

 

Aug 2nd : NSF #1 Payment Retry  - Declined

• status gets set to HOLD. If broker speaks to customer and agrees a date to retry again on Aug 15th

 

Aug 15^th : 3^rd Payment Retry (only because broker took off HOLD)  + NSF #1 and NSF #2 - declined

• Even after agreeing with the broker to take off hold and retry - payment declined now a 3rd NSF applies.
• Payment Retry + NSF #1 and NSF #2+ NSF #3 – Hold status again. 

 

 

 

 

 

There are scenarios where the platform will not create a retry of the NSF fee.  This is intended and it is most common when the payment returned error is HOLD on the card.

 

In these circumstances, just the retry of the scheduled payment is available to collect a payment for. 

 

 

 

 

There are various codes that can appear when a payment is declined. Here is a summary of SOME of those codes and what those codes mean:

 

FEE APPLIED

 

05 - AUTH DECLINED 99001
Customer has insufficient funds.

Policy Payment returned in progress.
Customer has insufficient funds.

 

NO FEE APPLIED

 

Lost or stolen card 
Customer will receive and email that says they need to contact your office

 

13 - INVALID AMOUNT 99012 
This is usually a Scotiabank customer and means the customer did not have funds in their account. 

 

43 - LOST/STOLEN CARD 99016
This means the customer has reported their card as lost/stolen. Not all lost/stolen cards will appear under this code and may come up as 05 - AUTH DECLINED 99001.

 

Policy Payment returned in progress – error
There is an issue with the card/bank account

 

412 - Precondition failure
There is an issue with the transit or institution number

 

693 - Policy Payment Retry returned

DECLINED

 

 

 

 

 

This section relates to the way that the platform handles failed payments when the response received back from the payment processor is ERROR. 

 

When the response from the payment processor is Error:

 

• The system creates an open activity for the broker, Unassigned and in the Customer Care section, including a reason code for the Error. 

   AND 

 

• There is an automated email to the customer advising they must contact their broker to make a payment. 
  •  Example provided here:

 

 

 

 

In addition, here is a list of SOME of the Error codes that you might see in the broker activity, along with some explanatory notes. This is not the complete list and varies between banking institutes and can often by unclear from the response in the platform, in which case it would always be best to ask your customer to call their bank of there is confusion or conflicting information.