• Last Processed Date:  The "Last Processed Date" is generally when the card was last charged, however, this is more like a "Last Processed As Of Date". There are scenarios where the date used here is not the processing date, but more a transaction date.
  If you have an early renewal, with say the end date of the subscription being 30/08/2022, then the Last Processed Date is 30/8/2022 so that the next Payment Date is calculated correctly as 30/8/2023 - i.e. Next Payment Date, End Date on subscription are calculated from this date.
  Also, if you have just a normal recurring donation and the next payment date was 15/5/22, but their charge attempts failed 2 times in a row, but succeeded on the 3^rd attempt (18/5/22). The Last Processed Date is set as 15/5/22, not the actual date of 18/5/22 so the Next Payment Date is calculated correctly from the date it was supposed to be 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.
  This date is primarily used for the Import Files and upload processing. For Import File processing of cards:
  • Tokenisation will occur when todays date is before the Start Date.
  • During the Import Process, if the Start Date is not specified, but the Payment Day is, then the Start Date will be assigned based on the Payment Day (eg: if Payment Day is 1, the next 1st of the month is when the payment will start).
  • During the Import Process, if the Start Date and Payment Day is also blank the Recurring Payment 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 27, 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 number 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 our user added ones.
3. A validation rule, custom apex coding, custom restricted pick list values, custom field marked as required at the field level, Flow/Process Builder error or 3rd Party App errors stops critical updates from occurring.
   For this, it is important to get an understanding of the process that occurs with the Recurring Payment Processing.  At a high level, this is:
   1. Nightly Recurring Payment Processor look for Active Recurring Payment Records that have a Next Payment Date on or before today's date.
   2. The Recurring Payment is charged (e.g. the Credit Card is charged)
   3. The Payment Txn record is created and updated with the successful information / details
   4. The Batch Processor runs within 10 minutes and that then update the Recurring Payment - Next Payment Date to be incremented by the frequency (e.g. Monthly)
      
      If the validation rule, custom apex coding, Restricted Picklist Values, custom field marked as required at the field level, Flow/Process Builder error or 3rd Party App errors stops critical update such as step b. creation of Payment Txn or step d. update of the Recurring Payment Processor, then the Next Payment Date is NOT updated.
      This means when the processor runs again the next morning, that recurring Payment (step a.) is still considered as not previously charged and will then charge again.  If the process is not picked up and addressed, then this will continue until it is addressed.
      
      What can you do:
      1. If this is a concern has been brought to your attention after working hours or you are not able to resolve immediately, we suggest turning of the Recurring Payment Processor until you are able to fix (don't forget to turn back on once resolved).  To turn off, navigate to the Merchant Facility, click into the primary active, then about 1/3 of the way down the page you will see Recurring Payment Processor - press STOP button.
      2. The Payments2Us Error Log should have logged the error - Review all errors for the day.
         If the error is validation rule related, see our notes on critical criteria for validation rules.
         If the error is a custom Restricted Picklist related, the field is most likely being populated by a field with the same API name on the Recurring Payment, Contact or Account.  Either fix the picklist on the source object or make the field not a restricted picklist.  You may also want to review the article on like for like field copy.
      3. Make sure the user that starts the Recurring Processor and Batch Processor has the Payments2Us Admin permission set assigned to them.
      4. To keep track of this potential issue occurring you could create a report on the Recurring Payment Object for Active Recurring Payments, that have a Next Payment Date prior to today's date and transaction generated is NOT checked and retry attempts is blank.  Schedule this to run daily and if there are any transactions then you may have an issue.
         Also, if you are not getting the error messages, you should locate the Workflow (against the Payments2Us Error Log) that sends the email alert.  Update the recipients of this to include key staff at your organisation.
         
         NOTE: Our standard support does NOT cover validation rules, custom code, custom Flows/Processor Builders, custom fields, 3rd Party Apps.

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.

When a card holder updates their card details using the link from the email then the Recurring Payment is changed from Suspended Max Retries back to Active.

Note, if you use the Card Update button on the Recurring Payment Object to update the card holders card, then you will need to mark the payment back as Active as this process does not automatically change the status

1. Create a Recurring Payment record and update the Card details via Update Card Details Button. Please note the Card Update will not work for Stripe.

2. Batch Entry

3. Transact Payment based on Payment form

4. Import files now works for most of Payment gateways.

See link FAQ 2 - https://help.payments2us.com/m/userguide/l/559156-import-files-faq#how-do-we-create-recurring-payments-from-import-files

https://help.payments2us.com/m/userguide/l/333314-import-files-overview

Also, some payment gateways can optionally enter CCV in the Checkout Form when run as an internal user.

https://help.payments2us.com/m/installation/l/1284641-what-are-the-differences-between-payment-gateways

If the field "Regular Payment Day" on the Object Payment Txn has a picklist value field checked as a default value, For example: "15" in the "Regular Payment day" field which has a picklist value.

Though its not Recurring Payment, the Regular Payment Day is assigned the default value.

The Recurring Day will have no impact on processing for non recurring Payments.

Recurring Payments are assign the Name based off {First Name} {Last Name} {method of payment} - Started {start date}

If you wish to adjust this, you can add your own custom Flow to do this.

The Payment Txn needs to be set to Receipting Complete for the Batch  processor to pickup the transactions and change to Matching complete. There are two workflow rules that set the Payment Txn status from  Payment Complete to Receipting Complete based on your Send Receipt options: "Send Receipt Automatic" and "Skip Receipt Automatic". Please check if these workflows are set in your organisation. For your Send Receipt option on the Payment form, this workflow needs to be activated. You can clone and create new workflow based on your requirements. See FAQ 4 I want to send a different email template and receipt for a specific Payment Form/Campaign. How do I do that?

We would recommend to look at flows, to see if any of your team has created flows that could impact this. Also recommend going to "Setup" and type in the quick find  'Apex Job' as this will give you an indication of what- jobs may be  running, you can also do the same for schedule jobs and background jobs.  These should give you the information you need to figure out what is  accessing the opportunity.    

The Bank Deposit Date is returned from the Payment Gateway, we do not  control that.  Generally, a failed transaction will have a bank deposit  date of the 1/1/1980 for Windcave.

We do NOT have anything that would remove donation amount.  Please  locate this field in the setup > object manager - recurring payment.   Then check where used and look for any added flows/code.

On the Payment Txn object there is a validation rule set  "Card_and_Amount_Update_cannot_reduce" they need to make this inactive.  It might be active, which is causing this as its organisation specific  feature. Please follow the link below:

https://help.payments2us.com/m/userguide/l/1497889-how-to-enable-card-holders-to-update-their-card-details#restricting-the-donors-from-reducing-gift-amount

 When someone signs up for recurring payment via Direct Debit it creates an "Auth Transactions", goes through to Matching Complete it does not associate it with the recurring schedule.

For Direct Debits are to be loaded and processed through internet banking, the initial sign up creates a Recurring Payment with a Status of "Awaiting Account Verification".  The reason for this is most banks require organisations to verify the persons that have signed up for Direct Debits before they start processing them.  We are unable to provide specifics on this as this is related to your bank and their requirements.

To get more detail on this process, please review How to process direct debit payments - before banking

If the user is getting a permissions error, like the screenshot below, then:

1. Check the User attempting to update the card has a Payments2Us Permission Set assigned to them, for example "Payments2us - Standard User"
2. Check the Users profile includes the recommended Object level permissions.
3. Check the User has permission to edit/update access to the related Contact and Account related to the Recurring Payment

These invoices are sent by Workflow.  You/your system administrator can disable this by:

• Click on Setup cog (top right), then select "Setup"
• Quick Find/search "Workflow Rules" and click into the "Workflow Rule" menu item
• Locate Workflow rule "Send Payment Schedule Invoice" that is against the "Payment Txn" object and press the "Disable" link to de-activate.