FinDock is a payment management application that runs natively on Salesforce. Twopir Consulting plans, implements, configures, integrates, customizes and supports it — so recurring collections, failed-payment recovery and bank reconciliation happen inside your CRM instead of around it. Architecture first, configuration second, custom development only where it earns its place.
Trusted by 500+ organizations — including subscription businesses, membership bodies and nonprofits that run recurring revenue on Salesforce with Twopir Consulting.
FinDock Delivery Coverage
Payments are usually the last workflow to reach the CRM. Everything else — the contact, the campaign, the case, the renewal conversation — is already there. The money is somewhere else, and that gap is where revenue, time and trust get lost.
Cards expire, direct debits get rejected, mandates lapse. Without an owned retry and recovery process, a failed collection becomes a cancelled subscription or a lost donor — and nobody notices until the monthly total is short.
Payment status sits in a provider portal and a finance spreadsheet. The people talking to the customer, member or donor cannot see whether the last payment succeeded, so every conversation starts with a question they should already be able to answer.
Bank statements are matched to invoices, pledges or donations by hand, line by line. The work is slow, it is repeated every month, and the answer is only ever as current as the last person who finished a spreadsheet.
Adding a local method or a second provider means another point-to-point integration, another set of webhooks, another reconciliation path. Expansion into a new market stalls on plumbing rather than on demand.
CRM totals never quite match the ledger. Campaign reporting counts pledges, finance counts settled cash, and leadership is asked to choose between two numbers that were produced by two different systems and two different definitions.
Who can issue a refund, retry a collection or change a mandate is decided informally. Under pressure that becomes over-privileged access and an audit trail nobody can reconstruct — exactly the wrong outcome for a payment process.
FinDock is a payment management application that runs natively on Salesforce. It lets an organization collect, process, reconcile and report on one-time and recurring payments inside the CRM — across payment methods such as SEPA and Bacs Direct Debit, cards, digital wallets and local bank transfers, and across payment service providers including Adyen, Stripe, GoCardless, PayPal and Worldpay. The vendor's own payments documentation describes the full model.
It is equally important to be clear about what FinDock is not. FinDock is not a payment service provider, and it is not a document generation tool. You keep your own contracts with your payment providers and your bank. FinDock orchestrates them from Salesforce, holds the resulting payment records against the customer, member or donor, and gives finance a matching and reconciliation process that runs on the same data.
The organizations that get the most from it share a shape rather than an industry: they collect money repeatedly, from many people, through more than one method. Nonprofits and fundraising teams, membership and association bodies, subscription businesses, education and healthcare providers, and any finance or revenue operations team that has been reconciling collections by hand. We work with growing, mid-market, and enterprise organizations that need help with complex CRM implementations, integrations, and business system challenges.
Three engagements, three starting points. Most organizations need one of them clearly and a little of another — the discovery call exists to work out which. Tell us where you are and we will tell you which of these you actually need.
For organizations adopting FinDock for the first time. We take it from requirements to a live, reconciled payment process — not just to an installed managed package.
For organizations already running FinDock where something is not working — usually reconciliation, recurring collections, or reporting that finance will not sign off on.
For organizations whose payment journey does not fit a standard page — a branded portal, an embedded checkout, or a process that has to reach systems outside Salesforce.
FinDock covers a large amount of payment behaviour through configuration, and configuration should always be the first answer — it upgrades cleanly and your administrators can own it. Custom development is the right answer when the requirement is about your experience or your surrounding systems rather than about the payment itself. FinDock's own documentation notes that the vendor supports its API but does not support customers' Apex, Lightning Web Component or Flow development — which is precisely the boundary this table describes, and precisely where an implementation partner earns their place.
| Requirement | Handled by configuration | Needs custom development |
|---|---|---|
| Payment methods & providers | Adding a supported method or connecting a supported provider, with its own processor settings. | A provider or method FinDock does not cover, or provider logic that has to branch on your own business rules. |
| Recurring collections | Payment schedules, collection runs, frequency, next collection date and installment generation. | Pricing or proration logic that has to be calculated elsewhere before an installment is created. |
| Reconciliation | Guided Matching rules, bank file processing, batch matching and exception queues. | Matching against a reference that only exists in another system, or writing results into an external ledger. |
| Paying online | Giving and payment pages, PayLinks for invoices and recovery, standard styling and fields. | Checkout embedded in your own portal, app or Experience Cloud site, built on the Payment API or Apex. |
| Data model | Source connector mapping to NPSP, Nonprofit Cloud Fundraising or FinDock Standalone objects. | Mapping to custom objects your organization has built, or a bespoke revenue model on top of them. |
| Notifications & follow-up | Flow-driven alerts and tasks fired from payment status changes. | Templated, multi-step recovery journeys coordinated with a marketing platform outside Salesforce. |
| Reporting | Salesforce reports and dashboards over the FinDock payment objects. | Blended finance reporting that needs data from your ERP or accounting system alongside CRM data. |
These are FinDock capabilities, configured and extended by Twopir Consulting against your operating model. The platform provides the mechanism; the engagement decides what it does in your organization.
The engine behind predictable revenue: recurring payment records that define amount, method and frequency, and payment schedules that generate the installments for each collection run.
One payment layer, many ways to pay. We configure the methods your audience expects and the providers your finance team has contracted, so adding a market is a configuration change rather than a project.
The surfaces where money is actually collected. Campaign and project pages for online giving, and PayLinks — personalised payment URLs generated from Salesforce — for invoices, failed payments and abandoned checkouts.
Where the monthly spreadsheet goes away. Incoming bank and provider transactions are matched to the right installment automatically, and the ones that cannot be matched land in a queue with a decision attached.
A failed collection is a revenue event, not an error log entry. We design what happens next — retry, reschedule, switch method, contact the payer — and make it visible to the team that owns the relationship.
History is what makes the new system trustworthy. We move existing mandates, recurring agreements and payment history into the FinDock model, then build the reporting that finance and fundraising will both accept.
FinDock sits between the record that says what is owed and the systems that move the money. An implementation is only as good as the direction and the timing of those flows.
A source connector decides which Salesforce records FinDock treats as the reason a payment exists. Amounts and schedules flow from the source object into installments; settled payments flow back onto the donation, subscription or invoice record so CRM users see the outcome without leaving the page.
Collection instructions go out to Adyen, Stripe, GoCardless, PayPal or Worldpay under your own provider contracts; authorisations, settlements, failures and refunds come back and update the installment. Because the orchestration lives in FinDock, changing provider is a configuration decision, not a rebuild.
Direct debit collection files go to the bank and statement data comes back for matching — either as uploaded bank files processed on ProcessingHub, or through FinDock Bank Feed, which imports transactions over Open Banking. Matching happens against the payment reference already on the installment.
Your own portal, app or Experience Cloud site collects the payment details and calls the FinDock Payment API — over REST, or through Apex when the journey already runs on-platform. The payment record lands in Salesforce as if it had been taken on a FinDock page, so reporting stays in one place.
For fundraising organizations the donation record is the source of truth. FinDock connects through the NPSP source connector or, on Nonprofit Cloud, through FinDock for Fundraising — so gift, recurring gift and payment records stay consistent with the fundraising model rather than living beside it.
Reconciled, settled payment data is what accounting actually wants — not pledges. We build the export or integration that carries matched payments, refunds and write-offs into the ledger on an agreed cadence, with a reference on both sides so a query can be answered from either system.
Payment status is a strong trigger and an easy one to waste. Failed collections, lapsed mandates and upgrade milestones flow out to your marketing platform so recovery and stewardship journeys fire on real payment events instead of on a monthly list someone exports by hand.
For UK charities, FinDock validates donations for Gift Aid eligibility, handles reversals, picks up historic gifts that later qualify, and submits claims to HMRC from Salesforce — which removes the export-and-upload step that usually sits between fundraising and the claim.
Six phases, one continuous engagement. Duration depends on how many payment methods and providers are in scope, how much history has to move, and how ready the source data is — not on the software, which installs in an afternoon.
We map how money reaches you today: every method, every provider, every file, every spreadsheet and every manual step between the payer and the ledger. We also find what nobody owns — usually failed collections and unmatched bank lines. This is the phase that determines the architecture, so it is not compressed.
We decide which Salesforce record is the reason a payment exists, and therefore which source connector applies. We design the relationships between that record, the recurring agreement, the installment and the payment, and we agree the reference that will be used to match money back. Getting this wrong is expensive later; getting it right makes reconciliation almost automatic.
Install and guided setup, ProcessingHub and WebHub connections, provider and payment method configuration, payment schedules, matching rules, page layouts and permission sets. Everything that can be configuration stays configuration, so your administrators can maintain it and platform upgrades stay uneventful.
The work that configuration cannot reach: checkout in your own portal, Payment API or Apex integrations, Lightning Web Components, Flow automation around payment events, and the finance or marketing system connections. Each one is justified against the boundary table above before it is built.
Provider sandbox testing for every method and every failure path, not just the happy one. Historic mandates and payment history migrated and reconciled against the old system, a parallel collection run compared line by line, then role-based training and a cutover with hypercare through the first real collection cycle.
The first months after go-live are where the matching rate, the retry policy and the exception queue get tuned against real data. From there we support releases, add methods and markets, and keep the architecture stable as volume grows — through a retained arrangement or an agreed scope of work.
Different sectors, one shape: money owed by many people, collected repeatedly, through more than one method. These are the scenarios we are asked to design most often.
Monthly and annual giving collected by direct debit or card, with upgrades, pauses and lapse recovery handled in the donor record rather than in a provider portal.
Dues and subscription fees on flexible terms, with renewal dates, tier changes and payer arrangements that differ from the member record itself.
Outstanding invoices paid through a PayLink generated in Salesforce, so the finance chase and the payment arrive in the same message and settle against the right record.
Registrations, appeals and campaign pages where every payment carries its campaign attribution, so fundraising and finance can report on the same transaction.
A committed total broken into scheduled installments, tracked against what has actually settled rather than against what was promised.
Rejections triaged by reason, retried on a policy, and escalated to a human with a recovery link when automation has done what it usefully can.
Several entities, currencies and local payment methods running on one payment model, with reporting that still rolls up to a single group view.
Moving mandates, recurring agreements and payment history off a legacy platform or a bespoke integration without losing the audit trail behind live collections.
The gains come from removing handoffs, not from working harder. These are the changes a well-designed FinDock implementation makes possible — the size of each one depends on where you are starting.
Collections run on a schedule, failures are caught and worked, and the recurring base is a number the finance team recognises rather than an estimate.
Matching runs continuously against incoming bank and provider data, so month-end becomes a review of exceptions rather than a rebuild of the whole picture.
Service, fundraising, sales and finance all read payment history from the same place, which removes an entire category of internal question and rework.
Adding a payment method, a provider or a market becomes a configuration and testing exercise instead of another bespoke integration to maintain.
Refunds, retries and write-offs happen through defined permissions and leave a record against the user who took the action — which is what an auditor and a board actually ask for.
Because settled payments, not pledges, drive the numbers, revenue reporting stops being a negotiation between two systems with two definitions.
These are representative delivery scenarios drawn from how FinDock projects are scoped — written as engagement patterns, not as client results. For measured client outcomes across our CRM and integration work, see the Twopir Consulting success stories.
A fundraising team collecting monthly gifts through a legacy direct debit bureau, with donation records updated from a file weeks after the money arrived.
FinDock already installed and collecting, but a large share of incoming bank lines still matched by hand every month because the reference design never matched the bank file.
A membership organization needing payment and renewal inside its own Experience Cloud site, where a standard hosted payment page would have broken the journey.
Installing FinDock is the easy part. The value is in the decisions taken before installation and the exceptions handled after go-live — which is where an implementation either holds or quietly falls apart.
Which record justifies a payment, how the reference is formed, how a recurring agreement relates to its installments. Those decisions determine whether reconciliation is automatic or manual for the next five years.
Configuration upgrades cleanly and your administrators can own it, so it is always the first answer. When custom development is genuinely required we say so, scope it, and justify it against the boundary we publish on this page.
A payment implementation that fundraising loves and finance cannot reconcile has failed. Both sides sign off on the reporting definitions before build starts, not during the first month-end after go-live.
FinDock rarely arrives alone. It lands in an org with existing automation, permissions, data quality and reporting — and we work on all of it, because that is what actually determines whether the payment process holds.
Matching rates, retry policies and exception queues can only be tuned against live data. We plan for that period rather than treating go-live as the end of the engagement.
FinDock work almost never happens on its own. These are the adjacent engagements it most often connects to.
The overview page: what FinDock is, how it fits a Salesforce estate, and where it sits against the rest of the payment stack.
The parent practice: implementation, org rescue, architecture and revenue operations across the Salesforce platform.
Connecting Salesforce to finance systems, portals and third-party platforms — the work that surrounds a payment implementation.
Retained support for the period after go-live, when matching rates, retry policies and exception queues get tuned against live volume.
Installing the managed package is a small part of it. A FinDock implementation is mostly design and data work: deciding which Salesforce record justifies a payment and therefore which source connector applies, designing how recurring agreements relate to installments and payments, agreeing the payment reference that will let incoming money be matched back automatically, configuring the payment methods and providers you have contracted, connecting ProcessingHub and WebHub, migrating existing mandates and payment history, and testing every failure path — not just the successful one. The phases are set out in the delivery process section above.
It depends on four things, and the software is not one of them: how many payment methods and providers are in scope, how much historic payment data has to be migrated, how clean the source records are, and how many payment journeys have to be built outside the standard pages. A single-method, single-provider implementation on tidy data with no custom checkout is a short project. Several markets, multiple providers, a portal integration and years of legacy mandates is a programme. We scope it properly during discovery rather than quoting a duration before we have seen the data.
No. FinDock is not a payment service provider — you keep your own contracts with providers such as Adyen, Stripe, GoCardless, PayPal or Worldpay, and with your bank. FinDock orchestrates them from Salesforce. That is one of the main architectural reasons to adopt it: because the orchestration lives in one layer, adding or replacing a provider later becomes a configuration and testing exercise rather than another point-to-point integration to build and maintain.
Yes, through source connectors. Organizations running the Nonprofit Success Pack install the NPSP source connector so that donation records drive payment collection and settled payments flow back to the right NPSP records. Organizations on Nonprofit Cloud use FinDock for Fundraising, which connects to the core Fundraising feature. Choosing and configuring the right connector is an architecture decision taken at the start of the project, because it determines the entire payment data model that follows.
It is widely used in fundraising, but it is not limited to it. FinDock also runs without a fundraising application at all, using its own standalone payment objects, which makes it a fit for membership dues, subscription billing, invoice collection and payment plans. The deciding factor is the shape of the problem rather than the sector: many payers, repeated collections, more than one payment method, and a finance team that needs the result reconciled.
No. FinDock is a payment management application, not a document generation tool. It produces and consumes payment artefacts — collection files for the bank, payment pages and PayLinks, Gift Aid claims for HMRC in the UK — but it does not build contracts, quotes or proposals from Salesforce templates. Document generation on Salesforce is a different category of application, and if that is the requirement, it belongs in a separate conversation about document automation rather than in a FinDock project.
Usually, yes — and it is one of the most common reasons organizations call us. A low automatic matching rate is almost always a design problem rather than a product problem: the payment reference on the installment does not survive the journey to the bank statement, matching rules were written against sample data rather than real files, or pooled settlements need batch matching that was never configured. We analyse matching failures by reason rather than by volume, redesign the Guided Matching rules around what the bank actually sends, and give the remaining exceptions an owner and a service level.
It is a shared responsibility, and treating it as somebody else's job is the risk. FinDock states that it is assessed against PCI DSS as a service provider and that it does not store, transmit or process cardholder data itself; Salesforce publishes its own compliance documentation for the platform. What remains yours is the part an implementation partner can influence: who is allowed to issue refunds, retry collections or change mandates, how those permissions are granted, and whether every action leaves an auditable record. We design that access model as part of the build. Current details are on the vendor's PCI compliance and security documentation.
Whether you are evaluating FinDock, midway through an implementation, or living with one that never quite settled, the first conversation is the same: how money reaches you today, and what it would take to make that run inside Salesforce.
Speak with a team that understands payments, Salesforce architecture & reconciliation
