This article describes the Payment Request Generator. For information on how to configure this feature, see Configuring the Payment Request Generator. For instructions on how to run manual and automatic generator runs, see Using the Payment Request Generator.
The Payment Request Generator can be used to “stamp” Salesforce records with a valid payment reference that can be used, for instance, in mailings and payment slips. This feature is ideal for creating donation requests without having to create corresponding installments upfront. Donations that do arrive can in turn be easily matched to your Salesforce data, or instance, using Guided Matching.
|Acceptgiro (Netherlands)||Standard; Bring Your Own Base Reference|
|Bollettino Postale (Italy)||Standard; Bring Your Own Base Reference|
|ESR (Switzerland)||Standard; Bring Your Own Base Reference|
|iDEAL QR (Netherlands)||Closed Amount; Open Amount|
|OGM (Belgium)||Standard Bring; Your Own Base Reference|
|Tikkie (Netherlands)||Closed Amount; Open Amount|
The Payment Request Generator goes through the following phases during manual or automatic runs:
- New: scope being defined
- Generating: references being generated
- Done: run completed successfully
- Failed: run could not be completed
The generator currently supports three source types. The sourre type tells the Payment Request Generator where to add the generated reference.
source_type__c = 'campaign'
The reference generator stamps the Campaign record.
source_type__c = 'campaignMember'
The reference generator stamps all Campaign Member records of a campaign.
source_type__c = 'report'
The reference generator stamps all rows in a report.
The Report source type has a hard limit of 50,000 rows due to Salesforce governance limits. If this is exceeded, a specific limit error is thrown.
Payment request forms
A payment request can be in three different forms. All requests have a reference Id. In addition to this main Id value, some request types have a URL as well as a QR code.
Payment request reference Id
The reference Id is key to a payment request. It is the most basic way of requesting a payment. Sharing the reference Id with the payer ensures the incoming payment can be easily against an installment or campaign. When you generate a reference, we store this Id value in the
Payment request URL
Sometimes payment requests can be in the form of a URL. This is especially handy when you want to send something via digital channels like email or SMS. The URL also still has a reference value you can use for matching. In this case, FinDock stores the URL on a PayURL field on the target object for the generator run.
Payment request QR
For some payment requests types, the increasingly popular QR code format is available. This payment request form is always an addition to reference Id and URL forms. The QR code is useful in for both print and digital channels. Payers scan the code, which typically redirects to the payment request URL (see above).
For QR codes, FinDock takes certain actions depending on the request type:
- Stores a base64 string on the record to aid exporting the QR code to an external printing partner
- Attaches a version of the QR code image to the record for use within Salesforce (e.g. add to a case)
- Stores a public link to the image on the record
A reference type is a unique code that can be used to match incoming donations against data in Salesforce. Countries and individual service providers have different standards and ways to generate references. References often include a check digit or ‘checksum’ to test the validity of the reference.
A string of maximum 16 digits of which the first is a check digit. More details on the Acceptgiro payment reference can be found here (Dutch only).
Bollettino Postale (Italy)
A string of 16 digits of which the last two are check digits. For further information, see Bollettino Postale processing.
iDEAL QR (Netherlands)
With the Buckaroo payment extension, you can generate iDEAL QR codes. The generator service from Buckaroo creates both a Pay URL and QR code. The QR code is available via a Pay URL, Image URL and a Base 64 value that FinDock stores on the target record. For further information, see Buckaroo.
A string of maximum 12 digits of which the last two are check digits. For further information, see European Payments Council.
The Tikkie payment service uses a unique payment reference that is added to a Tikkie URL and QR code (Base 64). For further information, see Tikkie for FinDock.
The generator types may be specific to a given service, such as Tikkie. for each generator type there are required and/or optional fields you define for input and output mapping. These are dependent on both generator type and source type.
For input fields, you can select an existing field or define a specific value to use for the given generator run. Static input eliminates the need to create custom fields for specific input requirements. For instance, on a Bring Your Own generator run, you can add a one-off reference base number with the static input value.
With this generator type, FinDock generates a payment reference for you that is unique (in real-world scenarios).
The required mapping for source type Report is:
- ID Field: The column in the report that identifies the records to be stamped with a reference.
- Reference Field: The field on the records where the reference can be stored. Must be a text field with 27 characters at minimum.
The required mapping for source type Campaign or Campaign Member is:
- Campaign: The Campaign record to be stamped, or the campaign whose members will be stamped.
- Reference Field: The field on Campaign (or Campaign Member) where the reference will be stored. Must be a text field with 27 characters at minimum.
Bring Your Own Base Reference
This generator uses a base reference you define and adds the check digit at the end. For all source types, you need to tell FinDock were to find the base reference using the input Reference Field mapping. This base reference field must include a string of 26 digits or less.
The input fields are used to set the parameters for the online payment, such as amount and a description that is shown on the payment form. Output fields are also more extensive as there is more to store. In addition to the generated payment reference, there are URLs, QRs and images to store.