Recurring Payments auto-generated processing

This article explains what happens when recurring payments are automatically generated in Vega. It will explain what settings are available to process these and how they can be reconciled against payments received or not.

Overview

Recurring payments are payments that are automatically processed on a schedule (for example, weekly, monthly, or annually). 

Recurring payments not connected to your payment gateway can be auto-generated to simplify recording and reconciling automatic payments, direct debits, and any other external regular payments. 

These auto-generated payments will be created with the status selected in Admin > Financial > Settings > Recurring Payment Settings > Recurring payment auto payment default status.

Recurring payments are generated when the finance server runs and finds all valid recurrences that are due to be processed. The finance server will also check the settings in Admin > Financial > Settings > Recurring Payment Settings for the appropriate settings for each recurrence based on a matching pay type subtype and frequency. When there is a matching pay type subtype with multiple frequency options, it will first check for a specific frequency match and then the 'All' option.

When a recurring payment will be processed

A valid recurrence is checked by the details below:

• The recurring payment status is Payment Open
• The Next Take Date and Time has been reached
• The contact account status is Active
• The recurrence fits one of these criteria:
  • The End Date is blank or greater than the current date
  • The Until Further Notice option is checked
  • The recurrence amount is less than or equal to the Total Amount Left
• The Next Take Date is within the last 2 months

Reconciling Payment Successful / Posted

This will auto-generate successful payments on each iteration of the recurring schedule, updating the recurrence to the next due and take dates each time. 

• The payment is created as Payment Successful / Posted
• The generated payment is linked to the recurrence
• The recurrence due and take dates are updated based on the frequency of the recurrence
• Xero/MYOB/Bank Transaction imports can be used to match these payments. These matches can be moved to a new batch to confirm they have been received
• An ANZ Dishonour import is available to update any matched payments to declined, and this will then follow the failed payment process
• Payments can also be manually updated to declined, directly on the payment or in bulk from the batch, and these will then follow the failed payment process
• Successful payments in the original batch have not been reconciled against the imported payments as received or declined. These donors would need to be followed up with, and the payments and recurrences updated as required

Reconciling Transaction Pending (Recommended)

This will auto-generate pending payments on each iteration of the recurring schedule, updating the recurrence to the next due and take dates each time

• The payment is created as Transaction Pending (This is not treated as a payment received in Vega)
• The generated payment is linked to the recurrence
• The recurrence due and take dates are updated based on the frequency of the recurrence
• Xero/MYOB/Bank Transaction imports can be used to match and update these payments to a successful status
• An ANZ Dishonour import is available to update any matched payments to declined, and this will then follow the failed payment process
• Payments can also be manually updated to successful or declined, directly on the payment or in bulk from the batch
• Payments remaining with the status Transaction Pending have not been reconciled, and these donors would need to be followed up with, and the payments and recurrences updated as required

Reconciling Payment Declined

This will auto-generate declined payments on each iteration of the recurring schedule, following the failed payment process

• The payment is created as Payment Declined
• The generated payment is linked to the recurrence
• The failed payment process is followed to update the recurrence as per the settings
• Xero/MYOB/Bank Transaction imports can be used to match and update these payments to a successful status. If it is the latest payment being updated, the recurrence due and take dates are updated based on the frequency and initial due date of the recurrence 
• An ANZ Dishonour import is available to update any matched payments with the dishonour reason
• Payments can also be manually updated to successful, directly on the payment or in bulk from the batch
• Remaining declined payments will follow the failed payment process unless the recurrences are manually updated

Failed payment process

Vega checks the option selected in Admin > Financial Settings > Recurring Payment Settings > On Payment Failure for the appropriate setting for each recurrence based on a matching pay type subtype and frequency when a recurring payment is declined. 

Option 1- Continue on Schedule:

• The recurrence due and take dates are updated based on the frequency of the recurrence, and another payment will only be attempted in the next iteration (weekly, monthly, etc)

Option 2- Set Retry Schedule:

The 'No. of Payment Failures' on this setting determines when the Retry Failure option is followed or if another payment is attempted. If this setting were 1, then only the first failed payment would be attempted before the recurrence was updated based on the retry failure option.

• If the number of failed payments processed within this cycle is less than the field 'No. of Payment Failures', then the recurrence next take date is updated based on the field 'Days Before Retry'. In the example settings above, after the first failed payment, the recurrence will be updated to take a payment the next day and show 1/3 failed payments:

• These declined payments are created as retry attempts in the database, linking to the retry cycle that was created with the first payment attempt. This retry database table is used in the report under Insights > Recurring Management > Failed Recurring Payments.
• This process is followed until a successful payment is made or the number of failed payments processed reaches the value in the admin setting. See details on these options below.

Final failed payment attempt

Once the number of payment attempts reaches the number in the 'No. of Payment Failures' field, and the last payment also declines, Vega will then check the option selected in Admin > Financial Settings > Recurring Payment Settings > On Retry Failure.

Option 1- Suspend Recurrence:

• The recurrence status is updated to Payment Suspended. If there is a recurring payment workflow for 'Send on Suspension' or 'Send on Suspension to Admin', then this will be triggered by this automatic status change. Suspended recurrences can be easily found from Money > Recurring Payments and select the Suspended tab. The recurring payment will not process again unless this status is updated.

Option 2- Close Recurrence:

• The recurrence status is updated to Payment Closed. Closed recurrences can be easily found from Money > Recurring Payments and select the Closed tab. The recurring payment will not process again unless this status is updated.

Option 3- Continue on Schedule:

• The recurrence due and take dates are updated based on the frequency of the recurrence and the original due date. For example, the recurrence was due on 20/01/2026. Failed payments were attempted on 21/01/2026, 22/01/2026, and 23/01/2026. The recurrence is updated based on the original due date of 20/01/2026 and the frequency, here Monthly, to 20/02/2026 and remains open.

Flowchart of gateway processing recurring payments:

Frequently Asked Questions

Can we easily find pending transactions?
Yes. In the custom query tool, you can query payments with a particular status and time frame if required.