Skip to main content

What is the Payment Request Generator?

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 direct mailings. 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.

Supported References

ReferenceGenerator types
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
Giro (OCR, Sweden)Standard
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:

  1. New: scope being defined
  2. Generating: references being generated
  3. Done: run completed successfully
  4. Failed: run could not be completed

Source Types

The generator currently supports three source types. The source type tells the Payment Request Generator where to add the generated reference.

Campaign source_type__c = 'campaign'

The reference generator stamps the Campaign record.

Campaign Member source_type__c = 'campaignMember'

The reference generator stamps all Campaign Member records of a campaign.

Report source_type__c = 'report'

The reference generator stamps all rows in a standard report. Grouped or summary reports cannot be used with this source type.

note

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 Reference field.

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

Reference Types

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.

acceptgiro (Netherlands)

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.

ESR (Switzerland)

A string of maximum 27 digits of which the last is a check digit. For further information, see Post Finance ESR Handbook in German, French, Italian or English.

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.

Giro (OCR, Sweden)

The Giro reference for Sweden is an OCR value defined by Bankgirot in Sweden. The OCR string must contain 2-25 digits, including an optional length digit and a required modulus 10 check digit. For further information, see Bankgirot Receivables.

OGM (Belgium)

OGM is string of maximum 12 digits of which the last two are check digits. For further information, see European Payments Council.

Tikkie (Netherlands)

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.

Generator Types

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.

Standard

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.

Payment Request Generator

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.

Payment Request Generator mapping for Standard type, Campaign source

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.

Other generators types

Some payment methods use other generator types or specific input variables to customize the generated reference.

For example, FinDock supports generating payment URLs and QR codes through Tikkie and Buckaroo. These use "open" and "closed" generator types that include a different range of input and open fields.

The input fields for these 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.

For Giro (Sweden), additional input fields are used for reference-specific settings, such as setting the optional OCR length digit for payment references in Sweden.