Donation Platform Salesforce Integration: 5 Questions Before You Buy

VarGive is the multi-market fundraising platform built by Vardot, a Drupal Diamond Certified partner working with global nonprofits including UNHCR and UNICEF. VarGive is open source by design. The multi-market organizations we work with own their platform, their data, and their roadmap.

Global nonprofits rarely run one Salesforce instance. They typically run several. Some markets merged into a global setup, others managed their own, with field mappings and customizations that vary by region.

That's the integration reality most donation platform evaluations skip past, and it's where operational stability lives or breaks at scale. Here are the questions I'd ask before signing with any donation platform vendor.

How CRM Reconciliation Actually Works Across Markets

Most large nonprofits we work with don't have one Salesforce integration. They have several. Some markets get merged into a global Salesforce instance. Others manage their own. Field mappings vary across markets, and customization is required based on each market's specific needs.

The technical foundation is a constant ID that tracks each transaction from VarGive into the corresponding Salesforce instance. That ID is what lets us find a donation in Salesforce after it leaves our system, search for it there, and confirm the data landed correctly.

A big goal for our engineering team right now is consolidating these various Salesforce integrations and making the overall pattern more unified and stable without removing the per-market customization that local teams actually need.

Routing Data To The Right Salesforce Instance

We handle this through markets. Each market points to the relevant Salesforce instance and carries the field mappings that match what the local team expects.

We're currently onboarding Denmark, and the work is making sure the Danish Salesforce mappings meet what the Danish team needs, not forcing them into a global default. Federated nonprofits typically have a global team that works with regional markets, and those markets manage their own Salesforce. The market configuration in our platform reflects that operational reality. When we create a market in the platform, the configuration includes which Salesforce instance to push data to, alongside everything else that varies locally.

Two things worth flagging. First, our Salesforce setup supports adding new field mappings and adjusting how data syncs in stages, and turning specific ones off and on as needed. When the local Salesforce team makes changes on their side, we can adapt to those changes without slowing down the rest of the platform. You shouldn't have to choose between moving fast and keeping Salesforce in sync.

Second, admins can switch off Salesforce reporting for a specific campaign or market. This keeps the CRM clean, which matters more than it sounds. Test campaigns are the obvious case there's no reason to send payments from a stress-test campaign into Salesforce. The control sits with the admin, not buried in a developer ticket.

What Salesforce Needs From Your Donation Platform

Not everything we capture, but enough for the team to do their CRM work, donor communication, and analytics.

Specifically, we send Salesforce the payment gateway used (Stripe, and the local gateway configured for the market), transaction IDs, customer mapping details, payment method updates, refund status, and whether the donation is recurring or one-time. Enough for the team to send a personalized email to the donor, and enough to support the quarterly or annual analytics they're running on Salesforce data.

The discipline here is recognizing that the donation platform isn't the system of record for donor relationships. Salesforce is. Our job is to send Salesforce what it needs to do its job well.

Why Separating The CRM From The Donation Platform Matters

The donation platform should focus on what it does well: multi-market, multi-currency, multi-lingual fundraising, with strong integration to local payment gateways that are standard in specific countries. Salesforce should focus on what it does well, donor relationships and engagement, through a powerful API, with widely available talent who already know how to work with it.

Trying to build CRM functionality inside a donation platform means reinventing what Salesforce already does. Better to integrate cleanly with Salesforce and empower regional teams to use tools they're already familiar with. The strength of VarGive shows up for large multi-market organizations where central teams need to empower various markets to execute their specific Salesforce activities, not bypass them.

Compliance and Fraud: What to Ask Before Signing

Two things don't always come up in vendor pitches but matter the moment something goes wrong: compliance and fraud.

On compliance, VarGive is built to meet PCI DSS standards from the ground up, not bolted on afterward. Card data is tokenized by the payment provider, which keeps our servers out of scope for cardholder data across every gateway we integrate. We harden the front-end against common web attacks (using techniques like Content Security Policy and Subresource Integrity), enforce two-factor auth on admin accounts, and run email and phone validation through a third-party service to keep donor data clean at the point of entry. GDPR-relevant flows like donor record deletion are part of the standard donor lifecycle, not something each client has to build separately.

On fraud, large NGOs underestimate this until their first attack on Giving Tuesday or an emergency appeal. We layer it: Cloudflare Turnstile at the edge, honeypot fields and IP/email blacklisting on the form, and a rules-and-multiplier fraud engine with a suspicious-orders view and per-order fraud scores battle-tested on global nonprofit clients and being centralized as a shared capability every new tenant inherits. With more clients on the platform, the rules library and detection patterns get richer over time.

Donor trust is your operating system. Compliance and anti-fraud aren't features you ship; they're the ground on which a global fundraising programme is built, donor by donor, donation by donation.

If you're evaluating donation platforms for a multi-market programme, these are the questions worth asking of any vendor, including us.

Paul McCrodden works with Vardot as Senior Product Manager for the Donations product team, behind humanitarian giving platforms for UNHCR and UNRWA. He brings 8 years in product management and 10 years in software engineering, with experience delivering enterprise platforms for organisations including the University of Cambridge, Pantheon, and Mitsubishi Motors. He holds an MSc in Multimedia Systems from Trinity College Dublin.