GamiPress Points Payouts - WordPress Plugin

How to Set Up GamiPress Points Payouts to Convert Points into Cash

GamiPress Points Payouts is not meant for standard point awards. It is built for a more accountable workflow: a user has accumulated points in GamiPress and wants to submit a payout request based on a predefined conversion rate. In this guide, we will walk through how to prepare your points economy, enable payouts for the right point type, configure the conversion rate and limits, set up the history page and request form, and handle payouts manually from the WordPress admin panel.

The main challenge here is not installing the add-on. It is controlling the logic: how many points can be withdrawn, how the user specifies a payment method, where administrators review requests, when points are restored after a refund, and how not to confuse Points Payouts with buying points, exchanging points, or using points to pay for orders. That is why this guide is structured as a practical walkthrough rather than a rewritten product page.

Along the way, you will find result checks, a sample implementation for a community website, usage ideas for different project types, a troubleshooting section, and a comparison with related solutions. If you are only considering payouts, start with the preparation and limitations sections. If the add-on is already installed, jump straight to configuring point types, the request form, and payout history.

What Problem This Add-on Solves Inside GamiPress

In the default GamiPress model, points act as an internal reward currency: the site awards them for actions, progress, purchases, community participation, or other events, and the user sees their balance. GamiPress Points Payouts adds a withdrawal layer to that model: the administrator enables payouts for a selected point type, sets the conversion rate to currency, and displays a payout request form to the user.

The key idea behind this product is not automatic money transfers, but a controlled payout request workflow. According to the official documentation, the administrator can view request history, reject a request, mark it as paid, or refund a paid request and restore the user's points. That is important to understand before launch: the financial action itself, payment details verification, and the actual money transfer remain the responsibility of the site owner and whatever payment process they choose.

Points Payouts fits best on sites where points already have clear value. For example, authors may earn points for publishing, community members for activity, partners for useful actions, and the site owner may want to let them convert part of that accumulated balance into a payout. For a store or learning platform, this can work as a motivational layer, but it has to be financially thought through: the payout rate, minimum amount, maximum amount, and manual review are not minor details here. They are the foundation of operational safety.

At the same time, this add-on does not replace a WooCommerce payment gateway, an affiliate commission system, a banking service, or an accounting module. It works inside GamiPress and specifically manages point payout requests. If you need points to be spent during checkout, look at WooCommerce Points Gateway or Partial Payments. If users need to buy points, that is a different GamiPress branch. If you need to exchange one point type for another, that is what Points Exchanges is for.

Who This Setup Is a Good Fit For

GamiPress Points Payouts makes sense where the site already awards points fairly and the owner is prepared to manually control withdrawals. Good candidates include private communities, educational portals, content sites that reward authors, task-based websites, clubs, local loyalty programs, and projects where points are awarded for verifiable participation.

The add-on is especially useful when you want to separate motivation from finance. The user gets a clear payout form, but the administrator stays in control: the request goes into history, the payout amount is calculated using the configured rate, the status changes only after review, and any disputed payout can be rejected or reversed.

When Points Payouts Is Probably Not the Right Starting Point

If your site does not have transparent rules for awarding points, launching payouts can create conflict very quickly. Users will start treating points as cash, while the administrator will have no clear way to explain why a request was rejected or why a balance changed. The product may also be a poor fit if you need fully automated withdrawals through payment gateways, multi-level financial reporting, tax documents, or a complex affiliate model with commissions and holding periods.

Before enabling payouts, define one simple rule for yourself: what actions earn points, when those points can be revoked, and what minimum balance is required before withdrawal. Without that, even a correctly configured form will generate unnecessary support work.

What to Check Before Installing and Enabling Payouts

Preparation for GamiPress Points Payouts does not start with the Upload Plugin button. It starts with reviewing your existing GamiPress setup. The add-on depends on GamiPress point types, shortcodes, blocks, widgets, and admin screens, so first make sure the core plugin is installed, active, and correctly awarding points to the intended users.

The first thing to review is the point type. In GamiPress, you can create multiple wallets, such as Credits, Gems, or Coins. For payouts, this is more than just a label: each point type can have its own rate, its own limits, and its own eligibility logic. If your site has one type of points for status and another with monetary value, enable payouts only for the second one. Do not make payouts automatically available for every point type until you clearly understand the economics behind each wallet.

The second thing to review is your point-awarding logic. If points are granted for actions that can be easily abused, tighten the rules, moderation, or trigger events first. Points Payouts should not become a way to monetize random points earned through test actions, bulk comments, or misconfigured integrations.

Pre-Install Checklist

• Make sure the core GamiPress plugin is active and your point types have already been created.
• Verify that a test user's balance changes as expected after both awarding and deducting points.
• Decide which point types can be cashed out and which should remain limited to ranks, badges, or feature access.
• Prepare the payout rules text: minimum amount, review period, allowed payment method, and possible rejection reasons.
• Review administrator and editor roles: access to financial requests should be limited to the people who actually process payouts.
• Set up WordPress email delivery through a reliable mail method if you plan to rely on new request notifications.

How to Choose a Rate Before the First Request

The Points Payouts documentation shows a simple model: the administrator defines how many points equal one unit of currency, and the request amount is calculated from that ratio. In the example where 100 points equal 1 currency unit, a request for 1,000 points becomes 10 currency units. In a real project, the rate should be based on site economics, not on what looks nice on the form.

Start by estimating how many points an average user can realistically earn through normal activity. Then calculate how many payouts the site can sustain without strain. After that, set a minimum withdrawal high enough to avoid wasting admin time on micro-requests, and a maximum amount low enough that large requests cannot bypass manual review. For most launches, it is wiser to start with stricter limits, test for a month, and only then relax the rules if needed.

Installation and the First WordPress Check

GamiPress Points Payouts is an add-on for GamiPress. The installation flow is the same as for other WordPress plugins: open the admin panel, go to Plugins, choose Add New, upload the ZIP archive through Upload Plugin, then install and activate it. There is no need to build authentication into the project or modify WordPress core files.

After activation, do not start with the public form. First check that the new settings appear in the admin area. The documentation states that the general Points Payout settings are available under GamiPress -> Settings -> Add-ons, while payout settings for a specific point type appear on that point type's edit screen. These are two separate layers: the global add-on settings control history, currency formatting, and the payment method label, while the point type screen controls payout permission, the conversion rate, and request limits.

Quick Check After Activation

1. Open GamiPress and confirm that your existing point types appear without errors.
2. Edit a test point type and look for the Points Payouts settings metabox.
3. Go to GamiPress -> Settings -> Add-ons and find the general Points Payout settings.
4. Check whether the payout history page exists and whether the add-on created it automatically during installation.
5. Create or select a test user with a non-zero balance so you can validate the payout form later.

If the add-on settings are not there at this stage, do not move on to building the form. First confirm that the core GamiPress plugin is active, the add-on ZIP was installed correctly, there is no critical error in the WordPress log, and the relevant screen is not hidden by the permissions of the current admin role.

Configuring the Rate, Minimum Amount, and Maximum Withdrawal

The most important part of the setup does not live only in the global add-on settings. It also lives on each point type screen. There you will see a dedicated block where you can enable payouts, define the exchange rate, and set the minimum or maximum amount for a single request. This approach is practical: one point type can be used for cash payouts, while another can remain limited to badges, levels, or access control.

Enabling Payouts for a Specific Point Type

The Allow Points Payout setting enables payout requests specifically for this point type. If it is turned off, users can keep earning points, but the payout form should not accept that type as available for cash conversion. This is a good way to separate status-style points from points that carry financial value.

Enable payouts only after validating how points are awarded. If points are granted automatically through WooCommerce, an LMS, a forum, or a community system, test how they are awarded and deducted first. Any mistake in point awards becomes more serious once payouts are enabled: the user is no longer just seeing an inflated balance, but a potentially withdrawable amount.

Exchange Rate

The Exchange Conversion setting defines the relationship between points and currency. The documentation gives an example where 100 points equal 1 currency unit and 1,000 points produce an amount of 10. The setting is easy to understand, but the implications are significant: the rate determines how your site translates internal activity into real monetary value.

Do not pick a rate just because it looks neat on the form. Review how many points a user can earn in a normal week, how many active users could submit a request at the same time, and how much time administrators will spend reviewing them. For an initial rollout, a rate that discourages overly frequent small payouts is usually the safer choice.

Minimum and Maximum Amount

The minimum limit protects the administrator from micro-requests. If you leave it at zero, the restriction does not apply. That is useful for testing, but on a live site it is usually better to set a floor. The maximum limit caps the size of a single request; a value of zero means there is no upper boundary. On a site with cash payouts, having no maximum can be risky, especially when point awards depend on automated actions.

Start with clear boundaries: the minimum should be realistically reachable for an active user, and the maximum should be low enough that large balances are processed through multiple reviewable requests or a separate approval path. If your payout rules are published on the site, keep those rules aligned with these settings so users do not see one promise in the text and a different behavior in the form.

Initial Settings Table

This table helps you quickly see what to verify after enabling payouts for a point type.

After saving the settings, do not stop at visually checking the form. Verify the cash calculation, the request status, the user's balance, and the history entry. That full chain, "settings -> request -> history -> status," is what shows that GamiPress Points Payouts is working properly.

The Payout Form, Payout History, and Front-End Widgets

Users interact with the add-on through the payout request form and their request history. The documentation lists two key shortcodes: [gamipress_points_payout] for the payout form and [gamipress_points_payout_history] for the history. The add-on also supports blocks and widgets, so the form can be embedded on a page, in a post, or in a theme sidebar.

Where to Place the Form

The best place for the form is not a random post, but a dedicated utility page inside the user's account area, member profile, or rewards section. The user should understand the context: how many points they have, what payout rules apply, which payment method they need to provide, and where to check the status afterward. If the form appears without explanation, some requests will be incorrect: users will submit incomplete payment details, confuse point types, or request amounts the administrator will reject anyway.

A practical setup is a single "Cash Out Points" page with three blocks: a short rules summary, the [gamipress_points_payout] form, and a link to payout history. If your theme supports the block editor, use a shortcode block or the add-on's official block. If the site uses the classic editor, paste the shortcode directly into the page content.

How to Use the History Page

In the general Points Payout settings, the Points Payout History Page option specifies the page where the current user can view their request history and details. The documentation also notes that the add-on may automatically create a page titled Points Payout History with the [gamipress_points_payout_history] shortcode in its content during installation.

Do not leave that page unchecked. Open it as a regular user, make sure it shows only that user's requests rather than internal admin data, and add a clear link from the payout form to the history page. If your site has an account dashboard, place the link in the account menu or profile navigation.

Payment Method Label

The global Payment method text option controls the label of the field where the user enters how they want to receive the money. By default, it uses Payment Method, but the documentation gives examples such as PayPal Email, Payment Email, or Bank account. For a Russian-language site, it is usually better not to leave that label abstract, but to state exactly what is required: a PayPal address, a payout email, banking details, or another agreed payment channel.

If you accept only one payout method, do not make the user guess. Rename the label and add a short instruction next to it on the page. If you support multiple methods, explain the expected input format and warn users that incomplete details may lead to rejection.

Currency Format

In the add-on settings, you can define the currency, symbol position, thousands separator, decimal separator, and number of decimal places. These options do not change the business logic behind point awards, but they do affect how trustworthy the calculation looks to the user. If your site serves a Russian-speaking audience, check how the amount appears in the form, in history, and in the admin area: make sure periods and commas are not reversed, no unnecessary fractional values appear, and the currency does not look like a placeholder test format.

Result check: create a request for a test amount, then open it both in the user's history and in the admin history. The monetary amount should look equally clear and consistent in both places.

How the Administrator Processes Payout Requests

After the form is submitted, the request appears on the admin screen at GamiPress -> Points Payout History. There you can see the request number, user, point amount, cash amount based on the configured rate, status, date, and available actions. This is the administrator's working hub: it is where you can see which requests are waiting for review, which are already marked as paid, which were rejected, and which need to be refunded.

Statuses and Actions

In the request details, the administrator can see the user, point amount, cash amount, status, and date. The documentation describes actions based on the current status: when a request is awaiting processing, it can be rejected or marked as paid; when a request has already been paid, it can be refunded and the user's points will be restored.

This logic helps you avoid breaking balances manually. If a request is invalid, rejecting it is usually better than manually adjusting the balance somewhere else. If a payout was marked as paid and later needs to be reversed, use the refund action because it is tied to restoring points. Manual balance edits should be reserved for rare administrative exceptions, with the reason documented separately.

Request Review Process

What to Verify Before the Actual Payment

1. Open the request in Points Payout History and verify the user, point amount, and cash equivalent.
2. Compare the amount with your site rules: minimum threshold, maximum threshold, and allowed payout method.
3. Review the payment method field and make sure the payment details are complete and belong to the user.
4. If needed, inspect the user's recent GamiPress award history to rule out test points or incorrect awards.
5. Send the actual payout outside WordPress using whatever method your site uses.
6. After confirmation, mark the request as paid or reject it with an internal note in your support system.

How to Keep the Request Linked to the Real Payment

Points Payouts should not be your only source of financial control if the site handles real money. Keep a separate internal payout record, especially if multiple administrators are involved. That can be a spreadsheet, a CRM, an accounting service, or a support ticket. The important part is making sure the GamiPress status always matches the real-world payment action.

Notifications for New Requests

In the Points Payouts email settings, there is a block called Points Payouts: New payout request email. There you can disable new request emails, change the subject line, and edit the email content. The subject field supports the same tags as the message body, so you can make the notification more informative for the administrator.

If payouts are processed manually, the notification should usually stay enabled, but you should not rely on it alone. WordPress email can be delayed or land in spam, especially without proper SMTP setup. Make checking the Points Payout History screen part of the routine admin workflow, and treat the email as an extra signal rather than the only trigger.

Practical Example: A Payout Page for an Author Community

Imagine a site where authors earn points for published content and verified participation. The owner wants to allow payouts only for Credits, show the form inside the member area, and review requests manually after checking publication quality. This is a typical GamiPress Points Payouts use case: there is an accumulated balance, a clear rate, a public form, and admin review.

Goal

The goal is to create a working page where an author can see the rules, submit a Credits payout request, enter a payout email, and then track the status in history. The administrator should see the request in Points Payout History, verify the payment details, and mark it as paid only after the actual transfer has been completed.

Preparation

• A point type named Credits has already been created in GamiPress.
• The test author has a balance above the minimum threshold.
• The rules for awarding Credits have been reviewed and do not issue points for random actions.
• The administrator has already decided on the exchange rate and per-request limits.
• The site has either a member dashboard page or a dedicated page for point withdrawals.

Setup Steps

1. Open the Credits point type and enable Allow Points Payout.
2. Set the rate in Exchange Conversion. Immediately verify the math using a simple test amount so all administrators interpret the formula the same way.
3. Fill in Minimum Amount and Maximum Amount. The minimum protects you from tiny requests, and the maximum prevents oversized payouts from slipping through without separate review.
4. In GamiPress -> Settings -> Add-ons, select the payout history page and configure the currency format.
5. Change Payment method text so the author clearly understands which email or payment detail to provide.
6. Create a "Cash Out Points" page and insert the form using [gamipress_points_payout].
7. Place [gamipress_points_payout_history] on the history page or verify the page that was created automatically.
8. Log in as the test author, submit a request, and then open the admin Points Payout History screen.

Result Check

After the request is submitted, the user should see it in their history and the administrator should see it in the admin list. The cash amount should match the configured rate, the status should show that the request is waiting for processing, and the payment method field should contain clear, usable information. After marking the request as paid, verify that the status changes. If you use the refund action for a paid request, confirm that the user's points are restored.

The Detail That Often Breaks the First Test

If the form is visible but the request will not submit, or the amount keeps failing validation, do not start by blaming the WordPress theme. Check the point type settings first. Payouts must be enabled for the exact point type the user is selecting, and the amount must fall between the minimum and maximum thresholds. The second common source of confusion is that the user is testing the form without having a sufficient balance.

Practical Ways to Use Points Payouts on Different Types of Sites

Point payouts only make sense when users understand what they are being rewarded for and administrators can verify the basis for payment. What follows is not a generic list of "places it might be useful," but a set of scenarios built around the add-on's confirmed features: cashing out a selected point type, using a rate, setting limits, displaying a form, maintaining history, and manually processing statuses.

Author Community

Authors earn Credits for published content, editorial support, or approved revisions. Points Payouts displays the payout form, and the administrator reviews whether there are any disputed awards before sending payment. In this scenario, the minimum threshold matters especially much: it reduces the volume of small requests and gives editors time to review the quality of the work.

The expected result is a clear path from contribution to payout request, without the editorial team managing payouts manually through email threads. Verification is straightforward: a test author should be able to submit a request, see it in history, and the administrator should be able to find it in the global list.

Learning Platform

On an educational website, points may be awarded for completing lessons, participating in discussions, or helping other learners. Payouts are usually better enabled not for every point type, but for a separate one that reflects verified contribution. That way, status points, badges, and progress remain motivational, while only a controlled wallet carries cash value.

The result check here should include user roles. A regular participant should see the form and their own history, the administrator should see all requests, and a teacher or editor should not have access to the financial screen unless that is part of their job.

Club or Private Community

In a club, points can be awarded for useful actions such as attending events, helping newcomers, moderating, or contributing expert material. Points Payouts helps turn those points into a controlled reward request, but the rules need to be published in advance. If members do not understand why some points can be withdrawn and others cannot, support requests will pile up quickly.

For this type of site, it helps to create a "Point Rules and Payouts" page: explain the conditions at the top, place the form underneath, and add a history link below that. This reduces invalid requests and makes the process more transparent.

Partner Tasks Without a Full Affiliate System

If the site awards points for simple, verifiable partner tasks, Points Payouts can cover the basic payout request workflow. But if you need commissions, holding periods, multi-level partner relationships, automated payouts, and tax documents, this add-on will not be enough. In that case, a specialized affiliate system is the better fit, while GamiPress can remain your on-site motivation layer.

Result Validation, Process Safety, and a Careful Visual Tweak

After configuration, it is important to test the entire path, not just whether the form appears. A working result looks like this: a user with a sufficient balance can submit a request, the amount is calculated based on the rate, the request appears in the user's history, the administrator sees it in Points Payout History, the status changes after admin action, and points are restored if the request is refunded. If any link in that chain is broken, it is better to delay launching for a live audience.

Final Test Before Publishing the Page

Test as a Regular User

1. Create a test user with a normal role, not an administrator account.
2. Award that user enough points of the selected type.
3. Open the form page while logged in as that user and submit a request for an amount within the limits.
4. Check the user history through [gamipress_points_payout_history].
5. Open the admin history and compare the user, points, amount, payment method, and status.
6. Mark the test request as paid, then optionally validate the refund scenario using a separate test request.
7. Check the new request email if notifications are enabled.

What Counts as a Successful Test

Do not run your first test using a real user and a real payout. A test request should be clearly recognizable to every administrator so it does not get processed as a genuine payment. If multiple people are responsible for payouts, agree in advance on how test requests will be labeled.

Compatibility with the Theme, Cache, and Editor

The form and history are displayed on the public side of the site, so they are affected by the theme, editor, container CSS, widgets, and caching. If the page is built with a page builder, first place the shortcode in a plain text or shortcode block and test it without extra animations. If the site uses aggressive script optimization, exclude the payout page from questionable optimizations only when there is an actual conflict, not preemptively.

Caching requires special care for account pages and financial forms. A page with personal history must show the current user's data. If the site uses full-page caching for logged-in users, verify that history does not leak or mix between accounts. If there is any doubt, exclude both the form page and the history page from caching at the cache plugin level.

A Safe CSS Tweak for the Form Without Editing the Plugin

If you want to visually separate the payout form from the rest of the content, do not edit GamiPress or add-on files. Wrap the shortcode in your own container on the page and add CSS through Appearance -> Customize -> Additional CSS or through a child theme. This is a safe presentation-layer change: it does not depend on internal PHP hooks and is easy to roll back.

<div class="points-payout-box">
  [gamipress_points_payout]
</div>

.points-payout-box {
  border: 1px solid #d7dee8;
  border-radius: 8px;
  padding: 24px;
  background: #ffffff;
}

.points-payout-box input,
.points-payout-box select,
.points-payout-box textarea {
  max-width: 100%;
}

After adding the CSS, open the page on a desktop screen and at mobile width. Fields should stay inside the container, the button should remain visible, and form messages should not blend into the background. To roll the change back, remove the container or the CSS block. This change affects only the page layout, not point calculations, request statuses, or the financial logic.

If the Payout Form or Payout History Is Not Working Correctly

Troubleshooting GamiPress Points Payouts should follow the actual chain: point type, form, user balance, limits, history, admin status, email. If you start with the theme or cache, you may waste time on a surface-level symptom and miss the real configuration problem.

The Form Is Visible, but the User Cannot Submit a Request

Symptom: the page opens, but the request fails, the point type is unavailable, or the amount is rejected. A likely cause is that payouts are not enabled for the selected point type, the user's balance is below the requested amount, the amount falls outside the minimum or maximum limit, or the user is testing the wrong point type.

Check the point type edit screen: is Allow Points Payout enabled, and are the rate and limits configured correctly? Then review the specific user's balance. If the issue appeared after changing the rules, temporarily restore the previous limits and repeat the test with a separate request.

The Cash Amount Looks Wrong

Symptom: the user expects one amount, but the form or history shows another. In most cases, the cause is either a misunderstanding of Exchange Conversion or a currency formatting issue. Test the rate using a simple amount such as 100, 1,000, or another easy value, and recalculate the result manually.

If the calculation is correct but looks odd, open the global add-on settings and review the currency, symbol position, separators, and number of decimal places. Do not change the rate if the problem is only in the way the currency is displayed.

The Request History Does Not Show the User's Data

Symptom: the user submitted a request but does not see it on the history page. Check that the history page contains [gamipress_points_payout_history], and that the correct Points Payout History Page is selected in the Points Payout settings. If the page was created automatically, make sure it is published and accessible to the current user role.

If the site caches pages for logged-in users, temporarily disable caching for the history page and repeat the test. Payout history is a personal area, so caching here must be configured carefully.

The Administrator Does Not Receive a New Request Email

Symptom: the request appears in the admin history, but the email never arrives. First check the Points Payouts: New payout request email block: confirm that emails are not disabled and that the subject and content are filled in. Then check general WordPress email delivery using a test email or an SMTP plugin.

If email delivery is unreliable, do not postpone request processing until mail is fixed. Make manual review of Points Payout History a regular admin task, and handle email delivery separately.

A Paid Request Needs to Be Reversed

Symptom: the request has already been marked as paid, but the payout now needs to be reversed or corrected. The documentation describes a refund action for paid requests that restores the user's points. Use that built-in action instead of manually re-awarding points somewhere else, so the status history remains easy to understand.

If the reversal is caused by an error in the real payment made outside WordPress, document that first in your internal payout system, then update the request status. That way, administrators will not lose the connection between the actual transfer and the GamiPress record.

When GamiPress Points Payouts Is the Right Choice

GamiPress Points Payouts is a strong fit when your site already has a well-designed points system, clear earning rules, and a team that is ready to manually review payout requests. The add-on handles the chain of "points -> request -> history -> admin status" well, but it does not remove the site owner's responsibility for payout rules, payment details, actual transfers, or user support.

Before launching for a real audience, run the full test: configure a separate point type, enable payouts, define the rate and limits, place the form, verify the history page, process a test request, and make sure the administrator understands every status. If that path works without confusion, you can get the WordPress version and roll out the add-on on a live site step by step.

The safest way to start is to limit payouts to one point type, set sensible thresholds, and publish the rules next to the form. After the first few requests, it will become clear where users need more explanation, which amounts they request most often, and whether you need to adjust the payment method wording, the rate, or the administrative process.