myCred Gateway WPMU DEV Fundraising - WordPress Plugin

How to Set Up myCred Gateway WPMU DEV Fundraising for Point-Based Donations

myCred Gateway WPMU DEV Fundraising is not meant to replace your site's entire donation system. Its role is narrower: it connects the myCred points economy with WPMU DEV Fundraising campaigns. In this guide, we'll look at how to approach the installation, what to verify before enabling the gateway, how to configure the point type, how to test a point-based donation, and where to look if the payment option does not appear or the user's balance does not change.

This guide is written as a practical walkthrough for an existing WordPress site. It does not repeat the product's marketing copy or make promises that cannot be verified in your own setup. Instead, it follows the administrator's workflow: prepare the site, verify dependencies, enable the gateway, define deduction rules, create a test campaign, and make sure the myCred log, user balance, and campaign data all stay in sync.

There is one important caveat: the official documentation page for this specific gateway is very brief, and most practical conclusions come from the myCred Gateway documentation, the myCred core documentation, and WPMU DEV Fundraising materials. So wherever exact behavior depends on your version or the screens in your installation, the wording here stays intentionally cautious. The final check should always be done on a test campaign using a separate user with a known balance.

How This Integration Works Inside WordPress

myCred Gateway WPMU DEV Fundraising belongs to the myCred family of store gateway integrations. These gateways add myCred as a payment or contribution method inside supported store, event, or fundraising plugins. In a standard payment system, a user pays with money through PayPal, Stripe, or another external service. Here, the flow is different: the site participant uses an internal points balance, and the site records that action as a contribution to a campaign.

It is important not to blur the roles of the three components. WordPress stores users, permissions, posts, pages, and plugins. WPMU DEV Fundraising handles campaigns, forms, goals, progress, widgets, and donation presentation. myCred handles balances, point types, transaction logs, display formatting, and restrictions. myCred Gateway WPMU DEV Fundraising sits between them and is responsible for passing the user's action from the fundraising form into the points system.

What the Gateway Does and What Other Plugins Still Handle

The gateway does not create a full loyalty program from scratch. If the site does not already have a thought-out points economy, it only gives you the technical ability to spend or accept points in the context of a donation. In the same way, it does not replace the WPMU DEV Fundraising campaign interface. If a campaign is unpublished, misconfigured, or not rendered correctly in the template, the gateway will not fix the fundraising page itself.

In practical terms, this means:

• The balance, point format, point editor permissions, and transaction log are configured in myCred.
• The campaign goal, fundraising type, donation form, progress, and widgets are configured in WPMU DEV Fundraising.
• myCred Gateway WPMU DEV Fundraising handles the scenario where points become a way to participate in the campaign.
• The final result should be verified in the public form, the myCred log, and the campaign data at the same time.

Why This Is Not a Typical Payment Gateway

Internal points are not money by themselves. Even if you assign them a notional exchange rate for convenience, they remain an internal unit within the site. That means this kind of gateway is not a fit for every project. It is especially useful where users already earn points for activity, learning, purchases, community participation, or completing tasks, and can then direct part of that accumulated balance toward a campaign.

If the site accepts legally significant donations, issues tax documents, or must process payments through an external payment system, a points-only mechanic cannot replace financial accounting. In that case, use it as an additional engagement path, while leaving money payments to a dedicated payment solution.

Who Point-Based Donations Make Sense For

myCred Gateway WPMU DEV Fundraising works best in communities where points already mean something to users. That might be an educational portal, a club, an internal network, a volunteer site, a content-driven community, or a project with gamification elements. The user sees that their accumulated activity is not just sitting in a profile, but can be directed toward a shared goal.

When the Product Makes Sense

The gateway is worth considering if the site already has active users, clear earning rules, and at least one scenario where points are perceived as valuable. For example, a participant earns points for completing lessons, answering on a forum, or making purchases, and can then support an internal campaign: raising funds for a community event, distributing bonuses, voting for an initiative, or contributing to a project fund.

A strong sign that the site is ready is when users already know where to check their balance. If points still look like a random number in the admin area, set up myCred first: names, history, profile balance display, earning rules, restrictions, and a clear explanation on the site. The donation gateway should come after the points economy, not instead of it.

When Another Solution Is a Better Fit

This product may be unnecessary if all you need is a simple money donation button with no points involved. It is also not the best fit for a site without user accounts, because balance deductions are usually tied to a specific account. Finally, be more cautious on projects with strict financial reporting requirements: points can support engagement, but they do not replace payment records and accounting procedures.

If your main priority is a modern donation form, donor management, reporting, recurring payments, and payment gateway integrations, look at full-featured donation plugins instead. myCred Gateway WPMU DEV Fundraising makes more sense when Fundraising and myCred are already in place and the goal is specifically to add an internal points-based participation method.

What to Check Before Installation

Narrow integrations usually break not because of the gateway itself, but because the environment is not ready. Before installation, verify more than just WordPress. Check the condition of both dependencies: myCred and WPMU DEV Fundraising. If either core plugin is disabled, misconfigured, or conflicting with the theme, the gateway layer will not produce stable results.

Minimum Technical Preparation

The official myCred documentation lists WordPress and PHP requirements, and the Gateway add-on page also describes the minimum requirements for the gateway module itself. In practice, the administrator does not need to memorize version numbers. What matters is checking three things: the site runs on a supported WordPress version, PHP is not obviously outdated, and the plugins are not conflicting through fatal errors or warnings.

Before installation, create a backup and, if possible, repeat the setup on a staging copy. This matters even more on sites where points are already in use: a bad configuration may not destroy data, but it can create incorrect deductions, log confusion, or inaccurate campaign statistics. Ideally, you should have a test user with a predefined balance and a separate test campaign hidden from your main audience.

Check myCred Before Connecting the Gateway

Open the admin panel and make sure myCred has already gone through its initial setup. There should be at least one point type with clear singular and plural labels, display formatting, and management permissions. The myCred documentation notes that each point type has its own key and separate settings, and that multiple types create separate menus, logs, settings, and widgets.

Verify the following:

• The user you will use for donation testing is not excluded from the selected point type.
• The user's balance is higher than the amount you plan to deduct during the test.
• The myCred log is enabled and shows transactions for the correct point type.
• The administrator clearly understands which point type will be used for campaigns if the site has multiple point types.
• Point Editor and Point Administrator permissions have not been assigned to roles accidentally.

Check WPMU DEV Fundraising

First, make sure Fundraising itself can create a campaign and display it on the site without the myCred gateway. WPMU DEV Fundraiser materials describe campaigns, goals, pledge scenarios, the progress bar, widgets, and adding fundraising items to pages or menus. If the base form is not visible, the pledge button does not work, or the campaign does not save its settings, do not move on to myCred Gateway WPMU DEV Fundraising yet. Fix the basic fundraising setup first.

The safe order is this: first a working Fundraising campaign, then working myCred points, then the gateway connection between them. If you start with the gateway integration, troubleshooting turns into guesswork.

Installation and the First Check After Activation

Install the plugin as a standard WordPress ZIP package: go to Plugins and Add New, upload the archive, and click Activate. If the file came from your WPMU DEV or myCred account, follow their official installation instructions. If you are working with an older build or an archive from a local project repository, do not mix it with unknown copies from random directories.

The Right Order for Enabling Dependencies

The optimal order is simple:

1. Update and enable the WordPress dependencies already used by the site.
2. Activate myCred and verify the point type, the test user's balance, and the log.
3. Activate WPMU DEV Fundraising and create a test campaign.
4. Activate myCred Gateway WPMU DEV Fundraising.
5. Open the Fundraising or campaign settings and look for the options related to the points-based participation method.

The myCred Gateway documentation explains that the add-on does not always have a large standalone settings page. When a supported plugin is installed and configured, myCred adds the relevant settings inside that plugin's own menu. So do not treat it as an error if activation does not create a separate large section just for the gateway.

The First Check Without a Real Donation

After activation, do not launch a public campaign right away. First, verify that there are no fatal errors in the admin area, that the campaign page opens, and that the test user sees the expected interface. If the points option appears only when the user has a sufficient balance, use a user with plenty of points. If the option does not appear at all, check that the selected campaign type supports the required flow and that the user is logged in.

A good initial check takes only a few minutes: open the campaign as the user, inspect the form, go back to the admin area, review the WordPress error log, and inspect the myCred log. Until you make a test donation, the myCred log should not show any unexpected deductions. If it does, stop and check other earning or deduction hooks that may have fired on the same page.

Configuring Points and Deduction Rules for Campaigns

The most important part of configuration does not live only inside the gateway plugin itself. To make point-based donations behave predictably, you first need to clean up the point type, display format, management permissions, log, and user exclusion rules. Otherwise, the user may see one point amount on the page, a different one in the profile, and the administrator may not understand why the total changed.

Choosing the Point Type

If the site uses only one point type, the task is easier: use it for the test campaign and make sure the format is understandable to the user. If there are several types, do not just pick the first one. For example, an educational site might use "experience," "coins," and "reputation." For donations, it is better to use the type the user can actually spend without breaking the main logic behind ranks, certificates, or course access.

In myCred, each point type has a key stored in user metadata. That key must be unique and assigned carefully. Do not change it on a live site unless you understand the consequences: you can break the connection between existing balances, widgets, and history. If you need a new point type specifically for campaigns, create it in advance, configure its display, and assign different balances to several test users.

Format, Limits, and Permissions

In the point type settings, review four groups: Label, Format, Security, and Other. Label controls the singular and plural name. Format defines how the value appears on the site. Security matters for permissions and the maximum value myCred can assign. Other may affect log behavior when a user is deleted.

After changing these settings, save them and clear the cache if the site uses page caching or fragment caching. Then open the balance page as the test user. If the balance is displayed through a shortcode, make sure that shortcode is using the correct point type, especially after creating multiple types.

What to Show the User Before the Donation

The user should not discover they lack enough points only after a failed form submission. Add a clear balance block next to the campaign. myCred provides basic shortcodes for this, including [mycred_my_balance] for the current balance and [mycred_history] for transaction history. Use them carefully: do not place a detailed history directly inside the donation form if it makes the page too busy.

[mycred_my_balance]
[mycred_history number=5]

This block is not a required part of the gateway plugin, but it reduces user confusion. If the balance is visible before the click, the person immediately knows whether they can support the campaign. After testing, verify that the shortcode does not expose someone else's data and works correctly only for the logged-in user.

How Pledges, Campaign Goals, and the Point Balance Fit Together

WPMU DEV Fundraising documentation describes several fundraising methods: simple donations, goal-based campaigns, pledge buttons, progress bars, and widgets. For myCred Gateway WPMU DEV Fundraising, the key question is which user journey you actually want to enable. Not every site needs to expose every option. The simpler the first scenario, the easier it is to verify that points are behaving correctly.

Points as a Donation or as Internal Support

Conceptually, there are two different scenarios. In the first, the user gives their points to a campaign and that is treated as a contribution. In the second, the user receives points for participating in fundraising, so the donation becomes an action that is rewarded. The myCred Store Gateways page describes WPMUDEV Fundraising as an integration that lets users make donations or receive donations in points. In a real installation, verify which option is available in your version and how it is labeled in the interface.

If you use points as a spendable resource, decide in advance what should happen if the campaign is canceled or fails. Should the points be refunded? Who is allowed to adjust the balance manually? How will the user see the history? If you do not have answers to those questions, do not launch a public campaign. A points economy loses trust quickly when users cannot tell why their balance changed.

Goals, Progress, and User Expectations

If the campaign displays progress, check carefully how points relate to the goal. Do not state on the page that one point equals a specific monetary amount unless that rule is formally defined in your project and confirmed by the configuration. A safer explanation is something neutral, such as: "You can support this campaign with your saved points." If a conversion is needed, make it explicit in the campaign description.

For campaigns with gifts or support tiers, it is especially important not to create false expectations. If Fundraising grants rewards for monetary pledge tiers, verify whether those same rewards also apply to the points-based flow. If there is no exact confirmation, do not promise automatic rewards. Test one support tier first and see what appears in the campaign record and the myCred log.

Practical Example: A Test Campaign With a Point Contribution

Below is a safe launch example you can repeat on a staging site or in a hidden test campaign. It is not tied to any specific price, currency, or public goal, because the purpose is to verify the mechanics: the user sees the balance, chooses the points-based participation option, the balance decreases, the campaign records the contribution, and the administrator can explain every entry in the log.

Goal and Preparation

Goal: create a private campaign called "Community Support Test" and run one point-based donation from a user with a predefined balance. Before you begin, myCred, WPMU DEV Fundraising, and myCred Gateway WPMU DEV Fundraising should all be enabled. The test user should have a known balance, ideally high enough for a sample deduction. The campaign should be published in a way that only the test user or an administrator in review mode can see it.

Verification Steps

1. In myCred, open the settings for the selected point type and verify the name, format, permissions, and exclusions.
2. Create or open the test user, assign a control balance, and record that value in your test notes.
3. In WPMU DEV Fundraising, create a campaign with a simple goal and no extra rewards or complex conditions.
4. Add the campaign to a test page and display the user's balance next to it using a myCred shortcode.
5. Open the page in a separate browser or private window as the test user.
6. Select the points-based participation option, submit the form, and wait for confirmation.
7. Compare the old balance, the new balance, the myCred log entry, and the campaign data.

Expected Result

After a successful test, you should see four matching signals. First, the user receives a clear message on the campaign page. Second, the user's balance changes by exactly the expected amount. Third, the myCred log contains an entry with the correct user, point type, and amount. Fourth, the campaign data reflects the user's participation in the way you intended.

Test summary: if even one of those four signals does not line up, it is too early for a public launch. You need to identify where the chain breaks: the form, the gateway, the balance, the log, or the campaign.

A Detail People Often Miss

Administrators often check only the public page and assume success as soon as they see a "thank you" message. For a points gateway, that is not enough. The message may appear while the myCred log records no deduction, or the reverse may happen: the balance drops, but the campaign progress does not update. That is why verification should always cover both sides: the user-facing outcome and the administrative trail.

How to Make Sure the Result Holds Up After Launch

After the first successful test, do not open the form to all users immediately. Repeat the check under different conditions: sufficient balance, insufficient balance, a different user type, repeated participation, cache disabled, cache enabled. This is not just a formality. The integration sits at the intersection of the form, balance, logs, roles, and template, which means an issue may show up only for one user group.

Checking the Public Side of the Site

Open the campaign page as a regular logged-in user. Make sure the form does not look like an admin utility screen, that the balance is displayed next to the action, and that the text clearly explains the user is spending or receiving points. If the theme heavily modifies form styles, test the button, fields, error messages, and progress bar on both desktop and mobile.

If the site uses page caching, exclude the campaign page from full static cache or make sure the balance block is not cached as shared HTML. Otherwise, one user may see an outdated balance or a form state that belongs to someone else. This is especially important if the balance is rendered through a shortcode on a public page.

Checking the Admin Area and Logs

In the admin area, review two places: the campaign record and the myCred log. The log should contain a clear action that can be tied to a specific campaign or event. If the log entry is too generic, document that for project administrators: how to find the transaction, by which user, by which amount, and by the time of the test.

Also verify that manual balance edits are not being used as a permanent workaround. A one-time correction may be acceptable after a failed test, but a public system should deduct and record points on its own. If the administrator has to fix the balance manually after every donation, the integration is not ready.

It is useful to keep a short test record: old balance, new balance, campaign name, contribution amount, and a link to the log entry. That record will help after updates, because the team can compare new behavior against an already confirmed result. If an update changes only the appearance of the form, but the balance, log, and progress still match the record, the risk is lower. If even one item diverges, it is better to postpone launch until you diagnose it again.

Safely Disabling a Questionable Setting

If you see incorrect deductions after launch, the first step is to temporarily disable the points-based participation option in the campaign or deactivate the gateway plugin on a staging copy for comparison. Do not delete logs or reset balances without a backup. myCred includes management tools for bulk operations, but using them on a live site without a rollback plan is risky.

Rules for the Points Economy Around Campaigns

Technically, you can enable the gateway and immediately give users a button, but that is not enough for a live community. Points need clear rules: where they come from, what it means when they are deducted, whether an action can be reversed, how the user sees the history, and who handles disputes. Without those rules, even a technically correct plugin can create distrust, because people will treat the balance as a personal resource.

Start with a short internal document for administrators. It does not need to be elaborate. It is enough to define one selected point type, the pages where users see their balance, the campaigns where points can be used, and the procedure for manual correction when something goes wrong. Without those rules, administrators will start making case-by-case decisions, and that quickly leads to different answers for different users.

How to Explain the Meaning of a Point Contribution to the User

On the campaign page, avoid vague copy such as "use our bonuses." Explain directly what happens after the action: the selected number of points will be deducted from the balance, an entry will appear in the history, and the campaign will record the contribution according to the site's rules. If points are not a monetary equivalent, do not call them donation currency. Safer wording is "point contribution" or "support the campaign with your saved points."

If the point contribution affects the public progress bar, explain how it is counted. If it does not affect the monetary goal, do not place it next to monetary wording. The user should understand whether they are supporting the campaign symbolically, helping move a goal inside the community, or spending a resource that could have been used for another reward.

How Not to Undermine User Motivation

Points work only when users see the rules as fair. If the same point type is used for ranks, content access, and donations, spending points in a campaign may unexpectedly set the user back in another part of the system. That is why some sites are better off creating a separate point type for support contributions, while keeping the main experience points reserved for ranks and achievements.

Another option is to allow donations from only a small part of the balance. If the gateway interface or your current integration version does not support that restriction directly, do not invent risky custom code on top of a live site. A safer approach is to define fixed participation tiers in the campaign rules or temporarily use a separate point type that is funded manually or through safe myCred hooks.

What Data to Record After Every Disputed Case

When a user reports that points disappeared or were not credited correctly, the administrator should collect the same set of data every time: the username, the campaign, the time of the action, the balance before and after, the myCred log entry, the campaign state, and a screenshot of the public message if one was shown. That process helps solve the specific dispute and also reveals where issues occur most often.

Do not adjust the balance blindly. If you manually add points back before checking the log, and later discover the deduction was correct, you create a double refund. Find the record first, then decide. If there is no record but the user really did see a confirmation in the campaign, inspect the Fundraising side and the page cache.

Compatibility With the Theme, Cache, and Access Permissions

There are several points where the surrounding environment can change how myCred Gateway WPMU DEV Fundraising behaves. The theme controls the look of the form and buttons. Cache affects personalized balance blocks and campaign progress. Security plugins may block form submission if they interpret it as an unusual request. Permissions determine who can edit balances and view logs. That is why, after installation, it is important to test not only the plugin screen itself, but the full environment around the campaign page.

Cache and Personal Data

The most dangerous caching mistake is showing one user's data to another. On a page that outputs the current balance through [mycred_my_balance], you should not enable full static cache for logged-in users without testing it carefully. If the cache plugin can exclude pages, exclude the test campaign or configure dynamic rendering for the balance block. If that is not possible, it is better to show the balance in the user account area and place a link to the balance page on the campaign page.

After enabling cache, repeat the test with two different users. The first should have a sufficient balance, and the second should not. Open the page in two browsers and make sure each user sees their own balance, their own messages, and the correct access to the form. If values bleed across users, disable cache for the campaign until you find the cause.

The Theme and Form Templates

Older fundraising plugins often assume standard WordPress styling and can look uneven inside modern themes with aggressive typography, containers, and button styling. Check the form fields, submit button, error message, progress block, and widget width. If the button is visible but cannot be clicked, open the browser console and look for JavaScript errors coming from the theme or an optimization plugin.

Do not start by editing plugin files. If the appearance needs adjustment, use the theme settings, a child theme, or a safe custom CSS block in WordPress. But use CSS only for presentation, not to hide errors. If a form element disappears because of a JavaScript conflict, CSS will not fix the real issue. It will only hide it from the administrator.

Permissions and Administrator Roles

myCred lets you control permissions for point editors and point administrators. On a site with campaigns, that matters even more: the person who edits content should not automatically be allowed to change user balances. Separate those roles. A content manager can update the campaign page, a moderator can respond to users, but only a trusted administrator with a clear process should adjust balances.

After configuring roles, run a simple check: sign in with a role that should not be able to edit balances and confirm that balance adjustment screens are unavailable. Then test a role that should be able to view the log but does not necessarily need access to bulk operations. Bulk balance management tools should never be left available to a wide range of admin users.

Multisite and Multiple Campaigns

If WordPress runs in multisite mode, verify where the myCred log is stored and which site holds the balance. The myCred documentation describes storage differences between a standard installation and multisite with or without central logging. In practical terms, that means one simple thing for the administrator: test the campaign on the exact site in the network where it will run, not on a neighboring site with similar settings.

When you have multiple campaigns, do not use the same test page as a universal showcase. Each campaign may have its own type, goal, shortcode, widget, and conditions. Create a small table in the project documentation with the campaign name, point type, public page, owner, progress check, and launch status. That reduces the risk of a new administrator enabling the points-based scenario in the wrong place.

Also test how the campaign behaves after a theme change, a cache plugin update, or a permalink structure change. Those actions are not directly related to myCred Gateway WPMU DEV Fundraising, but they do change the form environment and can affect submission, redirects, shortcode blocks, and progress bar rendering. For a stable launch, make it routine to repeat a short test after every major site change: one user, one point contribution, one log review, and one comparison between the public result and the admin area.

If the site is managed by a team, assign a process owner. This is the person who knows where the campaign is enabled, which point type is used, how to find the log entry, and when to temporarily disable the points-based participation method. Without that owner, a small issue turns into a chain of handoffs between the administrator, content manager, and developer. The process owner does not have to be a programmer, but they do need to be able to reproduce the test and document the result in clear language. It is also useful to keep, next to the process rules, a link to the test page, the name of the test user, and the control scenario the team repeats before every public campaign change, including routine checks after updates.

Why Point-Based Donations Fail and How to Find the Cause

Troubleshooting is most effective when you treat it as a chain rather than a list of random actions. First, check whether the user can see the form and the points option. Then check whether the submission goes through. Next, compare the balance and the log. Finally, verify whether the campaign updated. That sequence quickly shows where the flow actually breaks.

The Points Option Does Not Appear in the Form

Symptom: the campaign opens, but the user sees only standard participation options or does not see the myCred method at all. Possible causes include: the gateway plugin is not active, the base Fundraising plugin is not detected, the selected campaign type does not support the points-based flow, the user is not logged in, the balance is too low, or the theme template hides part of the form.

Check the active plugins, the user's role, the balance, and the campaign settings. Then temporarily switch to a default WordPress theme on a staging site or disable aggressive script optimization. If the option appears only when the balance is high enough, that may be expected behavior rather than an error. In that case, add a note on the page explaining the minimum number of points required.

The Balance Is Not Deducted After Submission

Symptom: the user sees a confirmation, but the balance stays the same. First, check the myCred log. If there is no entry, the action never reached the points system or was rejected. If there is an entry but the balance did not change, check the point type: the shortcode may be showing one type while the deduction was applied to another type that is not displayed on the page.

The fix depends on the cause. If the wrong point type is being used, adjust the form or use the correct balance display shortcode. If there is no entry at all, check whether the form submission is being blocked by scripts, cache, or a security plugin. If the problem appeared after an update, compare the behavior on a staging copy with nonessential plugins disabled.

The Campaign Does Not Update Its Progress

Symptom: the balance was deducted, but the progress bar, amount, or participant list does not change. At that point, myCred has already done its part, so look at the Fundraising side. Check the campaign type, goal rules, page cache, progress widget, and the donation record in the admin area. If the progress is cached, the user may continue seeing the old state even after a successful action.

To verify this, open the campaign in the admin area and compare the data with the public page. If the admin area updated but the front end did not, the cause is almost certainly cache or the template. If the admin area also did not update, verify whether the selected points-based flow is compatible with that campaign type.

The User Sees an Insufficient Balance Error

Symptom: the form reports that there are not enough points, even though the user believes otherwise. Check which balance they are looking at. On sites with multiple point types, one balance is often displayed while the gateway tries to deduct another. Also check decimal formatting and rounding if the amount is entered manually.

Fix the text next to the form so it clearly states which point type the campaign uses. If the site uses multiple point currencies, do not give them identical names. The user should be able to tell the difference between, for example, "reputation" and "support coins."

PHP Warnings or Style Conflicts Appear After Activation

These symptoms are not always caused only by the gateway plugin. At the intersection of older fundraising components, the theme, and newer PHP versions, warnings can appear, and the form's front-end styles may inherit unexpected theme rules. Check the error log, temporarily disable minification, compare behavior under a default theme, and make sure the base plugins are updated as far as your setup allows.

Quick Troubleshooting Route

Where the symptom appears	What to check first	When to roll back the setting
Form	Login status, gateway activation, campaign type, template.	If the points option disappears for all users.
Balance	Point type, exclusions, log, balance shortcode.	If deductions are coming from the wrong point type.
Campaign	Goal, progress bar, cache, donation record.	If progress does not match the myCred log.
Styles and scripts	Theme, optimization, cache, browser console.	If the form becomes inaccessible or the button stops submitting data.

When myCred Gateway WPMU DEV Fundraising Is the Right Choice

This plugin makes sense when three conditions are already in place: working WPMU DEV Fundraising campaigns, a meaningful myCred points system, and an audience that understands why they would spend or receive points. In that context, myCred Gateway WPMU DEV Fundraising adds a useful bridge between user engagement and on-site fundraising.

If you are only starting to build a donation system, are not tied to WPMU DEV Fundraising, and do not use myCred, compare more modern donation plugins first. They may get you to money donations, reporting, and forms faster. A points gateway makes sense when the points-based flow is part of the product, the community, or the site's internal economy.

Before going public, run through a short checklist: you have a backup, the test campaign passed, the balance was deducted correctly, the myCred log is clear, the progress bar updated, the cache is not showing someone else's data, and the user has been told which point type is used. Once that is confirmed, you can get the myCred Gateway WPMU DEV Fundraising file and move on to a safe setup on your own site.