Stop being the only one who knows what feeds what.

What goes wrong today

Point-to-point integrations that only one person understands

Each connection was built to solve one problem at the time: the website to the processor, the processor’s export to a spreadsheet, the spreadsheet to the mail tool. Every new tool adds another pipe, and the person who built the last one is usually the only one who can explain it.

No authoritative answer to “what feeds what”

Ask which systems currently send data where, and the honest answer is often a guess, reconstructed from memory or from opening each tool’s settings in turn. There is no single place that states the current integration surface.

Failures discovered downstream, not at the source

A webhook stops on a Sunday and nobody notices until Tuesday, when someone asks why this month’s numbers look thin. The loss is found in the report it caused, not in the connection that caused it.

Every new tool is another pipe to maintain

Adding a CRM, a second payment processor or a new mail tool used to mean building and maintaining a fresh connection to every other system it needs to talk to, with no shared model underneath any of them.

What connects, and on whose authorization

Each source below is read only after your organization configures and authorizes it.

Stripe

Card charges, refunds, disputes, and recurring events ingest with their provider reference intact, so a support ticket about one payment starts from the same identifier the processor dashboard shows.

Bank transfers & offline gifts Limited

No bank feed exists to connect. Transfers are entered by your team or brought in through import, then reconciled in the same ledger as processor activity. Worth saying plainly, so nobody expects an automatic feed that was never built. Recorded by your team or brought in by import today. Direct bank connections are on the roadmap.

WordPress & WooCommerce

Where you run WordPress or WooCommerce, that site keeps operating unchanged. The connection carries donation activity across. It does not touch the frontend.

CSV & spreadsheet imports

The usual retirement path for a legacy CRM export or a folder of spreadsheets. Decide once how historical fields map onto the current schema, and every later import follows the same shape.

Mailchimp

Audience membership and campaign activity sync so a bounce or unsubscribe is visible next to the giving record it affects, instead of living only inside the mail tool.

Existing CRM records Limited

Contact and giving history come across through supported imports and provider integrations. This is not a live two-way sync with an arbitrary CRM, so plan it as a defined cutover rather than an ongoing mirror. Through imports and supported providers. There is no live two-way sync with an arbitrary CRM.

Meta (Facebook & Instagram) Limited

Ingestion is one-directional: social-driven supporter and campaign signals arrive, but Donativus does not publish back to the page. Anyone expecting scheduled posting from inside the platform should know that is planned, not shipped. We read Meta activity and attribute it. Posting from Donativus is on the roadmap.

Power BI Limited

An optional, separately licensed destination for teams that already report through Power BI. It sits alongside the built-in analytics rather than replacing the data model underneath them. Optional, on top of the reporting that is already built in. Licensed separately.

The operating loop for this work

1. Authorize

   Your team connects each source with the credentials you already hold for it. Nothing is read before that.

2. Ingest

   Provider events arrive as they occur: a charge, a form submission, a list update. Each one enters the same pipeline, regardless of source.

3. Normalize

   Each event becomes a transaction carrying its provider reference, status, supporter link, and campaign attribution, so sources become comparable and analyzable.

4. Monitor

   The integrations screen shows what is connected and when it last synced, so a stalled source is visible on its own rather than through a downstream number.

5. Extend

   Adding a source means one more authorized connection into the same model, not a new pipe to every system already in place.

What can connect, and which way the data moves

You already have a working set of systems: a payment processor, a website with a donate button, an email tool, a spreadsheet of extra gifts, sometimes a CRM inherited from a previous director. Donativus ingests from that existing stack rather than replacing pieces of it. Payment processors, Stripe, Redsys, PayPal, Square, Global Payments and EuPlatesc, bring in charges, refunds, disputes and recurring events. Website and forms sources cover WordPress and WooCommerce sites and hosted Donativus forms, both carrying campaign and source attribution through to the gift. CSV and spreadsheet imports bring in historical giving and legacy CRM exports. Mailchimp and Donativus’s own email templates cover mailing. Meta covers social. Built-in analytics, and optionally Power BI, cover reporting.

Every one of these is a source, not a destination. Data moves in, from the processor, from the site, from the mail tool, into Donativus’s own record, where it becomes the foundation for analytics and AI recommendations. It does not move information back out to post on your behalf, change a WordPress page, or write to an external CRM. Where a connection ingests only, such as Meta or an imported CRM, that limit is stated plainly, not implied, because a data lead planning an integration surface needs to know before it becomes an incident on a Sunday.

Authorization is the boundary, not a convenience

Nothing reaches Donativus until your team configures and authorizes the connection, with credentials you hold for that provider. There is no default visibility into a system you have not connected, and no background collection while you are still deciding. That is deliberate. The two facts that matter for an integration surface are which direction the data moves and who authorized it, and both should be answerable without opening a support ticket.

A few sources are qualified rather than unlimited. State it precisely, because a data lead is the person who otherwise has to explain the gap later. Bank transfers and other offline gifts have no live bank feed. They are entered by your team or brought in through import, then reconciled alongside processor activity. CRM integration means supported imports and provider integrations, not a live two-way sync with an arbitrary CRM. Meta covers ingestion and campaign attribution only. Publishing posts from inside Donativus is planned, not available today.

One transaction shape out, regardless of what went in

The providers above do not agree on anything by default. A Stripe charge, a Redsys gateway operation, a PayPal payment and a bank transfer entered by hand are different objects with different fields and different failure states. Normalization turns all of them into the same transaction shape on the way in: the same amount, status, provider reference, supporter link and campaign attribution, whichever source produced it.

That shape is what makes a Stripe refund and a Redsys chargeback comparable in the same report, and what lets a support conversation start from a provider reference instead of a screenshot. It is also what makes the analytics and AI recommendations elsewhere on the platform reliable: they read one shape, not seven.

Maintaining the surface without maintaining ten separate pipes

Point-to-point integrations are the usual failure mode: the website talks to the payment processor, the payment processor’s export feeds a spreadsheet, the spreadsheet feeds the mail tool, and every new tool means another pipe that only the person who built it fully understands. When that person leaves, the pipe becomes a mystery the rest of the organization discovers by accident.

Donativus replaces that mesh with one ingestion layer. Every source connects to the same normalized model rather than to each other, so adding a new provider means one more authorized connection, not a new integration with every existing one. The integrations screen lists what is currently connected, payments, website, mailing, alongside its last successful sync, so a stalled source is something your team notices on the screen built for noticing it, not something inferred three weeks later from a dip in a fundraising report.

What changes

One list, not a guess

The integrations screen states what is currently connected and when it last synced, so “what feeds what” has an answer.

Failures surface at the source

A stalled connection shows up where it happened, before it shows up as a gap in a fundraising report.

One shape, many providers

Six payment processors, a website, imports, mail, CRM and social all resolve to the same transaction record.

New tools, not new pipes

Every additional source connects to the same ingestion layer instead of to every system already in place.

How it fits with what you run

• Donativus is not a payment processor. Your connected providers still capture and settle every payment and charge their own fees, separate from the Donativus platform price.
• Every source ingests only after your team configures and authorizes it, with credentials you hold. There is no passive collection and no default access to a system you have not connected.
• CRM integration means supported imports and provider integrations, not a live two-way sync with an arbitrary CRM. Meta connections are ingestion and attribution only. Publishing posts from Donativus is planned, not available.
• Built-in analytics cover operational and fundraising reporting on their own. Power BI is an optional, separately licensed addition for teams that already work in it.