Your CRM is only as good as your data. Yet amazingly, there is a source of high quality, structured, readily available, and directly actionable data that remains mostly untapped. Having payment data right in the heart of Salesforce significantly increases the value of any CRM implementation.
A big part of what we do with FinDock is about enabling organisations to achieve just that: having all payment data, no matter the source, right in the core of Salesforce. To fully unlock the value of payment data, you can allow system admins to access any Salesforce tool to gain further insights, create personalised payment journeys, increase loyalty, and much more. System admins should be empowered to be agile and creative in using payment data, without having to worry about breaking payment flows or staying within Salesforce limits.
There are 5 categories of inbound payment data which are highly relevant to any CRM implementation:
Any payment intent is captured on any customer-facing channel. This includes online shops, donation pages, mobile apps, and FinDock Giving Pages.
Notifications received from Payment Service Provider (PSP) partners. Once a payment has been initiated and is being processed by a PSP, the PSP will start sending regular updates about the payment including rich enriched data, such as exchange rates, payouts, and fees. Notifications tend to be one of the most actionable sources of data, as it’s through notifications that you will learn that a payment has succeeded, failed, or is being refunded.
Bank statement files are made available by any bank. By loading and matching bank statements, you know that all your payments are in Salesforce, even if not initiated through Salesforce. For some payment methods, e.g. direct debit, bank statement files have a notification function as well.
A wide array of payment inbound reports are provided by banks or other institutions other than the bank statement files.
Many of our customers work together with partners such as Virgin Giving, FundraisingBox, Facebook donations, and face-to-face or telemarketing fundraising bureaus. All of these partners provide rich information about payments and payers captured on their platforms.
In order to get the maximum value out of all inbound payment data, regardless of its origin, three pillars need to be in place: data model, transportation, and matching.
Data model: A solution should contain a high-quality unified payments data model. Payment data only becomes valuable once it is available in a common, normalised, and easy to work with a data structure.
Transportation: Payment data needs to be brought into Salesforce. Payment data comes in all shapes and sizes, ranging from really large, complex files to high-frequency notifications.
Matching: Once the data is in Salesforce, it needs to be enriched, deduplicated, and matched to the right profile, payment, campaign, or any other custom or standard object. Just having data transported into your CRM and storing it somewhere doesn’t add much value. To make the data meaningful and actionable, it needs to be an integral part of the customer 360.
It needs to work with any customisation to the CRM data model. Payment matching should never put restrictions on what can be done with Salesforce.
Perfect 100% automated matching is not always feasible, although every customer should try to get as close as possible to that goal. A payment matching solution should be intuitive and guide users when manual intervention is needed.
There is an important business logic aspect to payment matching. Most fundamentally, it should at all times keep payment master data up-to-date with new information coming in through inbound payment events.
It should come pre-shipped with a rich matching setup so that integrators and system admins don’t have to be payment experts. It should then be highly extendable and configurable to meet specific needs.
It needs real-time and constant access to Salesforce data and customisations. We believe that this is so crucial that a payment engine has to run on Salesforce and cannot be off-platform.
It needs to be unified and support all categories of inbound payment data. The available notifications for a category can be wildly different in the real world, even within a category notifications can be very different. However, once transported into Salesforce they all start to look similar with similar matching needs. Also, integrators, system admins, and users should just have to learn one skill in order to master all of their inbound payment data.
An important thread in our recent innovations is that they combine a focus on our constantly improving and expanding Salesforce payment processing capabilities with getting better and better at the 3 pillars of inbound payment data. This is a natural and synergistic combination that we believe brings great value to our customers.
Our data model remains remarkably stable, which shows its robustness. On the transportation and matching aspects, we have been making significant strides forward. For the matching pillar, we introduced Guided Matching as our unified payment matching engine. Guided Matching runs on the Salesforce platform, works with any customisation to the data model, and has a deeply integrated manual review experience.
A new WebHub and completely overhauled Payment API adds speed, reliability, and a simpler way of capturing new payments intents. Both the new API and the new WebHub Notification Gateway bring the payment intent and notification categories to unified matching.
Within this blog, I have outlined that for most organisations, payment data is currently a heavily underutilised data asset in CRM implementations. Three pillars are required to get the maximum value out of inbound payment data: data model, transportation, and matching. FinDock is highly focussed on supporting our customers with these three pillars and getting their payment data to the core of the customer 360.
Please feel free to visit our website for more information.