Getting started with Payment Experiences

The following is a simple overview of the steps you need to take to start working with FinDock Payment Experiences.

FinDock Payment Experiences is a pilot feature that needs to be activated in your org. Please fill out this form to sign up for the pilot.

FinDock will take you through the scope and capabilities of FinDock Payment Experiences as part of the pilot onboarding process. In addition, we recommend reading through the pilot documentation, starting with our introduction to FinDock Payment Experiences.

If you haven't already, enable Digital Experiences in your org through the Salesforce Setup.

We recommend practicing with the ready-made templates available from FinDock Labs. The site template used Salesforce Lightning Web Runtime (LWR).

Users who need access to your digital payment experience need to have the FinDock Payer permission set group. This permission set group includes two permission sets required to use the FinDock Payment Experiences components: FinDock Core Experience Cloud Run and FinDock Experience Cloud.

Apart from this permission assignment, there are a few key permission-related settings in Salesforce you need to configure to allow guest user access.

1. Assign Flow permissions.
   • Each Flow template in FinDock Labs includes pre-defined permission sets for Guest User. Deploy the repo and assign the included permission sets.
   • Go to Setup > Flows > [Your flow] > Edit Access and check the setting Override default behavior and restrict access to enabled profiles or permission sets
   • You may also need to enable specific user profiles for the flow by adding them to the list of Enabled Profiles.
2. Adjust site access.
   • Go to Setup > Sites > Builder > Settings > General and check Guest users can see and interact with the site without logging in.
   • On that same settings view, go to Guest User Profile > Enabled Flow Access > Edit and select the payment flow(s) and enable.
3. Adjust API access.
   • Go to Setup > Sites > Builder > Administration > Preferences and check Allow guest users to access public APIs.

For low-code solutions, building Flows and dropping those into Experience Cloud sites is the way to go. If you need complete control over every aspect of the digital experience, the pro-code solution is custom Lightning Web Components (LWCs). FinDock's managed components work with both approaches.

Before you get to far with development, we recommend addressing your localization requirements.

For digital payment experiences, localization covers three areas: languages, currencies, and formats for date, time and numbers. We'll go through languages and formats first. Currencies are tackled further below.

FinDock Payment Experiences fully support the standard localization tools available in Salesforce out-of-the-box:

• Translation Workbench
• XLIFF Import
• Experience Builder Languages
• CMS Content Translation

Every UI text string FinDock's managed components is implemented as a translatable Custom Label. Labels and other Flow translations are resolved to the site language while date, time and number formats are displayed based on localization component properties.

When building payment experiences, the content scope for localization includes:

1. Salesforce CMS
   Enhanced CMS Workspaces content is translated per language using content variants or exported/imported as .xlf files (Manage -> Export/Import for Translation).
2. Builder Properties
   Static text defined directly inside component properties in Experience Builder is translated manually in the property editor per language or exported/imported via Experience Builder Settings (Settings -> Languages -> Export/Import).
3. Flow forms
   Translated via Translation Workbench (Setup Component = Flow), the primary and recommended method for localizing screen component labels, headings, and help texts.
4. Packaged Custom Labels
   You can translate labels in bulk using the provided XLIFF template (translations/CustomLabels_template.xlf) via Translation Workbench (Setup -> Translate -> Import), or use Setup -> Custom Labels -> Local Translations/Overrides to override default English text or existing packaged translations directly in the UI.

The table below summarizes how FinDock Payment Experiences templates implement localization.

If you are extending or customizing FinDock Payment Experiences templates and components:

• Avoid hardcoded user-facing strings. It is always better to create a Custom Label ($Label.c.your_label_name) and reference that in your LWCs or Flow screens.
• Keep Flow formulas translatable. Avoid hardcoded literals inside Flow formulas. Instead, use Custom Label references ({!$Label.c.your_label_name}).
• Use native localization modules. Format currency and dates using @salesforce/i18n and JavaScript Intl utilities (Intl.NumberFormat, Intl.DateTimeFormat) to preserve automatic locale awareness.

Many organizations work with multiple currencies across different regions, businesses and digital experiences. Specific payment methods and method-processor combinations may also set currency restrictions. For digital payment experiences, you currency options are defined separately from locale.

To help you ensure the correct currencies are available for a given use case, we provide an unmanaged component, currencyPicker, which can be used in Flows are pro-code (paymentForm) solutions. The component is included in all FinDock Labs templates.

The currencyPicker component has two paths for determining which currencies to show to the payer. There is an explicit allow list that you can use to define which currencies to show. Currencies in the list (identified by their ISO 4217 code) must also be active in the org. Alternatively, if the allow list is not populated, the component falls back to calling an Apex class get a list of active currencies in the org.

When used in Flows, the allow list is part of the component's Custom Property Editor where you select which currencies to show and which is the default. In the pro-code paymentForm context, you manually define allowed currents with a comma-separate (CSV) string and set the default as a separate string parameter.

If you also want to restrict currencies based on the payment method and processor, you can do this with a Decision element in your Flow and branch to different currencies based on payment method and/or processor.

The currencySource property in the picker determines which currency is selected when a payer lands on the pay screen. If more than one currency is active, the payer can change the pre-selected value to some other currency. If only one currency is available, that value is pre-selected and the picker is automatically hidden.

The pre-selected value is determined as follows:

1. Default: the defaultCurrency defined in the component setup, a fixed ISO 4217 code, or a Flow variable that supplies the currency at runtime. The default must be among the active currencies in the org, otherwise, FinDock uses the fallback.
2. Experience Cloud: to pre-select a currency from page or user context, populate a Flow variable in your own flow and pass it to defaultCurrency. Also note that the payer's currency selection automatically persists for the rest of the browser session.
3. Fallback: If any of the above values are not available, the currency picker falls back to the first listed currency in the allowed list (CSV) or the first (alphabetical) active currency according to org currency settings (Apex call).

In all cases, the picker result is immediately used, so amount formatting and the pay button are correct before the payer interacts with the page.

Start building with Flows