FinDock allows you to perform bulk collection runs to collect payments using direct debit, credit card, etc. In this article, we go over this process using SEPA Direct Debit as an example.
- FinDock is installed and configured.
- You have installed at least one payment extension and activated a payment method that supports bulk collection.
- There are existing installments or source records in your org.
Bulk collections are initiated using the Payment Schedule object in FinDock. The Payment Schedule contains all the information needed to execute a single run.
To create and execute a payment schedule:
- Launch the FinDock app and click Setup.
- Click the Payment Schedule tab and click New.
- Leave Status as 'Scheduled.' This indicates the schedule is ready for execution.
- Finished Status can be used to give all included installments a certain status after the schedule is run. If this is required, it will be noted in the articles about the respective payment extension and payment method.
- Set the Processing Details.
- Source : select the source from where you want to generate or select Installments.
- Payment Method : select the payment method for the collection run.
- Payment Processor and Target determine how the collection run will be processed. In the example below, SEPA is the processor and the resulting file format is ING.
- Define the schedule.
- Run Date: date when the payment schedule will be executed by the scheduler.
- Selection Date: limits the Installments being generated or included. All installments with a due date on or before the selection date are included in the run (provided they also match the defined source, payment method, processor and target).
- Collection Date: date when the installments will be processed. Please note that it is a requested date. The actual date of processing is determined by your individual bank or processor.
- Set Advanced options as needed.
- Additional SOQL: further limit the installments generated and/or included. Be aware that this is complex functionality that can easily break the selection process. Use with caution.
- Process Batch Size: limit the number of records per Salesforce batch for generation of the installments. This can be useful if you have a lot of customization in your Salesforce org and run into timeouts during the generation process.
- When you have entered all the details, click Save to store the payment schedule.
The payment schedule starts the installment generation phase when picked up by the scheduled class PaymentSchedulesSchedule (see 'Schedule Apex jobs' in Configuring FinDock Core). If you want to start generating right away, you can use the Start Generation button on the Payment Schedule detail page or on the payment schedule path. There are four primary phases to the bulk collection process, as described below.
The details of how the installments are created or selected are defined by the source connector being used. In general the following needs to be true on the installments:
- Source, payment method, payment processor & target values have to match the payment schedule being executed.
- The due date has to be on or before the selection date on the payment schedule.
- If there is a payment profile , it should be active.
- If there is a mandate , it should be active.
- The status has to be 'New' or 'Pending recollection.'
If all this is true, the installment is linked to the payment schedule. If any of these is false, the installment is ignored. When the generation process ends, the status of the payment schedule is changed to 'Generated.'
The duration of the installment generation phase depends heavily on how many installments or source records there are, how much customization was done to the org, etc. The process runs using a standard Salesforce Batch Process, so you can check the status under Salesforce Setup / Apex Jobs. The precise name of the installment generator depends on the source connector.
If the payments are collected through a Payment Service Provider, instead of through a bank, no file is generated but the payments are created directly at the PSP through an API. Step 3 can thus be skipped or replaced by verifying the creation of payments in your PSP account.
The next step in the bulk collection process is the charge file creation. This step is initiated by changing the status of the payment schedule from 'Generated' to 'Process.' This status change can be done manually, or automatically by using workflow, process builder, approval processes or any of the other automation tools available in Salesforce.
Only this status change initiates the charge file creation process. Approval processes or other customization always needs to change the status from 'Generated' to 'Process,' with no other steps inbetween, to initiate this activity.
When the process is initiated, a message is placed on the outbound message queue signaling ProcessingHub to start the generation process. ProcessingHub will then:
- Synchronize the installments.
- Create the appropriate charge file (PAIN.008 in case of SEPA Direct Debit for instance).
- Deliver the charge file to the correct destination.
The last step can differ between processors and targets. If the file can be delivered directly to the Payment Service Provider or bank, the ProcessingHub will do so. In many cases, the charge file will land in the ProcessingHub file exchange Chatter group. In this case, the status of the payment schedule will change to 'Pending Verification.'
If the charge file is delivered to the Chatter group, manual verification is required. Upload the file to the appropriate bank or PSP. If the PSP or bank accepts the file, you can change the status of the payment schedule to 'Verified.' This will initiate the final phase of bulk collection.
If the status of the payment schedule is set to 'Verified,' depending on the payment method and processor being used, either the Finished Status value will be set on every installment, or ProcessingHub will start closing the installments as 'Collected.' For more details, please refer to the relevant articles for the payment extension, payment method and processor being used.