• Last Processed Date:  This is the date, the payment was last successfully charged. Please also see How do I do setup catch up payment dates from Last Processed Date for other important information on how this field is used.
• Next Payment Date:  This is the date that active and qualifying Recurring Payments will be charged next.  The payment will be taken out at approximately 1am on this date.  If the payment fails to be taken out on this date (e.g. no funds available on the card), then "Retry Attempts" field will be incremented by one and the transaction will be attempted against the next day.
• Payment After Next Payment Date:  This is similar to the Next Payment Date.  If today's date is greater than or equal to this date for qualifying Recurring Payments, then the payment will be attempted on this date. An example use case for this date is for a membership that is on quarterly invoice.  The invoice is generated by the Recurring Payment record type of Payment Schedule.  If the member does NOT pay the first quarters membership invoice and the today's date then goes past when the second quarters invoice date (Payment After Next Payment Date), then a second invoice is then generated for the second quarter.
• Sign Up Date: This is the date the Recurring Payment is created, or when the donor "signs up". If left blank it will default to TODAY.
• Start Date: This is the date the Recurring Payment will start. Tokenisation will occur prior to this date. If left blank, it will default to the Payment Day (eg: if Payment Day is 1, the next 1st of the month is when the payment will start). If left blank and Payment Day is also blank it will start TODAY.
• End Date: This is the date the recurring payment is scheduled to end. If left blank, the Recurring Payment will continue indefinitely or until manually stopped.

The Payment Day is used to assign the Next Payment Date - Day.

If the Payment Day is left blank, then the next payment transaction that comes through - i.e. a payment is processed. The day of month of that payment will then be assigned to the Payment Day.

For example:

• Payment Day: blank
• Next Payment Date: 16/6/2016

Then a manual payment link to the recurring payment, or a credit card payment is processed (i.e. overnight recurring payment processor).

• The transaction date will be the 16/6/17 on the Payment Txn.
• The Payment Day will the 16 on the recurring payment
• The Last Processed Date will be set to the 16/6/17
• The Next Payment date will be set to the 16/7/17 on the Recurring Payment

If the Payment Day is assigned a number. For example, you wish to make all payments for credit cards occur the same day of a month. Then the next payment date is based on the Payment Day.

For example:

• Payment Day: 18
• Next Payment Date: 16/6/2016

Then a manual payment link to the recurring payment, or a credit card payments processed (i.e. overnight recurring payment processor).

• The transaction date will be the 16/6/17 on the payment txn.
• The Payment Day will the 16 on the recurring payment
• The Last Processed Date will be set to the 16/6/17
• The next payment date will be set to the 18/7/17 on the Recurring Payment. I.e. It has used the Payment Day to determine the day of the month.

Another scenario to consider are:

• If you blank the Payment Day out, blank out the Last Processed Date and mark the Recurring Payment as Inactive.
• OR add a new record but leave the Payment Day and Last Processed Date as blank.

Then, the Payment Day will be assigned as today 's day in the month.

For all of the above scenarios, if the Payment Day is automatically assigned and it is greater than 28, then it will be assigned "Last". "Last" indicates the last day of the month and this caters for months having varying days.

In order for a recurring payment to be considered for processing, the following need to occur:

• On the Merchant Facility, the Recurring Payment Processor must be started.

On the Recurring Payment, the following are required:

• The Recurring Payment must be active
• It must have an Amount in the "Payment Amount" field or the "Donation Amount" field
• Today's date must be greater than or equal to the either "Next Payment Date" or "Payment After Next Payment Date"
• The "Last Attempted Date/Time" must NOT be today's date
• The "Transaction Generated" must not be checked
• For Credit Cards, the "Billing Token" field must have a value.
• For Stripe, Authorize.net, PayPal and NAB Transact Payment Gateways, "Payment Gateway Customer ProfileId" is required
• The Salesforce Organization Id must match the "Organisation Id" on the related Merchant Facility. Please ensure you know the full impact if updating the Organisation id on the Merchant Facility in a full sandbox.

The Last Processed Date work in conjunction with the Next Payment Date to do catch up payments.

This process is assuming that the workflow "Last Processed Date Check for Monthly" related to the "Recurring Payment" object is not active.  If you do not want catch up to occur, then please enable this workflow.  If this workflow does not exist in your instance of Salesforce then please upgrade to the latest release.

For example:

If the following values were setup:

• Today's date is the 25/07/2016 (July 25th, 2016)
• Payment Day is set as "01"
• Last Processed Date is set as 1/04/2016 (April 1st, 2016)
• Next Payment date is set as 1/05/2016 (May 1st, 2016)
• Frequency is set as Monthly
• Amount is set as $50

The Merchant Facility - Recurring Payment Processor was started during the day of the 25/07/2016 (July 25th, 2016)

The following processing will occur over the next consecutive days:

• On the morning of the 26/07/2016 (July 26th, 2016), $50 will be charged.  The Last Processed Date will be set as 1/05/2016 (May 1st, 2016) and Next Payment Date is set as 1/06/2016 (June 1st, 2016)
• On the morning of the 27/07/2016 (July 27th, 2016), $50 will be charged.  The Last Processed Date will be set as 1/06/2016 (June 1st, 2016) and Next Payment Date is set as 1/07/2016 (July 1st, 2016)
• On the morning of the 28/07/2016 (July 28th, 2016), $50 will be charged.  The Last Processed Date will be set as 1/07/2016 (July 1st, 2016) and Next Payment Date is set as 1/08/2016 (August 1st, 2016)
• On the morning of the 28/07/2016 (July 28th, 2016), there will be no charge as all caught up
• On the morning of the 29/07/2016 (July 29th, 2016), there will be no charge as all caught up
• On the morning of the 31/07/2016 (July 30th, 2016), there will be no charge as all caught up
• On the morning of the 01/08/2016 (August 1st, 2016), $50 will be charged.  The Last Processed Date will be set as 1/08/2016 (August 1st, 2016) and Next Payment Date is set as 1/09/2016 (September 1st, 2016)

Expired

This means that the end date on the Recurring Payment has been met.

Inactive

The Recurring Payment Status is normally manually set to inactive by a user of Salesforce/Payments2Us.  This indicates that the payer no longer wishes to have payments taken out.  When setting this, you should will be required to Cancellation Reason

Suspended - Max retries exceeded

When the nightly Recurring Payment Processor runs and it finds that the it cannot successfully charge a card, then increments the number of "Retry Attempts" on the Recurring Payment Record.

Should the number for of "Retry Attempts" exceed the "Recurring Retry Attempts" on the related Payment Form, then the status will be automatically changed to "Suspended - Max retries exceeded".

Yes - if you are wanting to change  the payment method (eg: Credit Card to Direct Debit), update the record type to the Payment Method that it is to be changed to.

Make sure your record fits the criteria in Question 3 above for the next Payment Txn to be created.

Please Note: Payment Method for existing Recurring Payments CANNOT be changed to PayPal. PayPal Recurring Payments behave differently to other regular payments.

No. Only successful payment txns are included in the total number of payments.

Against  the contact record, related list “Recurring Payment”.  Go new, Select  record type “Credit Card” – Press “Next” and enter.

Add the following information

• Recurring Payment Name (Perhaps Persons Name + start date)
• Merchant Facility
• Payment Form
• Contact (should be populated)
• Account (household account for contact)
• Recurring Payment Status (“Active”)
• Enter a value for Payment Amount or Donation Amount.
• Last Processed Date – set to today
• Next Payment Date – date of next charge
• Frequency (e.g. Monthly)

1. DO NOT ENTER credit card number, exp date - this will not successfully charge the cards

Press “SAVE” button

Press the “Update Card Details” button.  Enter details. This process will also Tokenise the credit card (This step is required, otherwise the card cannot be charged)

If you want to tokenise the card now, but have it charged on a future date:

• Make sure the Enable Reccurring field on Payment Form selected is set to "Yes Tokenise on sign up, charge on selected day"
• Follow the procedure in the question 8 above - Don't press Update Card Details Yet
• Make sure the day of the month is not today's day eg: 25
• After the Recurring Processor has run (either automatically or press Run Now), check that there is a Payment Txn in the Last Update Auth. Transaction
• Note: This Txn will not appear in the related list of Payment Txns. Actual Txns after that will appear in this list
• Note: The Auth Txn will have the status set to Auth Start. This will remain at this status, not other action is required
• Warning: In the Authorisation Txn, do not press the Authorisation Process button of you only want to have this Txn as a token on the card. Pressing this will actually charge the card the authorised amount.

There are a couple of reasons why this might happen.

1. The payments are working in catch-up mode.  Check the last payment/next payment date to see if they are in the past.  Also checkout the FAQ item above:  How do I do setup catch up payment dates from Last Processed Date
2. The frequency is not a valid/pre-defined frequency.  For example, Monthly or Quarterly are valid values.  "Once-off Authorise" is not a valid frequency, nor is user added ones.

The Frequency field is used to set up the Recurring Payment, which then holds the information on of the payment frequency.

If a value other than "One-Off" is selected when creating a recurring payment, the first Payment Txn will be set to that frequency, and then it create a matching Recurring Payment. Therefore all Txns created after that are set to "One-Off" in order to not create a new Recurring Payment record every time there is a charge.

There is a recently included field called Pay Frequency for the Payment Txn object, which has the frequency of the related recurring payment so the user can see this information on the Payment Txn. Add to your page layout if it's not there already.

There is a check box field called Recurring Payment Setup. This gets checked when the Recurring Payment is created. If there was a disruption to the Payment Txn or it went to Error status originally, this box can get checked. If it is checked it will not created the Recurring Payment even if you adjust the status on the Payment Txn.

1. Check to see if this field has been checked. Untick it if so. If you cannot see this field make sure it's on the page layout.
2. Change the status to Receipting Complete. This will got through the batch processor and change to Matching Complete and create the Recurring Payment

Paypal Recurring Payments behave differently to other regular payments. Unlike credit card payments which are create and charged from withini Payments2Us and Salesforce, Paypal payments are generated within Paypal, and then the information is sent via the webhook and ID details to create a Payment Txn as a record for the payment.

The initial Payment Txn should be they type "Paypal Setup". This Payment Txn authorises the Paypal account to be charged.

Make sure that all setup requirements within Paypal are complete. See here for information about Paypal setup.

This can be done using a URL token, but not on the Payment Form itself.

On the URL token in  Default Frequeny field, select the frequency you wish to be highlighted. The user can still select a different value if they prefer.

Note: Default Frequency is a different field to Frequency. If a value is selected in the Frequency field on a URL token, that selected frequency will be locked on the web form and the user cannot change the frequency value.

No. You will have to manually update these details on the linked URL token.

Alternatively, after you have made any changes, you can remove the URL token lookup on the Recurring Payment and uncheck the create URL Token checkbox.

Then edit the Recurring Payment again and re-check the Create URL token check box. This is will create a new URL token based on the current information on the Recurring Payment.