Charitable - WordPress Plugin

How to Set Up Charitable for Donation Campaigns in WordPress

Charitable is best viewed not as a standard payment form, but as a dedicated donation campaign management layer inside WordPress. In this guide, we will walk through how to prepare your site, create your first campaign, configure the donation form, connect payment methods, review donor records, and catch the issues that can block real contributions.

This article is intended for nonprofit site owners, webmasters, editors, or agencies that need to launch fundraising quickly while leaving the team with a clear system they can manage day to day. This is not a repeat of the product's marketing copy. Instead, we will focus on the practical chain of campaign - form - payment - donation record - email - verification.

Charitable includes a free version and premium functionality. Because of that, this guide separately notes features that depend on your plan, active add-ons, and connected payment gateway. If a specific feature does not appear in your admin area, check your plan, add-on, and the developer documentation first before assuming there is a problem with your theme or WordPress.

Where Charitable Is Actually Useful

Charitable makes sense when your site needs more than a simple "donate" button and instead requires a managed fundraising system. A standard payment form can accept money, but after that you often still need to manually gather donor details, reconcile payments, send confirmations, track campaign goals in a spreadsheet, and explain to the team where to see current progress. Charitable handles that operational layer inside WordPress: each campaign has its own goal, form, donation settings, records, emails, and display options across the site.

The core object in the plugin is the campaign. That is where you define a specific fundraiser: support for an animal shelter, a medical fund, an education program, a club event, an emergency appeal, or a long-term initiative. A campaign can live as a standalone page, a homepage block, part of a landing page, or an item in a multi-campaign grid. The key point is that the fundraiser does not disappear into a generic payment form. It keeps its own story, amount, progress, donors, and verification path.

In practice, Charitable is especially useful in three situations. First, when an organization runs several fundraising efforts at the same time and each one needs its own goal, description, and reporting. Second, when you want to reduce donor friction by showing clear amounts, a short form, a familiar payment method, and confirmation after the donation. Third, when the team wants to manage donations without relying on an external platform, so records, pages, and SEO landing pages for campaigns stay on the organization's own WordPress site.

Why This Is Not the Same as a Standard Payment Form

A standard payment form answers the question "how do we accept money?" Charitable answers a broader one: how do we launch a fundraiser, explain the purpose, accept a contribution, connect it to a campaign, send an email, and then show the outcome in reports. That is why setup is about more than payment fields alone. You need to think through campaign structure, amount formats, receipt text, offline donation behavior, staff roles, and post-launch verification from the start.

If all you need is a one-time payment with no campaign history, progress tracking, or donor records, Charitable may be more than you need. But if your site supports ongoing fundraising, reports back to supporters, accepts offline contributions, runs repeat campaigns, or needs to show progress, a dedicated donation plugin is usually more practical than a collection of unrelated forms.

Which Use Cases to Plan in Advance

Before installing anything, it helps to write down not a list of desired features, but your actual workflows. For example: a donor opens a campaign page, picks a suggested amount, enters a name and email address, pays by card, receives an email, and the administrator sees the record in Charitable > Donations. Another workflow: someone pledges a bank transfer, chooses the offline method, receives instructions, and the bookkeeper later changes the donation status once the funds arrive. A third workflow: an editor features a single campaign on the homepage with a block or shortcode, while the page listing all fundraisers uses a campaign grid.

Thinking in workflows helps you avoid turning on everything at once. Recurring donations, donor dashboards, PDF receipts, abandoned donation recovery, donor portals, peer-to-peer fundraising, and marketing integrations are not necessary for every site on day one. Start with a reliable core path, then add extensions once the team clearly understands which process each one improves.

Who the Plugin Fits Best and When Another Approach May Be Better

Charitable is a strong fit for small and mid-sized nonprofits, foundations, clubs, schools, communities, grassroots groups, and individual fundraisers that need donation collection on WordPress. It is especially useful when the site already runs on WordPress, content is published by editors, and the team wants to manage campaigns in a familiar admin panel instead of sending every visitor to a separate external platform.

The plugin is also useful for agencies building nonprofit websites. For the client, a single interface is easier to manage: campaigns in one menu, forms inside each campaign, donations in reports, and emails in settings. If the handoff is done cleanly, the client team can update goal amounts, text, images, and offline payment instructions without going back to a developer.

There are also cases where you should be more cautious. If the organization already runs inside a large CRM and the WordPress site only serves as a public-facing presence, an external platform with built-in CRM integration may be more practical. If fundraising is legally complex and tied to local tax rules, membership dues, grants, or formal accounting processes, discuss the setup with a finance specialist first. Charitable helps collect and organize data, but it does not replace legal, accounting, or tax review.

Strong Points for Small Teams

For smaller teams, the value of Charitable is that it brings several essential pieces together in one place. An editor creates a campaign in the visual builder, an administrator enables the payment gateway, a finance or operations person reviews records, and a communications lead checks emails and thank-you messaging. That reduces the number of manual spreadsheets and makes fundraising easier to manage for people who do not work in WordPress every day.

Offline donations are also worth calling out. Not every supporter wants to pay by card. Some send a bank transfer, bring cash to an event, or mail a check. Charitable lets you track those contributions alongside online donations so campaign progress and reporting stay aligned with reality. For local nonprofits and community groups, that often matters more than exotic payment integrations.

When Charitable May Be Too Much

The plugin may be unnecessary if all you need is a simple inquiry form with no payment, a petition, a contact form, or a one-off PayPal flow with no donor database. In those situations, a general form builder is sometimes easier. Charitable is also not a WooCommerce extension. Official documentation describes it as a standalone donation system, not a WooCommerce cart module. If donations need to live inside the cart, order statuses, and product flow of an online store, it is better to compare a WooCommerce-based setup against a separate campaign system before you commit.

Practical takeaway: choose Charitable when a donation needs to be tied to a campaign, a donor, reporting, and follow-up emails. If you only need a single payment block with no campaign management, start with a simpler setup and come back to Charitable when there is a real need for campaign-based fundraising.

What to Check Before Installing on a Live Site

Before installing a donation plugin, it is important to check more than WordPress compatibility. You need to review the full path of money and data. Unlike a standard design block, a donation form touches payments, emails, personal data, caching, security, and donor trust. A failure at any point can lead to lost contributions or to the team missing important records when they matter most.

Technical Readiness

Start with the basics. The site should run over HTTPS, the admin area should be accessible to a user with administrator rights, and WordPress plus all active plugins should be up to date. With Charitable, running an outdated version is especially risky. Plugins that handle payments and personal data need security and payment logic fixes far more urgently than decorative extensions do.

If the site uses aggressive caching, JavaScript optimization, a CDN, or server-level cache from the host, identify in advance where exclusions are configured. Pages with live donation forms should not serve stale security tokens or break submission validation. Charitable documentation specifically links form validation problems to caching and third-party conflicts, so cache preparation is not a minor detail.

Minimum Checklist

• Create a full site and database backup before installing a new payment-related plugin.
• Confirm that the live site is served over HTTPS and that the certificate does not trigger browser warnings.
• Update WordPress, the theme, and active plugins, especially if the site has not been maintained for a while.
• Find where cache exclusions are configured for donation pages.
• Prepare a staging page or a site copy if fundraising is already mission-critical for the organization.
• Decide who will be allowed to view donations, export data, and change offline contribution statuses.

Payment and Operational Preparation

Before publishing the form, decide which payment methods your donors actually need. Charitable supports core options such as Stripe, Square, PayPal, and offline donations, while additional gateways and add-ons depend on your version. Do not enable every available method just because it appears in the interface. The more options you add, the more you need to test, review, email, track, refund, and explain to donors.

For an initial launch, it is usually best to choose one main online method and one fallback offline option. For example, card payments through Stripe or Square for quick donations, and bank transfer for people who do not want to pay online. Then test both paths: the online donation should appear in the records, the offline contribution should receive a clear status, and the emails should go out correctly.

Data, Privacy, and Email

A donation form collects personal information, so decide in advance which fields you truly need. The more fields you add, the more friction donors face and the more responsibility your team takes on for storing that data. Name, email, amount, campaign, and payment status are usually enough for the core workflow. Add address, phone number, company, comments, communication consent, or extra fields only when the team clearly understands why they are needed and how the information will be used.

Test WordPress email delivery before launching the campaign. If the donor confirmation or administrator alert never arrives, the donor may assume the payment failed, and the team may miss a new contribution. On sites where forms matter, it is wise to use an SMTP plugin or another reliable delivery method because default hosting mail often depends on server configuration and may land in spam.

Installation and First Launch with Minimal Risk

Installing Charitable in WordPress is technically straightforward, but the first launch should be treated like a small acceptance test. The goal is not just to activate the plugin. You want to confirm that the menu appears, a campaign can be created, the form displays on a page, a test donation makes it all the way into the records, and emails go to the expected recipients.

Installing Through the WordPress Admin Panel

If you are using the free version, the standard path starts under Plugins > Add New. Search for Charitable, install the plugin, and click Activate. After activation, a Charitable section will appear in the left admin menu. If you are using a paid version, the flow may include uploading a ZIP file and activating add-ons, but this guide does not cover purchasing, license keys, or checkout. The focus here is on configuring a product you already have access to.

After activation, open the Charitable section and confirm that campaigns, donations, settings, reports, and documentation prompts are available. If the interface does not appear, check user permissions, admin-area caching, conflicts with menu management plugins, and any PHP errors in the hosting logs.

Initial Setup in Charitable

Start with general settings and payment gateways. In Charitable > Settings, review currency, amount formatting, pages, emails, donor settings, and payments. Do not change everything that looks interesting right away. For the first test, it is enough to set the base currency, enable one test gateway or offline donations, prepare the donor email, and create one short campaign.

If your version includes a setup wizard, use it as a guide, but do not rely on it as the only validation step. A wizard helps you avoid missing the main setup tasks, but the real test needs to happen on the front end: open the campaign page in a separate window, fill out the form like a regular donor, and verify that the outcome matches what you expected.

How to Tell the Installation Worked Properly

After installation, you should have more than just an active plugin. You should have a minimum viable fundraising flow. A campaign can be created without errors, the form opens on the page, the selected payment method appears inside the form, submission does not return a validation error, a record appears in Charitable > Donations, and emails are not getting lost. If even one of these items fails, it is better not to launch a public fundraiser until the issue has been diagnosed.

Pre-launch check: create a test campaign with a small fundraising goal, open the page while logged out of the admin area, and complete the full donor path. A user who is logged into WordPress often will not see caching or permission issues the way a normal visitor will.

The Campaign as the Central Object: Goal, Story, Form, and Display

The most common beginner mistake with Charitable is thinking of it as a set of separate forms. In reality, you should start with the campaign. The campaign connects the fundraising story, page layout, form fields, goal, timeline, suggested amounts, progress, on-site display, and future donation records. If the campaign is poorly designed, even a technically working form will inspire less trust.

Template or Built from Scratch

In the Charitable campaign builder, you can choose a ready-made template or a simple structure you build yourself. A template is useful when you need a working page quickly because it already includes basic blocks, visual rhythm, and content areas. Building from scratch makes sense when you already have your own landing page, brand-specific structure, or strict content requirements.

The right choice depends on the team. If editors will be creating campaigns without a developer, it is usually better to start with a template and agree on a minimum block set: headline, goal description, image, progress, donation form, trust section, updates, or comments if those are part of the workflow. If every campaign is assembled by a designer or agency, you can build a more flexible structure, but it still helps to keep a clear standard for future fundraisers.

Campaign Goal and Timeline

A campaign goal does more than fill a nice-looking progress bar. It helps donors understand the scale of the need and helps the team see whether the fundraiser is moving forward. If the goal is too abstract, the progress loses meaning. It is better to tie the amount to something concrete: equipment, a month of rent, aid kits, treatment, transportation, scholarships, an event, or another outcome that can be verified.

A campaign deadline is not always necessary. For an ongoing fund, an open-ended fundraiser may be the more honest choice. For emergency relief, an event, a matching campaign, or a seasonal drive, a timeframe helps explain urgency. The key is not to set a deadline just for pressure. If the campaign should not end automatically, leave it open and explain in the text how the organization will publish updates.

Suggested Amounts and Custom Donations

Charitable supports both suggested donation amounts and custom amounts. For most campaigns, it is best to use both. Suggested amounts reduce donor hesitation and tie the money to a concrete action, while a custom amount leaves room for people who want to give less or more.

A good set of suggested amounts should feel clear and purposeful. Do not simply list 10, 25, 50, and 100 without context if the campaign has a specific mission. It is better to tie each amount to an outcome: one day of pet food, one supply kit, one consultation, one transportation run, or one child's participation in a program. If the interface lets you describe each amount, use that option. If it does not, explain the meaning of the amounts in the text near the form.

What to Verify After Configuring a Campaign

• The campaign title is clear in Charitable > Campaigns and does not look like an internal draft.
• The goal amount and timeline match the text on the page and do not conflict with emails or social posts.
• The suggested amounts make sense and do not force donors to hunt for the custom amount field.
• The form includes only the fields you actually need, and required fields do not discourage the donor.
• The published page opens on the public site and does not require a WordPress login.

How to Display the Donation Form on a Page Without Confusion

After creating a campaign, you need to decide exactly where the donor will see the form. Charitable offers several display methods: a standalone campaign page, a block in the WordPress editor, a full campaign shortcode, a campaign grid, a standalone donation form, or widgets. These options may look similar at first, but they solve different problems. If you choose the wrong one, the page can become heavy, feel cramped, duplicate the form, or show the wrong fundraiser.

Full Campaign via [campaign]

The shortcode [campaign id="123"] displays the full campaign exactly as it was built in the visual builder: story, progress, donors, form, and other layout elements. This is a strong option when you want to feature a single important fundraiser on the homepage, inside a project article, or on a landing page. The key point is to use the numeric campaign ID, not the name or URL. Charitable documentation explicitly notes that the shortcode does not work by campaign name.

If you use a page builder such as Elementor, Divi, or WPBakery, insert this shortcode through the builder's standard shortcode module. After publishing, always check the width of the content area. A full campaign is designed for a reasonably wide content column, so in a narrow column or sidebar, elements may wrap poorly. For narrow spaces, a donate button, progress widget, or compact form is often the better choice.

Campaign Grid via [campaigns]

The [campaigns] shortcode is meant for pages that need to display multiple campaigns. It is useful for an "all fundraisers" page, an active project directory, or an internal foundation section. It supports parameters for quantity, sorting, and order, and some add-ons introduce their own arguments. Do not use a grid where the visitor should quickly make one specific donation. A grid is good for selection, not for urgent conversion.

For larger sites with many campaigns, think through the archive in advance: which fundraisers appear first, how completed ones are hidden, whether category filtering is needed, what the cards should look like, and what happens to campaigns without a current image. If your version supports a dedicated campaign image setting for visually driven campaigns, use it intentionally. That image may appear in lists, shortcodes, and social shares, not just on the campaign page itself.

Standalone Form via a Block or [charitable_donation_form]

If the page already has its own custom copy, trust sections, photos, and layout, you can display only the donation form. In newer workflows, Charitable offers the Donation Form block in the WordPress editor, while older content may still use the shortcode [charitable_donation_form]. The documentation separately explains how the old shortcode can be converted into a block when editing the page, but the shortcode itself continues to work if you leave it in place.

For the Donation Form block, it is important to choose the campaign in the settings sidebar. In some cases, you can link the block to the current campaign so the same page template pulls in the active fundraiser automatically. For a regular homepage or landing page, it is usually better to select one specific published campaign. One important limitation: do not place multiple live Donation Form blocks on the same page unless there is a clear need. Charitable documentation recommends a single live form block per page to avoid extra weight and submission confusion.

Quick Rule for Choosing a Display Method

• Use the full campaign when the page needs to show the story, progress, and form together in one block.
• Use a standalone form when the page is already written by hand and only the payment section is needed.
• Use a campaign grid when the visitor needs to choose from several fundraisers.
• Use a widget or compact button in narrow areas where a full campaign would feel cramped.

Payments, Test Mode, and Offline Donations

Payment settings are the most sensitive part of Charitable. The form may look perfect, but if the gateway is not connected, test mode is not turned off at the right time, or an email only sends when the status becomes Paid, the team will get chaos instead of a clean fundraising process. That is why payment setup should follow a strict sequence: enable test mode, activate the required gateway, connect the account, make a test contribution, verify the record, and only then open live payments.

Which Gateways to Enable First

Charitable documentation lists Stripe, Square, PayPal, and Offline Donations as the core options. Additional payment gateways may be available through add-ons and depend on your version. For an initial launch, one online gateway and one offline fallback are usually enough. Multiple gateways give donors more choice, but they also increase the number of flows you need to test: redirect, confirmation, status, refund, email, report record, and reconciliation inside the payment provider dashboard.

Stripe is convenient because the basic connection is described as signing into your account rather than manually configuring keys and webhooks for the standard setup. PayPal Commerce may have its own settings, webhooks, and button options. Square has a separate sandbox flow that lets you test a donation without a real charge. Offline Donations do not require a payment account, but they do require very clear donor instructions and disciplined manual status updates.

Test Mode and Payment Verification

Before enabling live payments, use test mode if the selected gateway supports it. In Charitable > Settings > Payment Gateways, turn on test mode, save changes, connect the gateway, and submit a test donation. After that, check three places: the record in Charitable, the record or test transaction in the gateway dashboard, and the donor email. If those three points line up, the flow is working.

Do not limit yourself to checking only the WordPress admin panel. A payment gateway may accept or decline the test, and Charitable then needs to receive the event correctly and update the donation status. That is why Square documentation recommends checking the Charitable record, the transaction in the Square sandbox dashboard, and the email. The same approach is useful for any gateway: the form, the payment provider, and the WordPress record should all tell the same story.

Offline Donations as a Real Channel

Offline Donations in Charitable are not just a decorative backup button. They are a real channel for checks, cash, and bank transfers. After enabling the offline gateway, add instructions: who to pay, where to send the transfer, which account details to use, what to include in the payment note, and when confirmation should be expected. The instructions should be brief, but never vague. A donor should not need to contact support just to understand how to complete a pledged contribution.

When an offline donation is created, it appears in the records. From there, the team updates its status after the money actually arrives. If a contribution was received outside the site, it can be entered manually by selecting the campaign, amount, and donor details. This matters for honest goal tracking. If part of the money comes in offline but the site shows only online contributions, visitors see an incomplete picture.

Donors, Emails, Receipts, and Reports After the First Contributions

Once the campaign is live, the center of gravity shifts from page building to data management. Charitable stores donations, helps you track donor activity, build reports, export data, and send emails. Care matters here. If records stop updating, emails stop sending, or statuses get changed manually with no rules, the team will quickly stop trusting the system.

Donation Records and Statuses

Each donation should be tied to a campaign, amount, donor, payment method, and status. For online payments, the status depends on the gateway response. For offline contributions, it may stay pending until the funds arrive. Do not change statuses just to make things look cleaner. They should reflect the actual state of the payment. If a donation was canceled, refunded, or never completed, it is better to keep the correct status than to delete the record without a trace.

When the volume of data grows, use filters and exports. Exporting can help a bookkeeper, campaign coordinator, or CRM if the data is processed outside WordPress. But before exporting, check which fields the recipient actually needs. Do not pass along unnecessary personal data if the report only requires amount, date, campaign, and status.

Emails to Donors and Administrators

Emails are part of donor trust. A donor expects confirmation, and an administrator expects notification of a new contribution. In Charitable settings, check which emails are enabled, which event triggers them, which sender address is configured, which dynamic tags are used, and what the message actually says. Do not leave generic English email templates untouched if your site serves a Russian-speaking audience. At the same time, only change the technical tags inside a template according to the documentation so you do not break the insertion of the donor name, amount, or campaign title.

Charitable documentation highlights an important detail: some emails are only sent after the donation reaches Paid status, not while it is still awaiting confirmation. So if no email arrives after a PayPal or offline donation, check the status first rather than focusing only on the mail server. If the status is correct but the messages still do not arrive, set up reliable SMTP delivery and review the mail log.

Receipts and the Donor Dashboard

Charitable's premium features include workflows such as PDF receipts and a donor dashboard. These are useful when the organization has many recurring supporters, annual reporting needs, requests to download confirmation documents, or a need to give donors self-service access to their donation history. Do not enable a donor dashboard just for the sake of completeness. It introduces user accounts, profile settings, privacy concerns, and password reset support.

If the donor dashboard is enabled, check which tabs and fields are visible to the user: profile, donations, campaigns, comments, communication settings, and so on. The team should clearly understand what the donor can manage on their own and what remains under administrator control. For emails and receipts, run a complete test: make a donation, receive the email, download the receipt, and review the donation record in the dashboard.

Fine-Tuning the Form: Fields, Appearance, and Donor Trust

Form setup in Charitable should begin with one question: "what does the donor need to do quickly and confidently?" The visual builder and Donation Form block offer flexibility, but too much flexibility can easily turn into an overloaded form. The more complex the form becomes, the more carefully you need to test the mobile view, required fields, error messages, suggested amounts, and payment options.

Form Fields and Required Data

In the visual form builder, there are required fields without which the donation cannot be processed: donor details, email, the payment section, and the amount. Add extra fields, descriptions, comments, social elements, and design sections only when the campaign actually needs them. If the fundraiser is urgent, the form should stay short. If the campaign is tied to events, memorial donations, or reporting requirements, extra fields may be justified, but they should be explained.

A good form does not make the donor guess. If a field is required, the label should make it clear what to enter. If a field relates to public display of a donor name or comment, the wording should be careful. If anonymous giving or privacy settings are used, do not promise more than your version and documentation actually support. A short, honest note is better: visibility of names and comments depends on the campaign settings and the available features.

Full vs. Minimal Form Layout

The Donation Form block includes Full and Minimal layout options. The full version works best on the main campaign page, where the donor is already ready to complete the entire form. The minimal version is better in tighter spaces: inside the middle of an article, on a news page, in a campaign footer, or inside a short call-to-action section. But a minimal form should not hide important conditions. If the payment method, amount, or consent options become unclear, the full version is the better choice.

Each placement should have one purpose. On a landing page, one main form is enough. On a homepage, you might show a compact block that either links to the campaign or displays the form for one specific fundraiser. In a sidebar, it is usually better not to place a complex multi-step form. Narrow areas almost always make fields harder to use, especially on mobile devices.

Appearance and Theme Inheritance

Charitable tries to inherit styles from the active theme and can use CSS variables for visually built forms. That is useful because the form does not look out of place. But theme inheritance is not always perfect. Sometimes the theme makes buttons too small, fields too cramped, or spacing inconsistent. That is why every visual change should be checked on the actual page, not only inside the builder.

If you need to adapt the form carefully, start with builder settings and the custom CSS class field if your version includes it. After that, you can add a small CSS adjustment in a child theme or in Appearance > Customize > Additional CSS. Do not edit plugin files directly. An update will overwrite the changes, and one CSS mistake can affect every form.

Safe CSS Example Based on Variables

The visual builder documentation references CSS variables for spacing, padding, border radius, and focus color. Below is a cautious custom adaptation that defines those variables on your own page container. Before using it, add this class to the section or block that contains the form and test the result on a site copy.

.donation-page-charitable {
  --charitable-field-gap: 18px;
  --charitable-input-padding-y: 12px;
  --charitable-input-padding-x: 14px;
  --charitable-input-border-radius: 8px;
  --charitable-focus-ring-color: #2f8f68;
}

.donation-page-charitable .wp-block-button__link {
  font-weight: 700;
}

After adding it, open the page as a regular visitor and check the fields, button, keyboard focus, and mobile view. If the form looks worse or the styles do not apply, remove the CSS and go back to the builder settings. The required final step is testing an actual form submission after any visual changes, because sometimes the conflict is not visual at all, but caused by script optimization.

When to Hide the Login or Registration Prompt

In some cases, the form may display a login or registration reminder. Charitable documentation describes a setting and the charitable_donation_form_login_allow filter, which disables that block from loading. First, look for a setting in the General section if your version provides one. Use code only when the team understands why the prompt is being hidden and how that will affect donor dashboard workflows.

add_filter( 'charitable_donation_form_login_allow', '__return_false' );

Add a snippet like this through Code Snippets or a child theme, not in the plugin files. Verification is simple: open the form while logged out of WordPress, confirm that the login block is gone, and then make a test donation. Rolling back is just a matter of disabling or removing the snippet. If the site uses a donor dashboard, discuss the change with the team first because registration may be part of your donor strategy.

Practical Example: Shelter Fundraiser with Online and Offline Contributions

To keep this from staying abstract, let us walk through a concrete example. Imagine an animal shelter website launching a campaign to cover one month's worth of food and veterinary expenses. The page needs to tell the campaign story, offer clear suggested amounts, accept card payments, and keep bank transfer available for supporters who prefer an offline option. The team needs to see all contributions in Charitable and send each donor a confirmation.

Goal and Preparation

The goal is to build a campaign page with a donation form, progress tracking, and two payment methods. Preparation includes installing Charitable, confirming administrator access to settings, making sure the site runs over HTTPS, selecting the primary gateway, preparing bank transfer details for offline payments, and verifying email delivery. If the campaign will also appear on the homepage, prepare the block or shortcode placement in advance.

For this type of fundraiser, it is better to start from a campaign template rather than a blank page. In the template, replace the image, headline, description, and result-related blocks. The text should answer three questions: what the fundraising is for, why the support is needed now, and how the organization will verify the outcome. If the nonprofit publishes reports, you can promise campaign updates, but do not commit to a specific reporting format unless the team is ready to maintain it consistently.

Setup Steps

1. Open Charitable > Campaigns and create a new campaign with Add New.
2. Choose the template that best matches the goal, or a simple layout if you already have a finished page structure.
3. Enter a clear campaign title, such as "A Month of Food and Care for the Shelter."
4. Add the story: who the fundraiser supports, how much is needed, and how the organization will confirm use of the funds.
5. Set the campaign goal and, if needed, the end date.
6. Add suggested amounts with a short explanation for each: one day of food, a vaccination, part of a vet bill.
7. Keep the custom amount option so the donor can choose a different contribution size.
8. Enable the primary payment gateway in Charitable > Settings > Payment Gateways and verify test mode.
9. Enable Offline Donations and write brief bank transfer instructions.
10. Publish the campaign and place it on the target page with a block or [campaign id="123"].

Verifying the Outcome

Open the page in a private browser window. Choose one of the suggested amounts, fill out the form, and complete either a test payment or the offline flow. After submission, check the confirmation page, the record in Charitable > Donations, the payment status, the donor email, and the administrator notification. If campaign progress is enabled, make sure the amount appears where it should.

Then test the reverse path. Create an offline contribution, find the record, update the status after the simulated funds arrive, and confirm that the campaign report shows the expected amount. If the offline instructions are unclear to even one person on the team, rewrite them before publishing. Donors will not pause to figure out internal procedures on their own.

Common Pitfall Before Launch

Teams often build a beautiful campaign but forget to test it while logged out of WordPress. As a result, the administrator sees a working form, while a regular visitor runs into cached pages, a hidden JavaScript error, an unavailable payment method, or an outdated security token. That is why the final check should always happen from the public-facing site, in a separate browser or private window.

Quick takeaway from this example: the campaign is only ready when a test donor can complete the chosen path and the team can see the record, status, email, and progress without manually hunting through several different places.

How Charitable Works with WordPress, the Block Editor, the Theme, and Cache

Charitable lives inside WordPress, so the final outcome depends on more than its own settings. The page is affected by the theme, the block editor, the page builder, caching, script optimization, SMTP, security plugins, and user permissions. A solid setup takes those neighboring systems into account from the beginning.

Block Editor and Page Builders

If you work in the block editor, use the Donation Form block for targeted form placement and shortcode blocks for campaigns where appropriate. In page builders, use the built-in shortcode elements. Do not place the same shortcode inside multiple hidden tabs, popups, or duplicate sections without testing. The form may load more than once, and the visitor may see unpredictable behavior.

For pages built with Elementor, Divi, or another builder, check two states: the editor and the published page. The editor may show internal placeholders, while the front-end output looks normal after publishing. If the campaign does not appear after publish, check the campaign ID, campaign status, container width, deferred script loading, and page cache.

Cache and Pages with Live Forms

Cache can make a site faster, but donation forms require careful handling. Donation Form Block documentation notes that pages containing a live form block are automatically excluded from full-page caching. On real sites, though, there are often additional layers: the cache plugin, server cache, CDN, JavaScript optimization, builder cache, and host-level cache. So after setup, do not rely only on the assumption that the automatic exclusion will be enough.

Add the campaign page, the form page, the confirmation page, and any landing pages with manually embedded forms to your exclusion list. If fragment caching or script bundling is enabled, temporarily disable optimization while testing. A cache-related problem often looks like a security error when submitting the form or inconsistent payment block behavior for guest visitors.

SMTP and Email Reliability

For donations, email matters more than it does for a standard contact form. The donor expects confirmation, and the administrator expects a signal that a new contribution came in. If the host sends PHP mail unreliably, Charitable may work correctly while the message never arrives. That is why, on a production donation site, it is smart to configure SMTP delivery and enable an email log if your SMTP tool supports one.

After connecting SMTP, run a full test: online contribution, offline contribution, donor email, administrator email, resend flow or receipt if those features are available. Check more than just whether the message arrives. Review the campaign name, amount, status, thank-you copy, and organization contact details.

How to Verify Everything After Setup

Verification is not something you do only on installation day. It should be repeated after Charitable updates, a theme change, cache changes, a new gateway connection, placing the form on a new page, or launching an important fundraiser. The best approach is a short acceptance checklist that can be handed off to an editor or site administrator.

Verification Path for the Administrator

Start in the admin panel. Open Charitable > Campaigns and confirm that the campaign is published. Check the goal, date, suggested amounts, and chosen display method. Then open Charitable > Settings > Payment Gateways and verify that the correct gateway is enabled, that it is running in the right mode, and that no test configuration remains where live payments are now required.

After that, open the public page while logged out of WordPress. Confirm that the form is visible, buttons can be clicked, suggested amounts can be selected, the custom amount works, the payment section is displayed, error messages are understandable, and the page does not look broken on mobile width. If the full campaign is shown through a shortcode, make sure the story, progress, and form do not conflict with the theme containers.

Verification Path for the Payment Flow

For an online gateway, perform a test payment according to the chosen provider's documentation. In test mode, do not use real cards and do not try to work around gateway restrictions. After submitting the form, check the Charitable record, the status in the payment provider dashboard, and the email. If the status in Charitable did not update but the provider shows a successful event, inspect the webhooks, IPN, or the connection settings for that specific gateway.

For an offline contribution, choose Offline Donations, read the instructions through the eyes of a donor, submit the form, and find the resulting record. Then update the status the same way your team would after the funds are actually received. Check whether that status affects both the report and campaign progress. If the process requires manual reconciliation, document the internal rule: who changes the status, when they do it, which supporting record they use, and where confirmation is stored.

Verification Path for Data and Email

Open the donation record and confirm that it includes the campaign, amount, donor, email, payment method, and status. Then review the donor email. It should be clear and free of stray internal wording, wrong currency, or empty placeholders. If a PDF receipt or donor dashboard is in use, test both the document download and the donation history view.

The final step is the export or report. Even if you do not plan to export data every day, make sure a report can be generated and that the fields are clear to the person handling accounting or analytics. If you need extra fields, add them before public launch, not after some donations have already come through without that data.

Troubleshooting Common Charitable Problems

Most Charitable issues do not come from one single "broken" element, but from a gap somewhere in the chain: the form loads from cache, the payment gateway does not send an event, the status stays pending, the server never delivers the email, the campaign is inserted with the wrong shortcode, or the display area is too narrow. Below is a practical symptom map worth walking through before contacting support.

The Form Shows a Validation Error or Will Not Submit

Symptom: the donor submits the form and sees a message saying the submission could not be verified, or is asked to reload the page. In the admin area, you may also see warnings about failed attempts triggered by security checks.

Likely cause: the form page is being served from cache, and the hidden security data has gone stale. A conflict with the theme, an optimization plugin, or a third-party script is also possible.

What to check: open the form as a guest, clear the page cache, disable JavaScript bundling during testing, and add the donation page to cache exclusions. See whether the error repeats under a different theme or with nonessential plugins disabled on a site copy.

How to fix it: exclude form pages from full-page caching, remove aggressive script optimization on those pages, and update Charitable and the theme. The documentation mentions a code-based fallback that reduces validation checks, but that is a last resort. Use it only after making a backup and understanding the risk.

Payments Stay in Pending Status

Symptom: the donor says they paid, but in Charitable the record remains pending or never moves to a paid state. For PayPal this is often tied to IPN messages, while for Stripe or Square it is more commonly related to connection issues, events, or test mode.

What to check: open the record in Charitable, then check the payment gateway dashboard. If the gateway does not show a successful transaction, the problem is not inside Charitable. If the gateway does show the payment, check webhooks, IPN, test vs. live mode, and the logs for that specific gateway.

How to fix it: reconnect the gateway according to the documentation, verify webhooks, and repeat the test payment. Do not bulk-change statuses manually until you understand the root cause. Manual status updates are only appropriate for specific records when the team is certain the money was actually received.

Donation Emails Are Not Arriving

Symptom: the donation record exists, but the donor or administrator never receives an email. In some cases, the email appears only after the status changes to Paid.

What to check: the donation status, enabled emails in Charitable settings, the sender address, the admin email address, the spam folder, and the SMTP plugin log. Keep in mind that some emails are not sent for pending payments.

How to fix it: configure SMTP, review email templates and dynamic tags, and run a test with a paid record. If WordPress sends the message but it is not delivered, the issue is usually email deliverability, not the donation form itself.

The Campaign or Form Does Not Appear on the Page

Symptom: the page shows a blank area, the shortcode does not output the campaign, the block displays a placeholder, or the wrong campaign is shown.

What to check: the campaign status, numeric ID, correct shortcode, campaign selection in the block sidebar, access permissions, and page publication status. For [campaign], use the ID rather than the name. For the Donation Form block, choose a published campaign or current-campaign mode only where it is actually appropriate.

How to fix it: reinsert the block or shortcode, verify the ID in the campaign list, update the page, and clear cache. If the page was built in a page builder, check the published output, not just the editor preview.

The Form Layout Breaks After an Update

Symptom: fields become cramped, the button loses its styling, the progress bar looks uneven, or the form starts conflicting with the theme.

What to check: builder settings, custom CSS classes, CSS variables, style cache, CSS minification, and theme updates. If you previously edited plugin files, those edits may have been lost during the update.

How to fix it: move your adjustments into a child theme, Additional CSS, or Code Snippets. Use CSS variables and your own wrapper container instead of editing Charitable files directly. After fixing the layout, check the mobile view and test a real form submission.

Many Suspicious Pending Donations Start Appearing

Symptom: the records quickly fill with many pending or failed donations, often with similar amounts or suspicious donor data.

Likely cause: the public donation form has become a target for automated card-testing attempts or spam. This is a common risk across online payments in general, not just on one specific site.

What to check: the Stripe or PayPal dashboard, statuses in Charitable, security logs, attempt frequency, IP addresses, enabled protection measures, and the current campaign status.

How to fix it: temporarily move the campaign back to draft if the attack is active, review payment dashboards, enable available protection settings, consider Cloudflare or similar protection, and only mass-delete records after a backup and audit. Do not delete everything blindly if real contributions may be mixed in.

Advanced Features That Should Only Be Enabled for a Real Need

Charitable has grown into a broader platform, and around the core campaign system there are many advanced capabilities: recurring donations, Fee Relief, donor dashboards, PDF receipts, Donation Recovery, DonorTrust, Campaign Updates, Tributes, Ambassadors, Webhooks, Zapier, Zoho Flow, imports, and migrations. These are powerful features, but they should not be switched on automatically on day one. Each one changes the way the team works.

Recurring Donations

Recurring donations are useful when the organization is building long-term support rather than only trying to close an urgent campaign. Before enabling them, think through billing frequency, donor-facing wording, cancellation handling, failed-payment emails, and reporting. If recurring payments are available through your plan and gateway, make sure to test creation, renewal, failure, and email notifications. Do not promise donors self-service subscription management unless the dashboard or related feature is actually enabled.

Fee Relief

Fee Relief lets you ask the donor to cover the payment provider fee if that option is available in your version. This can help the organization keep an amount closer to the intended net donation, but the wording needs to stay honest. The donor should understand that the extra amount is optional and why it appears. After enabling it, check the calculation, final total, email content, and report record.

Peer-to-Peer Campaigns and Ambassadors

A peer-to-peer setup makes sense when supporters create their own fundraising pages or raise money in teams. At that point, you are no longer dealing with just a donation form, but with a mini-platform inside the site: applications, moderation, page templates, participant emails, fundraiser accountability, and brand rules all enter the picture. Ambassadors features are best enabled only after your core campaigns, payments, and reporting are already stable.

Donation Recovery and Campaign Updates

Donation Recovery helps bring back incomplete donations if that feature is available in your version. But it depends on WP-Cron, email delivery, consents, selected campaigns, and valid recovery links. Campaign Updates are useful for longer fundraisers: the team can publish news, milestones, or urgent updates so donors can see that the campaign is still active after the first contribution. In both cases, the main risk is turning on automation without an editorial process behind it. If no one is responsible for the copy, schedule, and review, automation quickly becomes noise.

When It Makes Sense to Download and Start Testing

Charitable is a strong choice when your WordPress site needs to do more than accept money. It should support a clear campaign flow: show the goal, collect the contribution, record the donor, send the email, reflect progress, and give the team a usable admin workflow. For nonprofits, foundations, clubs, local initiatives, and agencies, that often reduces operational overhead more effectively than a patchwork of separate payment forms.

Before going live, check three things. First, does the campaign structure fit your organization: a single fundraiser, several parallel campaigns, an ongoing program, or supporter-led fundraising? Second, does your version include the features you actually need: core payments, offline contributions, recurring donations, donor dashboard, PDF receipts, add-ons, and integrations? Third, is the team ready to maintain the process: updating campaigns, reconciling statuses, responding to emails, and monitoring form security?

If those conditions line up, you can download the ZIP file, install the plugin on a site copy or test page, and walk through the workflow from this guide. Do not launch a public fundraiser until you can see a working donation record, the correct status, the email, and a clear outcome on the campaign page.