Does Stripe integrate with Salesforce?

Yes. You can connect Stripe and Salesforce with Stripe's own app for Salesforce Platform, an integration platform such as Zapier, Workato or MuleSoft, a custom API and Apex integration, or a native Salesforce payments app such as FinDock that uses Stripe as the payment processor.

What does the Stripe app for Salesforce cost to run?

The app itself is free to install; see Stripe's documentation for current terms. Stripe processing fees apply whichever option you choose. For the Stripe app, the larger cost is usually the admin and developer time needed to build and maintain the flows that connect Stripe data to your Salesforce processes.

Can I use Stripe and another payment provider in the same Salesforce org?

Yes, with a native payments app. FinDock, for example, can process card payments through Stripe and direct debit through another provider in the same org. With the Stripe app, an iPaaS or a custom build, each additional provider needs its own integration.

Can I use Stripe with Nonprofit Success Pack (NPSP)?

Yes. FinDock can process payments through Stripe and write the payment data to source apps such as Nonprofit Success Pack, so recurring donations and one-time gifts are recorded where your team already works.

Do I need a developer to integrate Stripe with Salesforce?

It depends on the option. Simple iPaaS syncs often need no developer. The Stripe app needs an admin comfortable with Flow, and Apex for more complex logic. A custom integration needs developers. A native payments app is configured by a Salesforce admin or an implementation partner.

How the four Stripe–Salesforce integration options compare.
	Stripe app	iPaaS	Custom API	Native payments app
Where payments are managed	Stripe, or Salesforce through flows you build	Stripe	Wherever you build it	Salesforce
Payment data in Salesforce	Synced Stripe billing objects	Fields you map	What you build	Native payment records
Recurring payments	Stripe Billing, plus flows you build	Mirrored from Stripe	You build it	Scheduled and tracked in Salesforce
Matching to records	Mappings you configure	Dedup rules you build	You build it	Built-in matching and dedup
Payment methods managed in Salesforce	Depends on what you build	Depends on what you map	What you build	Cards, wallets, direct debit and local methods
Other payment providers	Stripe only	A separate connector per provider	A separate integration per provider	Several providers in one org
Who maintains it	Your admins and developers	Your team, plus the iPaaS vendor	Your developers	The app vendor; your admin owns configuration

Salesforce Recurring Payments Guide: Native App vs. PSP managed

Dominyka Bortnikaite — Wed, 21 Oct 2026 14:01:31 +0000

Salesforce Recurring Payments Guide: Native App vs. PSP

Salesforce recurring payments means collecting a set amount from a customer, policyholder, member, student, or donor on a schedule, and recording every collection in Salesforce. Any setup can take the first payment. The differences show up later, when a card expires, a bank rejects a direct debit, or a payer changes accounts.

This guide follows a recurring payment through those events and covers what to check at each one, so you can judge a setup by how it handles month twelve, not month one.

How recurring payments work in Salesforce

Salesforce stores the recurring agreement: the payer, amount, frequency, and dates. In most orgs this is the recurring payment record of your payments app, linked to a contact or account. Nonprofits can also use Salesforce's own Recurring Donation (NPSP) or Gift Commitment (Nonprofit Cloud) objects. Salesforce doesn't collect the money itself. A payments app or a PSP integration does that, and each collection is recorded as its own record, usually called an installment.

There are two common setups. The difference is where the schedule lives:

PSP-managed. The PSP holds the schedule and the payment authorization and collects on its own timetable. An integration copies the results into Salesforce. Examples: Stripe's app for Salesforce, which syncs Stripe billing data into Salesforce, and the Zuora connector for Salesforce.
Native payments app. The app is installed in your Salesforce org, so the schedule, authorization, installments, and payments are all Salesforce records. It sends each collection to one or more PSPs, or to your bank as a direct debit file, and records the result. Example: FinDock generates an installment from the recurring payment record for each due date and collects it through payment schedules, which can run automatically with auto-collect.

Example: a $49 monthly ACH payment, step by step, in both setups

The agreement is recorded in Salesforce
Salesforce record
Who pays, how much, how often, and how. Each installment comes from it.

Amount
$49.00
per installment
Frequency
Monthly
1st of the month
Payment method
ACH debit
Checking •••• 4300
Mandate
ACH authorization
Signed Dec 12
PSP-managed
The PSP holds the schedule and the authorization. Salesforce shows a synced copy.

Native payments app
The recurring payment record drives the schedule, and the mandate is stored in Salesforce.
The collection: one installment per due date
Related records
Each collection has its own record and status.
Installments (4)Linked to the recurring payment
- Installment Due Jan 1
  Settled Jan 3
  $49.00Paid
- Installment Due Feb 1
  Settled Feb 3
  $49.00Paid
- Installment Due Mar 1
  R01 · includes $5.00 late fee
  $54.00Failed
- Installment Due Apr 1
  Scheduled · ACH debit
  $49.00Upcoming
PSP-managed
The PSP charges on its own timetable, and each result is copied into Salesforce.

Native payments app
Salesforce sends each due installment to the PSP or bank, in batches or automatically.
The outcome: recorded on each installment
Payment history
A payment is recorded, or a failure with its reason. Refunds, partial payments, and fees change what is still open.
- Mar 1 payment failed: R01, insufficient funds
- $5.00 late fee raises the open amount to $54.00
PSP-managed
The PSP handles retries and reminders. Salesforce sees the result after the sync.

Native payments app
The reason is recorded on the installment, and a Flow or Marketing Cloud journey can start follow-up.
Reconcile: match each payment to its installment
Matched to installment
PSP reports and bank statements are matched to the installments they pay.

PSP / Bank
ACH credit · $49.00
Feb 3 · Ref ACH-0203-7714
Matched
Salesforce
Installment · $49.00
Due Feb 1
Paid
PSP-managed
Payouts are often matched by hand, outside Salesforce.

Native payments app
PSP reports and bank statements are matched to installments in Salesforce.

Both can take a payment. The events below are where they differ. For a broader comparison, see native Salesforce payment apps vs. direct PSP integration.

Who collects recurring payments in Salesforce

Any organization that collects a fixed amount on a schedule uses the same mechanics: an agreement, an authorization, and a collection for each due date. Common examples:

Insurance: premium installments.
Financial services: repayment and fee schedules.
Education: tuition and fee plans.
Membership organizations and associations: monthly or annual dues.
Service and subscription businesses: maintenance contracts, retainers, and installment plans.
Government and public sector: recurring fees and charges.
Nonprofits and charities: monthly giving and pledges.

What changes by sector is the payment methods, the rules, and the objects that hold the agreement.

What happens over the life of a recurring payment

Sign-up: the payer authorizes future collections

The payer signs up through an online form, a payment link, or a call with your team. For cards, the payment service provider (PSP) stores a credential for later collections. For direct debit (SEPA, ACH, and other schemes), the payer signs a mandate. Some methods, such as Swish in Sweden, use a consent flow, and some PSPs need an initial payment before recurring collection can start.

What to check: Does each method you offer support recurring collection with your PSP? Is the agreement created directly on the Salesforce record you report on, rather than synced in later?

Each due date: the installment is collected

On each due date, the amount is collected through the PSP or, for self-managed direct debit, through a payment instruction file you send to your bank. Collection runs in batches, where a payment schedule picks up the installments that are due, or automatically.

What to check: Is each collection its own record with a status you can report on? Can you see what will be collected next month before it runs?

A card payment fails

Cards expire, get replaced, or are declined for insufficient funds. A failed payment needs three things: the reason recorded on the payer's record in Salesforce, a retry if the failure is temporary, and a way for the payer to fix it, such as a payment link. This sequence of retries and reminders is called dunning.

What to check: Is the failure reason visible on the payer's record in Salesforce? Who controls retries, the PSP or your team? Can you send a payment link for the open amount?

The bank rejects a direct debit

Direct debits can be rejected before collection or returned afterward, for example when an account is closed or the payer disputes the debit. Banks report these in status reports and on bank statements. SEPA uses pain.002 status reports for rejections, and ACH sends back returns with a return code, such as R01 for insufficient funds. If your setup doesn't process them, the installment is never marked as not collected, and nobody follows up.

What to check: Are rejections and returns read automatically and recorded on the installment? Can you see when a payer's collections keep failing?

The payer changes bank details or card

A new bank account needs a new mandate, and a new card needs a new stored credential. Future collections have to move to the new details, and the old mandate should stop being used.

What to check: Can your team update payment details from the Salesforce record, or does the payer have to sign up again? Does the change create the new mandate and move future installments to it?

The payer pays part, gets a refund, or owes a fee

Amounts change after the due date. A payer pays half, a refund is issued, or a late fee is added. If an installment can hold several payments and its open amount can change, the balance stays accurate in Salesforce. Otherwise these adjustments end up in spreadsheets.

What to check: Can one installment hold several payments? Are refunds linked to the original payment?

A standing order changes without notice

Standing orders are recurring bank transfers the payer sets up at their own bank. They are common in the UK, and the Netherlands has an equivalent called periodieke overschrijving. You don't initiate them, and the payer can change the amount or cancel without telling you, often with an unstructured reference.

What to check: Can incoming transfers be matched to expected installments, so missing or changed payments are flagged?

The payout arrives and needs reconciling

PSPs pay out totals, net of fees. Bank statements list individual transfers, with references payers may mistype. Reconciliation means matching every payout and transfer to the right installment. That gets difficult when a payout covers hundreds of collections with some refunded, or a direct debit batch shows up as a single credit while rejections return separately. It also gets difficult when a transfer has no reference or one in someone else's name, a payer pays two months at once or a different amount, or a payment arrives days after the installment was flagged as unpaid.

What to check: Does matching read both PSP reports and bank statements? Can one transfer be matched to several installments, or to part of one? Where do unmatched payments go for your team to review?

Sector rules add steps

Some sectors add rules on top of collection. UK charities claim Gift Aid on eligible donations, which needs a valid declaration from each donor and regular claims to HMRC. Direct debit schemes set rules for notifying payers before a collection. Each rule means more data to keep on the record and more deadlines to meet.

What to check: Can your setup hold the data these rules need, such as declarations and notice dates, on the same record as the payment? Does it show claims or notices that are due?

You add a PSP or switch providers

Adding a PSP, for a new country or payment method, is simple when the schedule lives in Salesforce: new payers use the new PSP and existing collections carry on. When the schedule lives in a PSP, a second PSP means a second set of schedules and a second sync. Switching PSPs takes more work either way, because card details are stored by the PSP that collected them and have to be transferred to the new PSP or collected again from payers. The difference is the schedules: in Salesforce they stay where they are, while in a PSP they have to be rebuilt too. Direct debit collected through your own bank files doesn't depend on a PSP at all.

What to check: Can you run more than one PSP at once, for example for different countries or payment methods? Is there a documented migration path from your current provider?

How the two setups handle these events

Event	PSP-managed	Native payments app
Sign-up	PSP checkout or a synced form; the Salesforce record arrives through the sync	Form, payment link, or agent; the record is created in Salesforce
Collection	Scheduled in the PSP	Scheduled from Salesforce records, through a PSP or bank files
Failed card payment	Retried by the PSP; follow-up runs in the PSP, or in Salesforce once the result is synced	Status and reason recorded on the installment. A Salesforce Flow or a Marketing Cloud journey can use them to start follow-up, such as an email with a payment link, and the installment can be collected again
Rejected direct debit	Reported by the PSP, if the PSP runs the debit	Read from PSP updates or bank status reports, and the installment is marked as failed
Changed payment details	Updated in the PSP; Salesforce may lag behind	New mandate or card set up from the Salesforce record
Partial payment or refund	Tracked in the PSP	Tracked on the installment
Standing orders	Not covered, because the bank initiates them	Matched to expected installments from bank statements, so missed payments show up
Reconciliation	Often manual	In Salesforce
Adding a PSP or method	New integration work	Install and configure the app's extension for that PSP

Where FinDock fits

FinDock is a native Salesforce payments app, so the schedule, mandates, installments, and payments are all Salesforce records. FinDock's own recurring payment record holds the amount, payment method, and frequency for a contact or account. It serves insurance, financial services, education, government, and nonprofit organizations.

Collection runs through payment schedules or auto-collect, using PSPs such as Stripe, Mollie, and GoCardless, or direct debit files you send to your own bank. For all supported payment methods and PSPs, see the FinDock factsheet. Each collection is an installment that can hold several payments and track refunds and late fees. FinDock processes direct debit rejections from bank status reports, handles standing orders, and reconciles PSP notifications and bank statements in Salesforce. FinDock has migration guides for recurring payments in Stripe and GoCardless, and general guidance for migrating payment data, including notes for Mollie, PayPal, and other PSPs.

Nonprofits that use Salesforce's fundraising objects can have FinDock collect against Recurring Donations in NPSP and Gift Commitments in Nonprofit Cloud instead. UK charities can also manage Gift Aid declarations and claims through a direct integration with HMRC.

Frequently asked questions

Can Salesforce collect recurring payments on its own?

Are your payments working for you in Salesforce?

Ashley Renee Hampson — Tue, 06 Oct 2026 08:09:52 +0000

At FinDock, we talk about payments all day every day, so we get to see a huge range of ways organizations manage theirs. We hear from customers who are just starting to think about bringing payments into Salesforce, usually because they're chasing a better customer experience or trying to fix an operational headache. On the flip side, we also often hear from customers who already brought payments into Salesforce… but it isn't working for them or they are looking for more flexibility or functionality, whether that's automating more of the process, extending it to new payment types, or finally connecting it to the rest of their revenue systems. In short, there are a lot of different ways it can look:

A payment provider you log into separately, where the real record lives, and a weekly export that brings some of it back
A custom integration directly with a payment service provider like Stripe that requires ongoing maintenance to keep up to date
An AgentExchange product that was the right call at the time but hasn't grown with your organization's requirements
A finance system that owns the money and a CRM that owns the relationship, with a person in the middle who reconciles the two
Just the shell of the payment that needs to be made, without any confirmation that it happened (or not!)

Payments are at the foundation of what keeps any organization going (and growing!). So if you're on Salesforce and they are causing friction, your payment management is not only not working for you, it's working against your goals.

Payments are critical data points and they deserve attention

When payments are part of your Salesforce strategy, the money movement and the record of it are the same event. The payment, the schedule behind it, the failure, the retry, all of it writes to the record it belongs to at the moment it happens, under the same security and sharing model as everything else in your org.

When payments aren't built in intentionally, the mess is not contained to the payments themselves. T1International had used Salesforce NPSP for years with a custom-built form connecting it to Stripe and PayPal. About a year and a half in, at year end giving season, hackers found the form and it became vulnerable enough that the team had to take it offline. Donations stopped. Staff went from fundraising to crisis management. Fixing it meant going back to the original developer, because nobody in-house could maintain or secure custom code. What once looked like a cost-saving decision had become a structural vulnerability.

FinDock gives payments the attention they deserve. Our customers contract around 190 million payments a year, and reconciliation runs against millions of transactions inside Salesforce rather than in a spreadsheet sitting next to it. It also stays transparent and secure. Every payment carries its own history, so you can see which attempt failed, why, what was retried, and when the bank confirmed it, without logging into a provider portal to piece it together. And because adding a provider or a payment method is configuration, not code, the thing you build today is sustainable and scalable.

Mishandling payments can cost you

You already know about the time. Of course, handling payments without secure automation takes a lot of time that most teams don't have, but the bigger costs are even more hidden.

A person can become the single point of failure. The export runs, the batch gets kicked off, the exceptions get cleared, and one person knows the order of operations. When they are out of office, everyone holds their breath.

Trust erodes, and it lands on Salesforce. When payments fail often enough, users stop distinguishing between the payment layer and the platform. They can't see the seam, so they blame what they can see. We've watched organizations arrive at a migration off a retiring product carrying so much accumulated distrust of how payments behaved that they didn't believe the new platform would work either, and the project struggled for reasons that had nothing to do with the new platform.

And everything gets harder to change. Adding a payment method, opening a new program, moving to a new billing model. Each one means unpicking the workaround before you can even start. You don't pay for a workaround once. You pay every time you want to change something.

But when it's done right, it shows. For Axepta BNP Paribas, their Salesforce org held leads and orders, EOS held invoices, SAP ran the direct debits, and a service rep answering "was I charged, and when?" had to open all three. They brought billing and payments onto Salesforce with FinDock: roughly 15,000 recurring payments a month, reconciled automatically, on the same record as the contract and the case. Customer satisfaction went from 3.95 to 4.16 out of five between 2024 and 2025.

What payments working FOR you looks like

Payment data lands in Salesforce as it happens, on the record it belongs to, without anybody exporting anything.
The date you promised is the date it runs, so your team can answer "when will I be charged?" without checking somewhere else.
Failed payments retry, or generate a link that lets someone fix it themselves, instead of turning into a call list.
Finance and the front office read the same record, so nobody reconciles two versions of the truth before a board meeting.

And adding a channel is a configuration rather than a project. Take Feeding America: migrating from the retired Salesforce NGOC onto Nonprofit Cloud, they kept the payment service provider they already had and added PayLinks and a virtual terminal for gifts arriving by phone and by mail, all managed natively in Salesforce. Changing platforms didn't mean changing processors, and integrating offline channels wasn't a custom build.

Where do you actually stand on payments?

Most teams know something isn't right but can't point at it, which makes it hard to build the case for fixing anything. We put together a short diagnostic with 25 questions for exactly that. A few minutes, and it tells you exactly where your setup is costing you with a personalized report.

If the person who built your payment form left tomorrow, who maintains it?

How many hours a month go into cleaning up payment data after the fact?

Could you tell someone today, with confidence, what date they'll be charged?

If you added a payment method next quarter, what breaks?

Where FinDock fits

FinDock is built natively on Salesforce, so payment data doesn't get synced in from somewhere else. It's already there. That's the whole difference, and it's why the workarounds above stop being necessary rather than getting automated. Want to see what that could look like for your organization? Get in touch

The post Are your payments working for you in Salesforce? appeared first on FinDock.

Dreamforce 2026: what AIforce actually means if you run payments in Salesforce

Dan Kingsley — Tue, 22 Sep 2026 08:48:55 +0000

The most revealing thing Salesforce did this year was quietly take a word off some product names. Sales Cloud is Sales Cloud again. Marketing Cloud is Marketing Cloud. That "Agentforce" prefix bolted onto everything twelve months ago has gone. Plenty of people wrote it off as marketing changing names again. As I've reflected since, I wonder it's the clearest signal of the whole week of the direction things are moving in.

You don't stop branding everything with a word unless that word has stopped describing something you sell. Agents aren't a line on the price list any more. They're how the platform gets reached. In public that showed up as AIforce: your Salesforce data, your business logic and your permissions delivered into Claude, into Slack, into whatever you already have open. Patrick Stokes said it from the stage: the value was never in the UI. It was always in the logic underneath.

I spent most of my three days in nonprofit and insurance sessions rather than platform ones, but also in lots of conversations with System Integrators across the ecosystem. The industry angles gave me a look at what customers who'd already built the thing had done and how Salesforce is now positioning it.

Three things worth your attention

AIforce and the Headless Toolkit. It runs on an open architecture of MCPs, APIs, plugins and skills. Three expressions of it shipped first: Claudeforce, a prebuilt MCP server inside Claude with sales skills. Slackforce. And Agentforce Coworker in Lightning (the normal interface of Salesforce CRM).

The detail I'd underline is the permissions model, because there isn't a new one. Agents inherit whatever the user can already see. I think that is a really important decision and it carries a consequence most orgs haven't thought about yet.

The governance layer shipped at the same time as the agents. This got less coverage, but sitting alongside AIforce is a control plane pulling together Data 360, Informatica for data prep, Tableau for semantics, Salesforce Guardian for agent identity and off-policy detection, and MuleSoft Agent Fabric as a cross-provider registry with budget tracking built in. On the admin side you also got Security Center Essentials as a free posture dashboard, a Compliance Agent surfacing privacy risk, and DSAR handling that reaches across Data 360, Archive and Backup.

Nobody builds rogue-agent detection speculatively. Salesforce has watched agent fleets turn into an operational problem in real customer orgs over the past year, and this is the answer to what they saw.

Salesforce gave up on owning the model. Koa, their first purpose-built CRM reasoning model, runs on NVIDIA's Nemotron and was trained on synthetic data. It's in pilot, but the pitch is that it matches or beats the leading models on CRM actions with roughly a third (in theory) of the errors.

At the same time Gemini went GA in the Agentforce reasoning engine and Claude is available through Bedrock. The whole thing is deliberately multi-model now. So Salesforce isn't competing on the model. It's competing on grounding and governance, which puts an uncomfortable amount of weight on whether your data is actually correct.

What this does to payment operations

Think about how your payment process really works. Someone in finance glances at the direct debit collection file on a Tuesday and notices it's light by about 9k. Someone in customer care spots a refund queued against the wrong installment because the name looked odd next to the amount. Neither of those checks is documented anywhere. They happen because a human looks at a screen every week and the screen looks wrong.

Take the screen out and those controls leave with it.

So the question for the next year isn't which agent to deploy first. Go and ask your finance team which checks only exist because somebody eyeballs a report. You'll get a longer list than you expect, and writing it down is the highest-value afternoon an architect can spend right now as we move into this new world.

You're putting probabilistic systems on top of deterministic money

Models guess well. Payments don't allow guessing. A mandate is valid or it isn't. A transaction reconciles to an installment or it doesn't. There's no confidence interval your finance director will sign off on.

I think my position on where the boundary sits is fairly firm. Let agents read payment state freely. Don't let them write to it without a deterministic gate.

Reading is where most of the value is anyway. "Why did this supporter's payment fail, what are their options, what happens if we retry on the 28th" is a question an agent can answer instantly at two in the morning, and today it generates a support ticket. However, writing payment data is a different animal. Creating a refund, changing a mandate, moving a collection date: those go through the same validated, logged path a human would trigger, with the agent calling it rather than improvising something close to it.

Which is why the Headless Experience Layer interested me. Deterministic widgets bound to real data and real business logic, droppable into any interface, is exactly how that can be handled.

Connected data isn't grounded data

Zero-copy federation will happily hand an agent a quarter's worth of unmatched bank statement lines and raw PSP notifications. The agent can see all of it. It still has no idea which payment belongs to which installment or which contact, so it'll answer your supporter with total confidence and get it wrong. That's worse than not answering.

Reconciliation is what turns transaction data into answerable data. In an agentic world that stops being a back-office nicety and becomes the precondition for anything working at all.

The clearest illustration I saw all week came from The Ocean Cleanup. Aurelia Ferraro walked through their donation certificate agent, which assembles a summary PDF of a supporter's giving on request. Small, unglamorous, genuinely useful. It works because every payment is already in Salesforce, matched to the right contact, in the right currency, with FinDock doing that underneath. The agent is the visible bit. The reason it can answer anything is that the ledger was already complete before anyone asked.

Feeding America made the same point from another angle, describing their move to Nonprofit Cloud with sustainer giving running through FinDock. Neither story was about AI. Both explain why the AI worked.

Inherited permissions

Back to that design decision. If agents inherit user permissions, your sharing model has just become your AI exposure model. Most sharing models were built for a world where somebody had to know where to click. Agents don't click. They ask. That over-permissive sharing rule on payment records or bank details or mandates, the one you've been meaning to tidy up since 2022, is now one plain-English question away from anyone with a login.

Audit the sharing model against your payment objects before you switch Coworker or Claudeforce on. Dull work maybe, but much cheaper than the alternative…

Your audit trail has a new job

Guardian giving agents their own identity matters more in payments than almost anywhere else on the platform. When an auditor or a regulator or your CFO asks who initiated a refund, "an agent did it" isn't something anyone can work with. You need agent X, acting for user Y, under policy Z, at 14:32. If your payment records can't carry that lineage today, keep agents off the write path until they can.

Where the payment layer sits in all this

Our argument at FinDock has always been that payments belong inside the system of record as first-class data. Every transaction, mandate, schedule, failure, retry, refund and match living as Salesforce data, under the platform's own permissions and audit trail.

For years you could make that case on productivity alone. Fewer integrations to maintain, and nobody's Tuesday afternoon lost to a spreadsheet.

That case has become even stronger. Once agents are reading and writing against your payment data, the quality of that data sets the ceiling on how much autonomy you can responsibly hand over. An agent is exactly as trustworthy as the ledger beneath it. If payments land in Salesforce late or partially or unmatched, no reasoning model on the market will rescue the answer it gives your supporter or customer.

That thinking sits behind what we're building with membership and donation forms on Experience Cloud, with Claude in the loop. The conversational surface is the easy part. What makes it work is that a properly structured payment lands behind it, correctly attributed and reconciled without anyone touching it.

What I'd actually do next

If you're planning a roadmap and you have your payment volume on Salesforce, I'd roughly do the following: Audit your sharing model against payment objects before the first agent goes live. Get your finance team to write down the checks that currently live in their heads, because those are about to stop happening. Fix reconciliation properly, since grounding is the whole game and there's no shortcut through it. Start agents on read-only servicing questions where the value is high and the blast radius is small. Decide your standard for agent identity and audit lineage on financial records now, while your fleet is small enough that changing your mind is cheap. Watch agentic commerce closely and don't build on it yet, because merchant of record and dispute liability aren't settled and you don't want to find that out in production.

One last thing, from a slide in a session on the Wednesday. A customer had put up a line that read:

"Technology should not make us less human, it should give us more room to be human."

In this world that's pretty specific. It means a fundraising team that doesn't lose Thursday afternoons to matching bank lines, and a finance team spending month-end on judgment instead of data entry. That's genuinely available to you. It arrives only if the matching is already right while nobody's watching it.

The post Dreamforce 2026: what AIforce actually means if you run payments in Salesforce appeared first on FinDock.

September ’26 Release Highlights

Lee Moorcroft — Sat, 19 Sep 2026 09:42:37 +0000

The September ’26 release goes into production on 20 September and has been available in sandbox environments since 23 August.

You can watch the September ’26 release webinar for a walkthrough of the main updates, or head straight to the September ’26 release notes for the full technical detail.

September brings several important steps forward for payments in Salesforce, from more flexible payment experiences and bank-validated Direct Debit mandates to new ways to give and pay and simpler payment operations.

At a glance

More flexible Payment Experiences, with new checkout and fundraising templates plus expanded localisation support.
Bank-validated e-Mandates in the Netherlands, giving organisations stronger proof behind SEPA Direct Debit collections.
More ways to give and pay, with Vipps MobilePay Donations and gift cards through Adyen.
Simpler payment operations, with more incoming payment data available directly to Guided Matching.

Here are the four highlights worth knowing:

1. Build a payment experience to fit the moment

Different payment moments call for different experiences.

Someone making a donation has different needs from someone paying an invoice or joining a membership organisation. And organisations operating across markets need payment experiences that work across different languages and currencies.

For this release, we continued to build out the open-source templates and examples behind FinDock Payment Experiences, which remains in pilot.

We have added a new single-page checkout template for simpler payment journeys such as memberships, invoices, ticketing and products. We have also expanded localisation support, making it easier to create payment experiences that adapt to the languages, currencies and formatting your customers would be familiar with, using your Salesforce org’s own localisation capabilities.

For fundraising teams, there are also new UK donation templates with Gift Aid steps already configured and fee coverage included.

You can start with a ready-made experience, adapt one of our templates to your needs, or build something much more customised while keeping FinDock underneath it to handle the payment.

Why does this matter?

That means you can change the payment experience your customer sees without having to reinvent the payment engine behind it.

Because the front end of a payment journey should fit the customer and the use case, while keeping the payment data connected to the same customer record in Salesforce

Explore the Payment Experiences templates on FinDock Labs

2. Bank-validated e-Mandates for Direct Debit in the Netherlands

An e-Mandate is a digital Direct Debit mandate that a customer authorises through their bank.

Instead of simply entering an IBAN and giving consent online, the customer chooses their bank, authenticates in their banking environment and approves the mandate there. The bank validates the mandate, and FinDock brings the mandate and its proof back into Salesforce alongside the customer and the recurring payment it authorises.

This matters because collecting a SEPA Direct Debit online does not automatically mean you have a mandate you can prove.

If a customer later says they never authorised the Direct Debit, an organisation may need to show that a valid mandate was actually given. Without that proof, a collection can potentially be challenged as unauthorised for up to 13 months.

With e-Mandates via Incassomachtigen, the mandate is validated through the payer’s bank. The normal eight-week SEPA Direct Debit refund right still applies, but the organisation has bank-validated proof of the mandate behind the collection.

Why does this matter?

For organisations collecting recurring payments by Direct Debit, it creates greater certainty around the permission behind every collection.

And because FinDock connects the mandate, its proof and the recurring payment in Salesforce, the mandate does not sit in a separate system away from the customer and their payment history.

View the demo in our September Release webinar. e-Mandates via Incassomachtigen is currently available in pilot in the Netherlands as a FinDock add-on. Speak to our Customer Success team if you would like to strengthen your Direct Debit mandate process.

3. More ways to give and more ways to pay

This release also introduces two new payment options, each opening up a different way for people to give or pay.

Vipps MobilePay Donations

For organisations fundraising in Norway, FinDock now supports Vipps MobilePay Donations.

Donors can set up their donation through the Vipps MobilePay experience, while the resulting payment information flows back into Salesforce. FinDock can then use Guided Matching to connect that activity with the donor and the rest of their payment history.

The result is a familiar local giving experience for the donor without creating a separate source of payment data for the organisation.

Gift cards through Adyen

We have also added gift cards to our Adyen integration for one-time payments.

That gives organisations another way for people to contribute towards a payment. Depending on the journey, that could mean using the balance of a gift card towards a membership, ticket, product or even donations.

And the gift card does not need to cover the full amount. If someone wants to make a €40 payment but only has €36 remaining on their gift card, they can use the gift card first and pay the remaining €4 with another supported payment method without leaving checkout.

That turns unused gift card value into something people can actually put towards a purchase or contribution, while giving organisations another opportunity to capture revenue that might otherwise have been left unused.

Why does this matter?

More ways to pay can also mean more opportunities to convert.

By letting people use the value they already have available to them and top up the difference when needed, organisations can remove another barrier between someone wanting to pay and completing that payment.

4. Guided Matching: simplifying the other side of the coin

Accepting a payment is only one side of the story. The other is everything that needs to happen after the money starts moving.

Payment providers send a lot of useful information with their notifications, and that data often plays an important role in matching a payment to the right customer, account or transaction. Until now, using a specific piece of that information in Guided Matching could require additional steps or custom work first.

With the September release, Guided Matching can work directly with more of the data already arriving from your payment providers.

That means teams can use that information to find the right account, update the right record or identify a duplicate without first having to build another layer just to make the data usable.

Why does this matter?

Because payment operations get harder as payment volumes, methods and providers grow.

Making more of the incoming payment data directly usable in Salesforce means more of the reconciliation process can be automated, while teams spend their time on the exceptions that actually need attention.

And there’s more

These are the highlights, not the full release.

September also includes improvements across refunds, payment processing, Salesforce Fundraising, existing payment integrations and the day-to-day administration of FinDock.

For the complete list of changes, configuration details and technical documentation, read the September ’26 release notes.

And if you want to see the major changes in action, watch the September ’26 release webinar.

The post September ’26 Release Highlights appeared first on FinDock.

How to connect every insurance payment to the reason behind it

Lee Moorcroft — Wed, 16 Sep 2026 14:54:02 +0000

The situation

Most carriers sell through a mix of channels. Direct via web and phone, and indirect through tied agents, brokers, and agencies. The people running that indirect channel are measured on sales, service, and the quality of the relationship with the agent.

But those teams rarely own the systems that determine, process, and record the money moving through that relationship. Premiums land in payment systems. Commissions are calculated in a policy admin system and settled through the general ledger. Between the distribution channel and the ledger there is a gap that few people in either function can see across.

The gap becomes visible whenever someone needs to understand a payment. A customer questions a premium collection. A broker wants to understand an adjustment. An agent receives a monthly payout and wants to know how the figure was reached. A claimant wants to understand a disbursement.

What happens today

One common example is the monthly agent payout. One payment, once a month, covering everything they are owed.

Underneath that figure sit hundreds or thousands of individual line items. Premiums collected, commissions earned, claims paid on the carrier's behalf, adjustments, clawbacks. What the agent can see is a payment reference and an amount. Payment one, payment two, payment three. The agent sees the result, but not the calculation behind it.

If the number matches what they expected, nobody asks anything. When it doesn't, the agent calls the carrier. Somebody in distribution or finance then works backwards through the underlying records to explain how the figure was reached. That reconstruction is manual, it happens after the fact, and it repeats every month for every agent who queries a statement.

For a carrier with a large distribution network, that is a permanent support load, and it lands on the team whose actual job is selling.

The same problem appears elsewhere in the payment lifecycle. A customer questions a premium debit. A claimant wants to understand a payout. A broker queries an adjustment. Different transaction, same underlying problem: the payment record shows what moved, but not enough of the business context behind why it moved.

Why the gap is hard to close

A payment record is built for processing a payment. It holds a reference, an amount, a date, a status. On its own it explains nothing, because the reason the payment exists lives somewhere else: in the policy it relates to, or the claim it settled, or the commission agreement behind it.

Reporting on payment data does not solve this. Neither does giving agents access to the policy admin system, which describes the contract in detail but says nothing about what was collected, what lapsed, or what has been paid out.

To explain any payment properly, the transaction has to be connected to the business event that caused it.

What FinDock does

FinDock connects payment activity to the policy, claim, commission, or other insurance record behind it, so a line item carries its own explanation. That gives collections and disbursements the business context needed to explain what moved, by whom, to whom, and why.

Payments arrive with their context attached.
Policy, claim, commission and other relevant insurance records can remain connected to the transactions they relate to.
Collections and disbursements use the same payment context.
Whether the carrier is collecting a premium, paying a claim, issuing a refund or settling commission, the transaction can be traced back to the reason it exists.
The details can be surfaced where people need it.
Customers, agents and brokers can see relevant payment information through the portals and experiences they already use.
Teams can investigate exceptions in Salesforce.
When something needs attention, payment and insurance context sit together rather than requiring teams to reconstruct the transaction across systems.

What changes with FinDock

Customers can understand what they were charged and which policy or instalment it relates to
Agents and brokers can see how commissions, adjustments and other disbursements were reached
Claims teams can trace payouts back to the claim and recipient
Service and finance teams investigate payment questions with the underlying insurance context already available
The same connected data can be surfaced through customer, broker and agent portals

Where FinDock fits

FinDock does not decide what is owed, collected or paid. The policy, claims or commission system determines what should happen and when. FinDock manages the resulting payment flow and connects the transaction back to the records that explain it.

This use case fits carriers that already know what should be collected or paid, but struggle to connect the resulting transaction back to its insurance context.

Who is the best fit for

You collect or disburse money across customers, brokers, agents or other parties
Payment activity needs to stay connected to policies, claims, commissions or other insurance records
Service, finance or distribution teams regularly reconstruct payment history across systems
Customers or intermediaries need better self-service visibility into collections and payouts
You want to expose payment information through existing Salesforce experiences or portals rather than introduce another disconnected system

In insurance, money moves for many different reasons. FinDock connects each payment flow to the insurance context that explains why it exists.

The post How to connect every insurance payment to the reason behind it appeared first on FinDock.

How to process donations in Salesforce: apps, setup, and best practices

Dominyka Bortnikaite — Wed, 09 Sep 2026 12:56:22 +0000

Salesforce payments

How to process donations in Salesforce: apps, setup, and best practices

September 9, 2026

Salesforce records donations, but it does not collect money on its own. To process donations in Salesforce you add a payments layer that connects one or more payment service providers (PSPs), captures the payment, and syncs the result back to your donation records. There are two broad routes: a Salesforce-native payments app that runs inside your org, or a direct PSP integration that pushes data in from outside.

What is donation processing in Salesforce?

It helps to separate two things that are often confused:

➜

Recording a donation — the data model that stores the gift. In the Nonprofit Success Pack (NPSP) this is the Opportunity, Recurring Donation, and Payment objects; Agentforce Nonprofit (formerly Nonprofit Cloud) uses Gift Transactions.

➜

Collecting the payment — actually moving the money from the donor via a card, direct debit, or bank transfer, then confirming and reconciling it.

Agentforce Nonprofit (formerly NPC) and NPSP handle the first part well. They do not collect payments by themselves. Donation processing is what connects the collection step to your records so that a completed payment updates the right Opportunity or Recurring Donation automatically.

Native donation apps vs. direct PSP integrations

This is the core decision, and it shapes everything downstream. The difference is where the payment logic lives.

Consideration	Salesforce-native app	Direct PSP integration
Where data lives	Inside Salesforce; the payment record is created and matched in your org	In the PSP first, then pushed or imported into Salesforce
Recurring donations	Managed against NPSP Recurring Donations or Nonprofit Cloud Gift Commitments, tied to mandates in Salesforce	Often managed in the PSP, with sync gaps to watch
Reconciliation	Automated matching of PSP notifications and bank files to installments	Manual or custom-built matching between two systems
PCI scope	Cardholder data handled by the PSP; scope kept off your org	Depends on how the integration is built
Multiple PSPs	One layer can route across several processors and methods	Usually one integration per provider

FinDock is an example of the native-app route: it runs inside Salesforce and connects to multiple PSPs and payment methods from a single layer.

Salesforce donation apps to consider

Rather than ranking apps, it is more useful to match capabilities to how your organization actually collects donations. Compare options on:

➜

One-off and recurring support — can the app manage recurring donations and mandates natively, or only single gifts?

➜

Payment methods — cards, SEPA direct debit, ACH direct debit, iDEAL, Bancontact, PayPal, Apple Pay, and Google Pay each affect cost and donor conversion differently across Europe and North America.

➜

Salesforce-native vs. bolt-on — does the app run inside your org and write to your donation objects, or does it sit alongside and sync?

➜

Reconciliation — does it automate matching of payments to donation records, or leave that as manual work?

➜

Data model fit — Agentforce Nonprofit, NPSP or a custom model.

FinDock is a Salesforce-native payments platform that fits the native-app route: it connects multiple PSPs, supports one-off and recurring collection through NPSP and Agentforce Nonprofit (formerly Nonprofit Cloud), and reconciles payments back to your donation records inside Salesforce. Whether that fit is right depends on the criteria above and the payment methods your donors use.

How to set up donation processing in Salesforce

The exact steps vary by app, but the sequence is consistent:

Prepare your data model.

Confirm whether donations are recorded in NPSP, Agentforce Nonprofit (formerly Nonprofit Cloud), or a custom model, and that the required objects and permissions are in place.

Install and configure the source connector.

A source connector makes your donation data model (for example NPSP) the source of record, so processed payments sync to the right Opportunity, Recurring Donation, and Payment records. FinDock's source connectors for NPSP and Agentforce Nonprofit (formerly Nonprofit Cloud) handle this sync natively, including installment generation and matching back to the correct donation record.

Connect your payment processor(s).

Add the PSP accounts you want to use and enable the payment methods your donors prefer per market.

Build a donation form.

Create a hosted giving page or embed a form to capture the donation and payment details, including amounts, personal details, and payment methods.

Set up recurring donations.

Configure recurring schedules and mandates so installments are generated and collected automatically.

Configure reconciliation.

Set up matching rules so incoming PSP notifications and bank files are matched to the correct installments, with a review path for anything unmatched.

Test end to end.

Run a live one-off and a recurring donation through to a matched, reconciled record before going live.

Best practices for donation processing

➜

Scope PCI correctly. PCI DSS applies to card payments; direct debit and most other methods do not require it. Keep cardholder data with a PCI-compliant PSP so it never touches your org. PCI is a shared responsibility across Salesforce, your payments provider, and your own processes — consult a Qualified Security Assessor (QSA) for your specific setup.

➜

Reduce friction on the form. Ask for the minimum donor details, offer the payment methods your audience actually uses, and keep recurring options clear.

➜

Plan for failed payments. Card expiries and failed direct debits are normal. Have a retry and follow-up process so recurring revenue does not quietly leak.

➜

Support international donors. Local methods improve conversion — iDEAL and Bancontact, SEPA direct debit, ACH direct debit — so match your payment methods to Europe and North America as needed, and enable multi-currency where relevant.

➜

Automate reconciliation. Automated matching keeps donation records accurate and frees finance teams from manual checking, which is where most errors creep in.

Frequently asked questions

Does Salesforce process payments natively?

No. Salesforce records donations, but it does not collect money on its own. You add a payments app or a PSP integration to capture and process the payment, then sync the result back to your donation records.

Can Salesforce handle recurring donations?

Yes, with a payments layer. Salesforce provides the recurring donation object to track the schedule; a payments app collects each installment against a stored mandate and updates the record automatically.

What is the best donation app for Salesforce nonprofits?

There is no single best app — it depends on fit. Compare apps on recurring support, the payment methods your donors use, whether they run natively inside Salesforce, and how much reconciliation they automate.

Is Salesforce PCI compliant for donations?

PCI compliance applies specifically to card payments. In a well-designed setup, cardholder data is handled by a PCI-compliant PSP so it stays off your Salesforce org. Compliance is shared across Salesforce, your payments provider, and your organization's own processes.

How do you reconcile donations in Salesforce?

Reconciliation matches incoming payment data — PSP notifications and bank files — to the corresponding donation installments. A payments app with automated matching handles most of this and flags exceptions for review.

How does FinDock handle donation processing?

FinDock is a Salesforce-native payments platform. It connects to multiple PSPs and payment methods, uses source connectors for NPSP and Agentforce Nonprofit (formerly Nonprofit Cloud) to keep donation records in sync, and automates reconciliation through Guided Matching so incoming payments are matched to the correct installment without manual work.

Customer story

Here's an example of how The Ocean Cleanup does this natively on Salesforce — connecting donors across payment providers into one system with FinDock.

"We already really like that we can see everyone in Salesforce. Based on the roll-up values, we can see how much someone has donated over time, their average gift, first donation and latest donation. It's very nice that we have this one place and have the context."

Erika Träskvik — Head of Digital Marketing, The Ocean Cleanup

Read the full story ➜

See how FinDock processes one-off and recurring donations natively in Salesforce.

Talk to FinDock

The post How to process donations in Salesforce: apps, setup, and best practices appeared first on FinDock.

The Ocean Cleanup

Dominyka Bortnikaite — Mon, 07 Sep 2026 12:43:46 +0000

How The Ocean Cleanup is connecting global fundraising with Salesforce and FinDock

The Ocean Cleanup is on a mission most people recognize on sight: to rid the world's oceans of plastic and stop more plastic from getting in. Behind that mission is a team of around 200 people, working on cleanup solutions around the world.

A donor base scattered across payment service providers

The Ocean Cleanup had already used Salesforce for years, primarily for partnerships and donor support. Individual giving was a different story. Donor data largely lived where the payment happened, directly with payment service providers such as Buckaroo and PayPal, with no central view in Salesforce to understand the full donor relationship or use giving history for future campaigns.

The Ocean Cleanup wanted to bring individual donor data into Salesforce and started rebuilding its Salesforce environment and moved to Nonprofit Success Pack (NPSP), creating the base to bring individual fundraising and donor data into Salesforce as well.

Bringing payments into Salesforce with FinDock

With that foundation in place, The Ocean Cleanup selected FinDock to connect its website donation experience to Salesforce, followed by bringing historic donor data into the platform.

“We already really like that we can see everyone in Salesforce. Based on the roll-up values, we can see how much someone has donated over time, their average gift, first donation and latest donation. It's very nice that we have this one place and have the context.”

Erika Träskvik — Head of Digital Marketing, The Ocean Cleanup

One connected system, wherever a donation comes from

The Ocean Cleanup raises funds globally, and its three largest donor countries — the United States, Germany and the Netherlands — all bring different payment expectations. Through FinDock, The Ocean Cleanup connects Buckaroo, PayPal and Stripe to Salesforce, so donors always see the payment methods they're familiar with, without adding operational complexity in the backend.

Local payment methods

Euro payments processed primarily through Buckaroo, alongside PayPal and Stripe for selected card payments.

US dollar payments run primarily through Stripe, with cards and ACH.

One-time & recurring giving

One-time and recurring monthly donations, with FinDock managing recurring mandates and routing payments to the right provider.

New methods, fast

New methods, such as Stripe Link, added through FinDock without building a new integration from scratch.

“We wanted to turn Stripe Link on and see how people would respond, and already we see a lot of people using it. As new payment methods become relevant, we can add them through FinDock.”

Erika Träskvik — Head of Digital Marketing, The Ocean Cleanup

The donation page itself uses FinDock's API, supporting the different providers and payment methods The Ocean Cleanup's international donor base requires.

Automating what happens around the payment

Having payment data available natively in Salesforce also lets The Ocean Cleanup build processes around what happens when a donation doesn't go as planned.

Dunning with PayLink

A dunning flow automatically sends a PayLink when a recurring payment fails, giving the donor an easy way to complete it.

Timely follow-up

Donations that are started but not completed are automatically closed after an hour, triggering a follow-up email while the intention to donate is still recent.

Expiring cards, solved

Plans are underway to expand the use of PayLinks to let donors update expired payment methods, rather than just retrying the same failed payment.

“A first version of the Dunning flow is live and we are looking to take it a step further and start using PayLinks to update the payment method itself, because if an expired card caused the problem, simply retrying that one payment doesn't solve it for next time.”

Erika Träskvik — Head of Digital Marketing, The Ocean Cleanup

Giving supporter service the context it was missing

For the support team, having payment data in Salesforce means donor questions and changes can be handled from one system, with giving history right there for context.

“For our customer support team, it's much easier to manage supporter requests through one system rather than hopping around. And the same goes for reporting. We used to download reports from every payment service provider and build pivot tables in Excel. Now the reports are already set up in Salesforce. We refresh them, look at the dashboards and immediately have the overview we need.”

Erika Träskvik — Head of Digital Marketing, The Ocean Cleanup

Growing recurring giving

Recurring giving is growing at The Ocean Cleanup. An impact calculator on the donation page has helped shift more supporters towards monthly donations.

“We can see our recurring donor numbers increasing, and of course we want to keep those donors for longer. Having all that data in one place means we can see how that base is developing and start thinking about what we can do to build those relationships over time.” Erika Träskvik

From payment data to personalized donor journeys

The Ocean Cleanup is using donation history to shape journeys, from welcoming a first-time donor to recognizing long-term supporters and following up when someone stops giving.

As the team continues developing its Salesforce environment, Erika also values having FinDock there to help navigate the different moving parts.

“FinDock support is always super responsive. They're quick to help and to tell us whether something is related to FinDock or Salesforce. That's great.”

Erika Träskvik — Head of Digital Marketing, The Ocean Cleanup

For The Ocean Cleanup, bringing payments into Salesforce has created a foundation that goes well beyond processing donations, giving the team what it needs to understand supporters better, build stronger relationships and keep evolving the fundraising experience as the organization grows.

See what FinDock can do for your fundraising

Bring every donation, provider and donor record into one connected Salesforce platform.

Get in touch

The post The Ocean Cleanup appeared first on FinDock.

Building online giving experiences on Salesforce

Lee Moorcroft — Tue, 04 Aug 2026 08:33:33 +0000

A fundraising campaign works hard to get someone to give online. But a supporter fired up by a specific appeal clicks donate and lands on a generic form: no mention of the campaign, no sense of the goal, the same amounts as everything else. That drop in momentum is where some of them leave before they finish. A page built for the campaign keeps more of them going through to a completed gift. A year-end appeal, an emergency response, a major-donor ask: each one deserves its own donation page, with its own amounts, wording and look. Your general donation page is critical, but it can’t do justice to every campaign at once.

So the practical question is how to give each campaign its own donation page in a way that’s manageable for your team.

This use case covers building donation pages on Salesforce, using Experience Cloud, Salesforce Flow and FinDock’s payment components, starting from FinDock Labs’ donation templates. Your team builds and adjusts the page in Salesforce’s Experience Cloud drag-and-drop tools, and FinDock’s components handle the payment itself.

FinDock Payment Experiences for fundraising

FinDock Payment Experiences lets your team build the donation page itself, using Experience Cloud, already included in your Salesforce edition. Instead of a generic donation form, the donation page can be built for the specific campaign: the right message, the right goal, the right amounts. And because the page and your donor data sit on the same platform, a gift lands on the donor record the moment it’s made, with nothing to sync afterwards.

It brings together three things: Experience Cloud to build and brand the page, Salesforce Flow to build the form and its logic, and FinDock’s payment components to take the payment. FinDock Labs provides ready-made templates, so you start from a working donation page rather than a blank screen.

What you can do with FinDock’s donation templates

Collect a one-time or recurring gift, with amounts and frequencies your team sets.
Let a donor give in honour or memory of someone, using Gift Tributes.
Let a donor cover the transaction fee, so the full gift reaches the cause.
Reuse the same template for the next campaign, with its own amounts, frequencies and branding.

You set all of this up in Salesforce Flow and the Experience Cloud page builder. If you’ve ever built a page in a website builder like WordPress, or a drag-and-drop one like Squarespace, the builder will feel familiar. You lay out a page by adding or dragging components onto a web page, and it handles desktop and mobile layouts for you. Typography, brand colours and header images are set once from a single menu and apply across the whole site. And you control the page structure yourself: navigation, custom URLs, and how pages show up in search with metadata. The result is a donation page that looks like the rest of your organisation’s site, on your own brand, not a generic hosted page you can’t change.

Launch a new campaign page faster

The donation site and flow are templates from FinDock Labs, so a new page doesn’t mean you have to start from a scratch. You deploy the template into your Salesforce org and you have a working donation page and flow, already connected to FinDock’s payment components. From there, setting the amounts, frequencies and branding for a specific campaign can be a no-code job in Flow and the Experience Cloud builder.

Because you start from a working template, getting a page live for a new campaign is quicker, and the amounts, wording and branding are things your team can change themselves in the builder. You’d only bring in a developer for something more custom, like a custom-designed component, or logic beyond what Flow can handle on its own.

The gift lands straight in Salesforce

Webpages and sites built with Experience Cloud and FinDock run natively in Salesforce, so a gift is written directly to the same place your campaigns, funds and donor records already live. There’s no separate donation platform to sync from, and no second copy of the data to keep up to date.

Extending beyond the template

The templates are only the starting point. Adding elements like a progress bar toward a goal, changing the site layout, or adding a screen to the flow is done in the Experience Cloud builder and Flow. If you need something the standard components don’t cover, developers can build their own Lightning Web Components using FinDock’s payment components, or add custom CSS, so the custom part stays manageable rather than a rebuild of the payment logic. And if you want to go further still and build a fully custom payment journey from the ground up, FinDock’s Payment API is there underneath it all, the same engine the templates are built on.

Available templates

FinDock Labs is FinDock’s open-source GitHub repository. The templates are free and public, with nothing to subscribe to, and you deploy them straight into your own Salesforce org. They’re community starting points built on FinDock’s supported payment components, so you’re customising a working example rather than relying on it as-is. For donations, it has templates for both the site and the flow underneath it:

Donation site, which uses either the Donation flows for Fundraising or Donation flows for NPSP template, for one-time and recurring gifts.
An LWC template, for teams that want to build their own Lightning Web Components using FinDock’s payment components, without Flow.

All templates are accessible and WCAG-compliant, and support multiple currencies, languages and payment methods.

What this means for fundraising teams

Your team can build donation pages in Salesforce, deploy them quickly for each campaign, and handle the everyday changes themselves, the amounts, the wording, the look, keeping technical help for the genuinely custom work. Gifts land directly on the donor record, and the pages sit on the same platform as the rest of your fundraising data. so there’s one less system for your team to manage.

Next step

The donation templates are available on FinDock Labs, where each one includes a preview of what it looks like and how it works:

Donation site: github.com/FinDockLabs/experience-cloud-donation-site
Donation flows for Fundraising: github.com/FinDockLabs/experience-cloud-donation-flows-fundraising
Donation flows for NPSP: github.com/FinDockLabs/experience-cloud-donation-flows-npsp
Full template library: github.com/FinDockLabs/payment-experiences-templates

For a walkthrough, or to talk through what your fundraising organisation needs, contact your FinDock representative.

The post Building online giving experiences on Salesforce appeared first on FinDock.

Axepta BNP Paribas

Dominyka Bortnikaite — Thu, 30 Jul 2026 06:27:51 +0000

Connecting customer service with payment operations

Axepta BNP Paribas brought payment operations into Salesforce with FinDock, uniting sales, billing, customer service and payments on one platform and processing around 15,000 recurring payments every month.

Axepta BNP Paribas is a leading European payment service provider, helping businesses accept and manage payments through payment terminals, e-commerce and omnichannel payment solutions. Customer service is one of its key differentiators, but as the business grew, customer, billing and payment data became spread across disconnected systems.

Rather than introducing another specialist payment platform, Axepta BNP Paribas chose to continue building on Salesforce. Together with FinDock, the company brought payment operations into Salesforce, creating one connected platform for sales, billing, customer service and payments.

Today, Salesforce Revenue Cloud and FinDock support Axepta BNP Paribas' complete quote-to-cash journey, processing around 15,000 recurring payments every month while giving employees a complete view of every customer from one connected platform.

Customer-first service required more than connected systems

Before its transformation, Axepta BNP Paribas' customer journey was spread across three different systems.

Salesforce supported lead management, order management and customer service. Invoices were generated in EOS, while direct debit processing and payment reconciliation took place in SAP. Each application fulfilled its own purpose, but together they created operational complexity and a fragmented landscape.

When a customer called with a question about an invoice or payment, customer service employees often had to search across multiple systems before they could provide an answer. Information was fragmented, reporting was split across applications and different implementation partners maintained different parts of the landscape.

For an organization where customer service is a key differentiator, that wasn't the experience Axepta BNP Paribas wanted to deliver.

"Customer service is key for us. We wanted our employees to have a complete view of the customer whenever someone gets in touch. Bringing payment operations into Salesforce means they no longer have to switch between systems and can immediately see everything they need to help the customer." Frederik Libbrecht — Salesforce Lead at Axepta BNP Paribas

Bringing payment operations into Salesforce

Because Salesforce was already the strategic platform for customer-facing processes, Axepta BNP Paribas chose to continue building on that foundation. After their initial Salesforce implementation, they decided to extend their solution with Salesforce CPQ and Salesforce Billing. FinDock completes the solution by bringing payment operations directly into Salesforce, connecting billing, collections and reconciliation into one platform, providing a single view for customer service. Rather than treating payments as a back-office process, payment operations became part of every customer interaction.

FinDock brings this together across three areas: processing, recovery and reconciliation. Here's what that looks like combined with Salesforce for Axepta BNP Paribas' complete quote-to-cash journey.

Payment Processing

Every SEPA Direct Debit and Credit Transfer, matched automatically.

Payment Recovery

Refunds, reminders and debt collection stay part of the customer journey.

Payment Reconciliation

Billing and collections reconciled into one connected record.

Today, the complete quote-to-cash journey runs inside Salesforce with FinDock.

Behind this process sits a flexible payment operation that supports every payment scenario Axepta BNP Paribas offers. Businesses can either rent payment terminals through recurring contracts or purchase them outright. Rental agreements generate around 15,000 monthly collections through SEPA Direct Debit, while one-off purchases, replacement accessories and service fees are invoiced separately.

Customers can pay through either SEPA Direct Debit or SEPA Credit Transfer, with incoming transactions automatically matched to the correct customer, invoice and payment schedule inside Salesforce. Refunds are also processed through FinDock, while reminder and debt collection processes continue within Salesforce. This ensures every payment event becomes part of the complete customer journey and customer service always has an up-to-date view of every payment interaction.

Better payment operations create better customer experiences

Bringing payment operations into Salesforce transformed both the employee and customer experience. Customer service teams now have immediate access to contracts, invoices, payment status and customer history from a single customer record, while automatic reconciliation, Guided Matching and integrated business processes simplify payment operations behind the scenes.

The result is one platform where employees spend less time searching and managing exceptions, customers receive faster and better-informed support, and Axepta BNP Paribas delivers both efficient payment operations and seamless payment experiences. Resulting in an increased CSAT score of 3,95/5 in 2024 to 4,16/5 in 2025. A substantial improvement for a year-over-year change.

3.95 → 4.16

CSAT score, 2024 to 2025 (out of 5)

Building on a future-ready platform with Agentforce

With customer, billing and payment data working together in Salesforce, Axepta BNP Paribas continues to expand what their Salesforce platform can do.

One example is an Agentforce use case that supports customer service employees during contract cancellations. The agent identifies contract types, calculates notice periods and prepares the information employees need before guiding customers through the cancellation process.

By building on one connected Salesforce platform, Axepta BNP Paribas has created a foundation that supports continuous innovation without introducing new silos or disconnected applications.

A partnership that supports continuous improvement

Frederik highlights the collaboration throughout the implementation and the ongoing partnership with FinDock.

"Whenever we have a question or run into a problem, FinDock responds very quickly. They're always willing to jump on a call and work through it together. It really exceeds our expectations. What I also appreciate is that the partnership doesn't stop after implementation. Through product updates, webinars and early insights into new capabilities, FinDock continues to help us get more value from our Salesforce platform." Frederik Libbrecht — Salesforce Lead at Axepta BNP Paribas

By bringing payment operations into Salesforce, Axepta BNP Paribas has created a platform where all customer data lives. Employees can help customers faster, payment operations run more efficiently, and the business has a foundation that will continue to evolve with Salesforce and Agentforce. It's a combination that delivers better operational efficiency, better payment experiences and, ultimately, customer payment happiness.

Your customers deserve payments this smooth

See how FinDock brings payment processing, recovery and reconciliation into Salesforce.

Get started →

The post Axepta BNP Paribas appeared first on FinDock.

FinDock

Stripe Salesforce integration: 4 ways to connect them

What a Stripe–Salesforce integration needs to do

Stripe's app for Salesforce Platform

What it gives you

What it leaves to you

An integration platform (iPaaS)

What it gives you

What it leaves to you

A custom API and Apex integration

What it gives you

What it leaves to you

A native Salesforce payments app

What it gives you

What it leaves to you

The four options side by side

How to choose

Frequently asked questions

Does Stripe integrate with Salesforce?

What does the Stripe app for Salesforce cost to run?

Can I use Stripe and another payment provider in the same Salesforce org?

Can I use Stripe with Nonprofit Success Pack (NPSP)?

Do I need a developer to integrate Stripe with Salesforce?

Talk to FinDock about running Stripe payments in Salesforce

Salesforce Recurring Payments Guide: Native App vs. PSP managed

Salesforce Recurring Payments Guide: Native App vs. PSP

How recurring payments work in Salesforce

The agreement is recorded in Salesforce

The collection: one installment per due date

The outcome: recorded on each installment

Reconcile: match each payment to its installment

Who collects recurring payments in Salesforce

What happens over the life of a recurring payment

Sign-up: the payer authorizes future collections

Each due date: the installment is collected

A card payment fails

The bank rejects a direct debit

The payer changes bank details or card

The payer pays part, gets a refund, or owes a fee

A standing order changes without notice

The payout arrives and needs reconciling

Sector rules add steps

You add a PSP or switch providers

How the two setups handle these events

Where FinDock fits

Frequently asked questions

Are your payments working for you in Salesforce?

Payments are critical data points and they deserve attention

Mishandling payments can cost you

What payments working FOR you looks like

Where do you actually stand on payments?

Where FinDock fits

Dreamforce 2026: what AIforce actually means if you run payments in Salesforce

Three things worth your attention

What this does to payment operations

You're putting probabilistic systems on top of deterministic money

Connected data isn't grounded data

Inherited permissions

Your audit trail has a new job

Where the payment layer sits in all this

What I'd actually do next

September ’26 Release Highlights

At a glance

1. Build a payment experience to fit the moment

Why does this matter?

2. Bank-validated e-Mandates for Direct Debit in the Netherlands

Why does this matter?

3. More ways to give and more ways to pay

Vipps MobilePay Donations

Gift cards through Adyen

Why does this matter?

4. Guided Matching: simplifying the other side of the coin

Why does this matter?

And there’s more

How to connect every insurance payment to the reason behind it

The situation

What happens today

Why the gap is hard to close

What FinDock does

What changes with FinDock