Question about the plugin with its background activity
-
Does Donor Merchant make any external HTTP/API requests, AJAX requests, scheduled background requests, or WordPress cron jobs when a campaign page loads or when nobody is making a donation? Or are external/payment requests only made when a visitor actually submits a donation?
-
Great question, and an easy one to answer because the plugin is deliberately quiet.
When a page loads and nobody is donating, Donor Merchant makes no external or background server requests. The donation form and the goal thermometer render entirely from your own database. There is no AJAX polling, no heartbeat, no telemetry, and the plugin never “phones home” to us or to any analytics or licensing server. You can confirm it in the source: a search for wp_remote_ only turns up Stripe, PayPal, and the optional webhook/Mailchimp calls below.
One clarification, since you asked precisely: on a page that actually contains the donation form, the visitor’s browser loads Stripe.js (from js.stripe.com) and/or the PayPal SDK (from paypal.com). That is required so card details are typed into the gateway’s own secure fields and never touch your server, which is what keeps you out of PCI scope. It is a browser-side script load, not a server call, and no donor or payment data leaves the browser until someone submits. On pages without a form, those scripts are not loaded at all: they are registered but only enqueued when a form is present.
Your server only calls Stripe or PayPal when:
- a visitor actually submits a donation;
- Stripe or PayPal send an incoming, signature-verified webhook, which they initiate;
- a donor clicks “manage my recurring gift” in the donor portal;
- and, only if you have turned them on, an outgoing webhook (Zapier/Make) or a Mailchimp sync fires the moment a donation completes.
Background/cron: the plugin registers a single WordPress cron event. On most days it does nothing; on the 1st of each month it emails the fundraising summary to your own admin address (if you leave that enabled). It makes no external request, just a local email, and WP-cron only runs when your site gets a visitor, so there is no persistent background process.
So: idle pages are silent, and external or payment requests happen only on a real donation plus the incoming webhooks the gateways send you. Happy to point you to the exact lines if that would help.
That is so awesome to know. I switched to namescheap for hosting and their stellar business plus and we only get 2g ram lol. I am using charatible and that is one that is making a lot of calls filled up my op-cache and another plugin did it too. lol
Hit enter by accident. So I am planning on switching to yours. 😉
Glad that helped, and thanks for saying so.
That resource profile is exactly what Donor Merchant is built for. The whole plugin is 20 PHP files, about 7,200 lines, 97KB zipped, and only 14 of those files load on a front-end request (the admin classes never load for visitors). Combined with no idle HTTP calls, there is not much for it to fill your opcache with.
If you do switch, one practical note so nothing surprises you. Version 2.5.0 added a CSV importer built for exactly this: export your donation history from Charitable, then go to Donor Merchant > Import, upload the CSV, and it will auto-detect the columns. Preview it first, which writes nothing, and imported gifts never send receipts, so your existing donors will not get emailed about old donations. It is also safe to run twice.
The one thing that cannot come across is any active recurring donation. That is not a limitation of the importer: a subscription lives in your Stripe or PayPal account tied to the integration that created it, so no plugin can move one. The usual approach is to leave Charitable installed until its existing subscriptions run their course, while new gifts go through the new form. There is a full write-up here if it is useful: https://www.donormerchant.com/guides/migrate-donation-plugin-keep-donor-history/
Happy to help if you hit anything during the switch.
You must be logged in to reply to this topic.