A charity website can generate enquiries, event registrations and donations every day, but the real operational value comes when that information reaches the right supporter record and the right team without somebody manually copying it between systems.
A properly designed Salesforce integration can connect website forms and donation platforms with the CRM so that supporter information, donations, campaign data and relevant preferences flow into the organisation’s wider processes.
The payment platform may still process the financial transaction. The website may still provide the public experience. Salesforce can become the connected CRM where the charity manages the resulting supporter relationship.
At Sweet Potato Tec, our Salesforce for Charities & Non-Profits work includes online and recurring donations alongside donor and supporter management, fundraising automation and connected data.
The important part is designing the complete journey rather than simply connecting two systems.
How can a charity integrate its website and donation platform with Salesforce?
A charity can integrate its website and donation platform with Salesforce using direct APIs, specialist payment applications or middleware such as Boomi. Website enquiries and donations can then be matched with supporter records, recorded against the correct campaign and used for follow-up and reporting. A reliable integration should also address consent, Gift Aid where applicable, recurring payments, failed transactions, refunds, reconciliation, duplicate prevention and security.
What should happen when someone completes a charity website form?
The information should move through a defined process rather than simply arriving somewhere in Salesforce.
Imagine someone completes a website form to register their interest in supporting the charity.
A well-designed integration needs to answer several questions.
What information is being collected?
Does this person already exist in Salesforce?
Should an existing record be updated or a new one created?
Why did they complete the form?
Which campaign or webpage generated the enquiry?
What communication preferences did they provide?
Who needs to follow up?
Does the interaction trigger an automated process?
This is where integration design becomes more important than simply saying that the website “connects to Salesforce”.
Sweet Potato Tec’s Salesforce integration services include discovery, data mapping, API integration, middleware and data synchronisation because those questions need to be answered before information begins flowing automatically.
The objective should be clean data capture at source.
If a website form produces incomplete, inconsistent or duplicate information, automatically sending it into Salesforce only creates bad data more quickly.
How can online donations flow into Salesforce?
An online donation journey typically involves several components working together.
At a simplified level:
1. The supporter visits the charity’s website.
They select a donation amount and provide the information required by the donation journey.
2. The payment is processed.
A payment provider or specialist fundraising/payment platform handles the financial transaction according to the chosen architecture.
3. Relevant supporter and transaction information is passed into Salesforce.
The integration determines whether the supporter already exists and creates or updates the appropriate CRM information.
4. The gift is recorded.
Salesforce Nonprofit Cloud Fundraising can represent gifts through gift transactions and commitments, including one-time and recurring giving structures.
5. Relevant campaign information is associated with the donation.
This allows the charity to understand where income came from.
6. Follow-up processes can begin.
The charity may need to acknowledge the donation, update internal workflows or include the supporter appropriately in future communications.
7. The information becomes available for reporting and supporter care.
Fundraising teams can see the gift as part of the wider relationship rather than relying on a separate payment export.
Salesforce’s current Nonprofit Cloud documentation confirms that online donation/payment integrations can send payment information into Fundraising as gift transactions.
The practical implementation depends on the charity’s website, payment provider and Salesforce architecture.
How can charities manage recurring donations in Salesforce?
Recurring giving needs to be designed as an ongoing payment relationship rather than treated as a series of unrelated one-off donations.
Salesforce Nonprofit Cloud Fundraising supports gift commitments and related gift transactions.
This distinction matters.
A commitment can represent the ongoing intention to give, while individual transactions represent payments associated with that commitment.
For example, a monthly donor should not appear to the fundraising team as twelve unrelated people or twelve unrelated supporter relationships.
The CRM should make it possible to understand the recurring arrangement and the payments associated with it.
The payment platform also needs to remain part of the design.
Depending on the chosen solution, it may be responsible for collecting future payments and communicating payment status back to Salesforce.
That means the integration needs to consider more than the successful first payment.
What happens next month?
What happens if the payment fails?
What happens if the supporter changes their payment details?
What happens if they cancel?
What happens if the amount changes?
A recurring-donation integration should be designed around the whole lifecycle.
Where does FinDock fit into a Salesforce donation integration?
FinDock is a Salesforce-native payment management solution that can be used to connect payment journeys and Salesforce.
For charities, one relevant use case is accepting payment information through an online donation journey while maintaining the resulting fundraising information within Salesforce.
FinDock provides APIs that can be used with web forms and supports payment-related processes inside the Salesforce environment.
For UK organisations, FinDock also provides specific Gift Aid functionality.
Its current documentation confirms that when its Payment API is used to collect donations through a web form, Gift Aid actions can be incorporated into the form integration. Its Giving Pages can also provide an option for donors to make a Gift Aid declaration.
That can make FinDock relevant to charities trying to connect the donation, payment and Salesforce journey more closely.
However, the product should not be introduced simply because it exists.
The charity first needs to understand its requirements.
Which payment methods are needed?
How are recurring donations handled?
What Gift Aid process is required?
Which system needs to own payment information?
What reconciliation process does finance need?
What is already working in the current donation platform?
Only then should the organisation determine whether FinDock, another payment solution or a different integration architecture is appropriate.
How can Gift Aid be connected with the donation journey?
Gift Aid information can be incorporated into the digital donation journey where the chosen platform and process support it, but the charity remains responsible for making sure its Gift Aid process meets the relevant requirements.
From a systems perspective, the objective is to avoid treating the declaration as an unrelated piece of information.
If an eligible supporter makes a donation and provides the appropriate declaration, the charity needs a reliable way to associate the relevant information with that supporter and giving activity.
FinDock’s current documentation provides one example of how this can work technically.
Its Payment API supports Gift Aid actions when donations are collected through web forms, and FinDock Giving Pages can include an option for donors to make a Gift Aid declaration.
But the technology does not decide whether a donation qualifies for Gift Aid.
Nor should a charity assume that adding a checkbox to a form automatically creates a compliant Gift Aid process.
The wording of declarations, supporter information, record keeping, eligibility and claims should follow current HMRC requirements.
The integration should then support that agreed process.
How should donations be matched with existing supporters?
The integration should attempt to identify whether the donor already exists before automatically creating another supporter record.
This is one of the most important parts of the design.
Without appropriate matching, the same person might donate several times and create several Salesforce records.
They may also already exist because they volunteered, attended an event or contacted the charity previously.
Matching therefore needs carefully defined rules.
Email address may be useful, but relying on one identifier in every situation can create problems.
People change email addresses.
Two people can sometimes share contact information.
Names can be entered differently.
The integration needs to define what constitutes a confident match and what happens when the answer is uncertain.
In Salesforce Fundraising, administrators can also configure gift entry so donors can be found using defined external identifiers, which can help distinguish people who share a name.
For website integrations, the same underlying principle applies:
do not create a new record until you have considered whether the person is already known.
Sweet Potato Tec’s nonprofit work focuses on creating clear visibility across supporter journeys rather than treating each interaction as an isolated record.
Good identity matching is fundamental to making that possible.
How can campaign attribution be preserved?
Campaign information should be captured as part of the donation journey so the charity can understand which fundraising activity generated the gift.
That may involve a campaign identifier, source information or other agreed attribution data being passed from the website or donation platform into Salesforce.
Salesforce Fundraising supports relationships between gift transactions and campaigns.
This allows fundraising information to be analysed in context rather than simply as a total amount received.
For example, a charity may want to understand whether a donation came through:
a particular appeal,
an event,
a specific digital campaign,
a fundraising page,
or another initiative.
The exact attribution model should be agreed before the integration is built.
Otherwise, teams can end up with technically complete donation records that provide very little insight into what generated them.
Campaign naming and attribution also need governance.
If website teams, fundraising teams and Salesforce users all use different campaign structures, reporting will become unreliable regardless of how well the API works.
How should consent and communication preferences move into Salesforce?
Consent and communication-preference information should follow clearly defined rules so that the charity does not end up with conflicting instructions in different systems.
Suppose a supporter makes a donation and updates their communication preferences during the journey.
Which system becomes authoritative for that preference?
Does Salesforce update immediately?
Does a marketing platform also need to be updated?
What happens if that platform already contains different information?
What if the supporter later changes their preference somewhere else?
Those questions need to be answered before automating the flow.
For UK charities, the organisation also needs to ensure its approach to personal data and electronic communications reflects its applicable data-protection and privacy obligations.
The integration should implement the organisation’s agreed rules.
It should not invent them.
This is another reason discovery and data mapping matter.
A technically successful integration that synchronises the wrong information in the wrong direction is still a bad integration.
What happens when a donation fails or is refunded?
Failed payments and refunds need to flow back into the CRM appropriately so fundraising and finance teams are not working from an inaccurate picture.
Salesforce Nonprofit Cloud Fundraising provides transaction statuses that include states such as unpaid, pending, paid, failed and fully refunded.
It also provides refund records associated with gift transactions.
This gives the Salesforce side of the architecture a way to represent what has happened.
The payment integration then needs to make sure those changes are reflected correctly.
For a failed recurring payment, for example, the charity may need to know:
which payment failed,
which commitment it relates to,
whether another attempt will be made,
whether the supporter needs appropriate follow-up,
and whether the expected income shown in reporting needs updating.
A refund creates similar questions.
The CRM should not continue reporting the original donation as though nothing changed.
The exact automation depends on the payment platform and finance processes.
The principle is straightforward: successful payments are only one part of the donation lifecycle.
Design for exceptions as well.
How should charities approach payment reconciliation?
Reconciliation should be designed with finance requirements in mind from the beginning.
The fundraising team may primarily think about the donor and gift.
Finance may need to understand settlement, fees, refunds and whether the amounts received correspond with what the CRM reports.
Those are related but not identical requirements.
Before implementing a payment integration, ask:
What transaction reference needs to be retained?
How are processor fees handled?
How are refunds represented?
How are failed transactions handled?
What information does finance need to reconcile payments?
Does information need to move into an accounting or finance platform?
How are discrepancies investigated?
Salesforce’s fundraising data model includes transaction information, while the payment platform will have its own transaction and settlement records.
The architecture needs to determine how those datasets relate.
Do not leave reconciliation until the end of the project.
An integration that makes fundraising easier but creates manual work for finance has only moved the problem elsewhere.
When should a charity use APIs or middleware such as Boomi?
Direct APIs can work well where the integration is relatively focused, while middleware can become useful where several systems, transformations or more complex data flows need to be coordinated.
There is no rule that every charity needs middleware.
Sweet Potato Tec’s Salesforce integration services include direct REST and SOAP API integrations as well as middleware using platforms including Boomi.
The choice depends on the architecture.
For example, a relatively simple website-to-Salesforce integration may be handled directly.
A more complex environment might involve:
the website,
Salesforce,
a payment platform,
a finance system,
an email platform,
and other operational applications.
Middleware can provide a structured integration layer between systems where that complexity justifies it.
At Sweet Potato Tec, we specialise in Salesforce and Boomi, but the principle is to use the simplest architecture that reliably solves the problem.
Introducing middleware where it adds no value simply creates another technology to maintain.
How can integration reduce manual data entry?
Integration can remove the need for staff to repeatedly copy information from website forms, payment exports or other platforms into Salesforce.
Sweet Potato Tec’s work with the Charity Retail Association demonstrates the principle clearly.
Before the project, the organisation’s website and Salesforce operated in silos.
Updates were delayed.
Event details were posted manually.
Reporting relied on spreadsheets.
Sweet Potato Tec connected Salesforce with the website for real-time data synchronisation and integrated Salesforce with Eventbrite so that event creation and registration information could sync automatically.
The result was shared, up-to-date data across teams, with fewer manual tasks and errors.
That project was focused on membership, website and event processes rather than online donation payments.
It should not be presented as a donation-platform case study.
It does, however, provide direct nonprofit evidence of the value of connecting public-facing digital journeys with Salesforce rather than relying on people to keep several systems aligned manually.
How can charities prevent bad data and duplicate records entering Salesforce?
Validation and duplicate prevention should be designed into the integration before it goes live.
Automation increases the speed at which information moves.
That is useful when the information is correct.
It is much less useful when an integration creates hundreds of incomplete or duplicate records automatically.
A robust process should consider:
required fields,
data formats,
supporter matching,
external identifiers,
duplicate rules,
invalid values,
failed integrations,
and how exceptions are reviewed.
The website should also collect only the information genuinely required for the relevant journey.
More fields do not automatically mean better supporter data.
Sweet Potato Tec’s Salesforce implementation approach includes data quality and governance because integration and data quality cannot sensibly be separated.
The aim should be:
capture clean information at source, match it intelligently and prevent known problems before they reach the CRM.
What security and compliance issues should charities consider?
Security should be designed across the entire journey, not just inside Salesforce.
A donation can pass through a website, payment provider, APIs and Salesforce.
Each component has its own responsibilities and risks.
The organisation needs to consider:
what personal data is collected,
which system stores it,
how it moves between systems,
who can access it,
how authentication is handled,
what payment information should or should not enter Salesforce,
how consent and preferences are managed,
and how long relevant information should be retained.
Payment-card processing also introduces specific security requirements, which is one reason charities should use appropriate payment providers rather than designing unnecessary handling of sensitive card data themselves.
Sweet Potato Tec’s integration approach includes security protocols as part of integration planning and delivery.
For charities, the technology design also needs to reflect applicable UK data-protection requirements and the organisation’s own information-governance policies.
Security should be a design requirement from the first workshop.
It should not be a final checklist before launch.
What should a charity map before building the integration?
Map the complete supporter and donation journey from beginning to end.
A practical discovery exercise should answer:
1. What happens on the website?
Document enquiry forms, donation pages and other supporter journeys.
2. Which platform processes the payment?
Understand one-off and recurring payment arrangements.
3. What information needs to reach Salesforce?
Separate useful CRM information from unnecessary data.
4. How are existing supporters identified?
Define matching and duplicate-management rules.
5. How are donations represented?
Map one-off gifts, recurring commitments, campaigns and relevant designations.
6. How is Gift Aid handled?
Document the declaration and record-keeping process where applicable.
7. How are communication preferences handled?
Decide where preferences are captured, owned and updated.
8. What happens when something goes wrong?
Include failed payments, refunds, invalid data and integration failures.
9. What does finance need?
Include reconciliation and any finance-system requirements.
10. What reporting is required?
Make sure campaign attribution and transaction information support the questions fundraising and leadership need to answer.
At Sweet Potato Tec, our Salesforce implementation and integration work begins with these processes before technology is configured.
That is how the integration becomes part of the charity’s operating model rather than simply a connection between two pieces of software.
FAQs
Can a charity website send donations directly into Salesforce?
Yes. A website and payment solution can be integrated so that relevant supporter and donation information is passed into Salesforce. The payment itself will normally be handled through an appropriate payment provider or payment platform, while Salesforce maintains the fundraising and supporter information required by the charity.
Can Salesforce manage recurring donations?
Salesforce Nonprofit Cloud Fundraising supports gift commitments and related gift transactions, allowing recurring giving to be represented as an ongoing commitment with associated payments. The payment platform and integration also need to support the recurring payment lifecycle.
Can FinDock handle Gift Aid?
FinDock’s current documentation includes Gift Aid functionality for UK charities. Gift Aid actions can be incorporated into donations collected through its Payment API, and its Giving Pages can include a Gift Aid declaration option. The charity remains responsible for ensuring its Gift Aid process follows current HMRC requirements.
Can Salesforce automatically match an online donor with an existing supporter?
An integration can apply defined matching rules to determine whether the donor appears to correspond with an existing supporter. However, matching needs careful design because no single identifier is reliable in every circumstance. Ambiguous cases may require review rather than an automatic match.
Do charities need Boomi to connect their website with Salesforce?
Not necessarily. Direct APIs may be sufficient for some integrations. Middleware such as Boomi becomes more relevant where several systems or complex data flows need to be coordinated. The architecture should be proportionate to the organisation’s requirements.
What happens if the connection between the website and Salesforce fails?
A well-designed integration should include error handling and monitoring so failed transactions or data transfers can be identified and investigated. The precise process depends on the integration architecture. Failures should not simply disappear without a trace or require staff to discover them accidentally.
Connect the whole donation journey, not just the form
A website-to-Salesforce integration should do more than move someone’s name and email address from one system to another.
For charities, the full journey can include supporter identification, a donation or recurring commitment, campaign attribution, Gift Aid information, communication preferences, payment status, reconciliation, acknowledgement and ongoing supporter care.
Those elements need to work together.
At Sweet Potato Tec, our Salesforce for Charities & Non-Profits work combines donor and supporter management with online and recurring donations, fundraising automation and connected data.
Our Salesforce integration specialists work with APIs, data synchronisation and middleware including Boomi to connect Salesforce with the systems organisations depend on.
The Charity Retail Association provides a practical example of why that matters. By connecting its website and Eventbrite with Salesforce, Sweet Potato Tec helped replace disconnected information and manual processes with shared, up-to-date data.
For donation integrations, the same principle applies.
Start with the journey.
Understand what happens when someone submits a form, makes a donation, gives regularly, changes their preferences, has a payment fail or receives a refund.
Then design the technology so Salesforce, the website, the payment platform and the people using them all have the information they need.
That is what turns an integration into a connected fundraising process.