Setting up Recurring payments
The screenshots and names of Components and Fields were taken on an installation that was using the ‘Accept Blue’ gateway. Other gateways screens and components will be similar but a bit different, and the names of the fields will be specific to the gateway you are configuring for (eg. ‘Authorize.net Credit Card Fields Component’ instead of ‘Accept Blue Credit Card Fields Component’)
Charging recurring payments is functionally the same as Charging Previously Saved Cards, except that the payments will process automatically on a schedule.
Paytram includes tools to create multiple recurring payments easily, for use when setting up subscriptions or splitting payments.
Required Data
The Total Amount to charge
A screenflow field or data stored in a record.
# of payments to make
(ie 12 payments)
Frequency and Interval of payments
This will compute the Date to charge
Data you will need to charge a recurring payment record
Where to get this data from
Notes
Named Credential
API Name of the Credential you created with the Configuration steps above.
This will generally be constant, but can vary if you are using Paytram with multiple gateway accounts
Customer Profile ID
Payment Method record
Customer Payment ID
Payment Method record
Logical next steps to do in your Screenflow
Create or update a record in Salesforce that represents the charge that was made (e.g., a Payment record)
Show the error message response
Recurring payments can be made from any record that has fields to reference for amount, date, and payment method to charge. (Actually, the payment method doesn’t necessarily need to be stored or related to the record. For example, your workflow might support a default payment record marked as default to be retrieved and used for the charge).
A new scheduled flow (usually scheduled to run once per day), will retrieve records marked to be processed on the current date and process the charge by passing the Named Credential, Amount, Customer Profile ID and Payment Profile ID.
There are therefore two separate parts to consider when dealing with recurring payments:
- Creating the records at the desired recurring schedule (i.e. monthly, weekly, annually, etc.) - E.g. a $1200 balance is to be made with twelve $100 payments on the 1st of the month, so 12 payment records dated 1/1, 2/1, 3/1 etc need to be created. 
 
- Processing the charges on the correct dates - E.g. A flow needs to run on a daily schedule to retrieve all payments dated for the current date that are scheduled for payment, and process them using the appropriate Payment Method. 
 
2 methods to setup records for recurring payments
Creating multiple records according to a recurring schedule
Paytram includes a calculator to help split and calculate dates for recurring schedules.
For example, a payment of $1200 split over 12 months would equal 12 payments of $100 each. Creating those 12 payment records - each dated with the correct date - would be time consuming. Using the Paytram - Tool - Schedule Payments Calculator Subflow helps to manage this challenge.
When creating a new Flow to use the Schedule Payments Calculator Subflow, you will need to calculate or explicitly set the:
- Date to Start 
- Number of Payments 
- Total Amount to Charge (which will be split by the number of payments for each instance of the charge) 
- Create a Flow called, for example, ‘Create Recurring Payments’. 
- Configure the Screen with the Date to Start, Number of Payments, Frequency of Payments (if there is more than one option) and Total Amount to Charge fields. 
- Add the Paytram - Tool - Schedule Payments Calculator Subflow to the canvas and (for general usage) map the following fields: 
- Frequency (appropriate values are Monthly, Weekly, Quarterly, or Annually) 
- # of iterations: Number of payments 
- Start Date: Date to Start 
- Total Amount: Total amount to charge 
 
For our example of $1200, with the Number of iterations as 12 and a start date of 1/1/2025, the calculator will return values of $100 for AmountPerPayment, 1/1/2025 for FirstScheduledDate, 12/1/2025 for LastScheduledDate, and the following dates for the date collection variable: 1/1/2025, 2/1/2025, 3/1/2025, 4/1/2025, 5/1/2025…..12/1/2025.
You can then loop that date collection to iterate the dates and create correctly dated payment records. You will likely want to add a flag in the record to indicate that this record was not paid (i.e. have a Paid checkbox that is unchecked, or a checkbox that indicates that this is a future scheduled credit card payment), and perhaps to indicate that the scheduled date vs. the paid date, should they be different.
Additionally, you will likely want to reference the payment method to charge. This can be done as a step in the Flow similar to the Charging Previously Saved Cards sample Flow above (e.g. allow the user to choose the desired card to charge). Store the selected card as a lookup in the payment record you will be creating so that it will be available to pass to the Charge Saved Payment Method Flow.
Advanced usage
Some tips for advanced users:
- You can use custom months between payments instead of frequency. For example, 8 would create a date collection like 1/1/2025, 9/1/2025, 5/1/2026, etc. 
- If you would like to charge the last day of the calendar month (which is not constant as months can have between 28 and 31 days), enable Use Last Day of Month. 
- If Use Start Date For First Payment is also enabled and has a value, then the first date in the collection would be the date specified, and the second payment would be the last day of the following month. This can be useful if you would like to charge most payments on the last day of the month, but the first payment is to be made earlier. 
Creating open ended recurring payments (subscriptions) 
If you would like to charge the same amount on a schedule as is commonly used for subscription fees and do not want to create multiple post dated payment records as placeholders for the payments, then you would not use the Paytram Subflow calculator tool. Instead, you would simply need a record with the following fields:
- Amount to charge 
- Day of month to charge 
- Payment method lookup 
- Alternatively, you can create a ‘Default’ checkbox field on a payment method and get the default payment method of the Contact each time the recurring payment is run. 
- End date or Flag for Active/Inactive 
Follow the instructions below to learn how to charge the desired amount on the correct day.
Processing the charges on the correct dates
To charge payment records that have a date, amount, and lookup to a payment method, create a Scheduled Flow that runs daily at a specific time. For example, 6 AM daily.
- Get all records that match the criteria. For example, get all payment records dated today that have a related payment method lookup, that are unpaid, or have some other flag indicating that they are eligible to charge. 
- Insert a Wait element in the Scheduled Flow. (The minimum amount of time to wait is one minute. This is not a feature of Paytram but a limitation of Salesforce.) Add the Charge Payment Method Recurring Subflow and map the following fields: 
- Info_Amount: The amount to charge. 
- Info_CustomerProfileId: The Customer Profile Id from the referenced payment method. 
- Info_PaymentProfileId: the payment profile id of the looked up payment method 
- Info_NamedCredential: 'AcceptBlue' 
- Info_Description and info_Invoice: optional 
 
- Check the Manually Assign Variables checkbox 
- Create text variables for the Error Message and Transaction ID responses 
- Create a record variable for the GatewayLogRecord that is created when the charge card transaction is made 
- Create a boolean variable for the WasError response. This is a true/false value that tells you if the transaction was successful or not. 
 
- Use a decision element to determine whether to display the error message (if applicable) or update the payment record in Salesforce if the payment was successful to indicate that it was paid (i.e. check a Paid checkbox). 
- You MUST also specify a fault path for each component of the Flow. Without that, Salesforce will retry any failed flows which may result in duplicate charges being generated for your customers. 
Last updated