GamiPress EDD Points Gateway - WordPress Plugin

Guide to Setting Up GamiPress EDD Points Gateway for an Easy Digital Downloads Store

GamiPress EDD Points Gateway is built for WordPress sites where GamiPress points are already part of the user incentive system and the Easy Digital Downloads store sells digital products. This guide does not rehash the product listing. Instead, it walks through how to prepare your points system, enable points-based payments in EDD, choose a clear conversion rate, verify the order flow, and avoid breaking your regular payment methods.

This article is intended for a digital store owner, a WordPress administrator, or a developer setting up the GamiPress and Easy Digital Downloads integration on a live site. It covers preparation, installation, detailed configuration, a practical use case, result verification, troubleshooting, FAQ, and a comparison with similar solutions.

The core idea is simple: a user first earns points in GamiPress, then uses an eligible points type as a payment method when buying a digital product. But a working setup depends on the details: which points types already exist, how EDD displays active gateways, whether you need full payment in points or partial redemption, how the store records orders, and how the administrator confirms that the balance actually changed.

This guide intentionally does not include instructions for buying a license, obtaining a paid version, or bypassing activation. It focuses only on configuring a product you already have, testing it safely, and deciding whether the add-on fits your use case.

What Problem a Points Payment Gateway Solves

In a standard Easy Digital Downloads store, the buyer chooses one of the available payment methods, such as the built-in test gateway, PayPal, Stripe, or another connected method. GamiPress EDD Points Gateway adds a different type of payment method - paying with a points type from GamiPress. For the user, it appears as an option at checkout. For the administrator, it is configured within the same EDD gateway logic as the other payment methods.

This approach is not useful for every store. It works especially well where points already have real value inside the product ecosystem: an education platform sells PDFs, templates, or mini-courses; a private community gives out digital materials in exchange for activity; a creator site lets users trade participation, reviews, or completed tasks for downloads; or a digital asset marketplace wants to give returning users a true alternative payment method instead of just a discount.

The key difference from a coupon is that the gateway works as a payment method, not as a promo code. The user does not enter a discount code or try to calculate the deduction manually. They choose a payment method at checkout, and the system converts the order price into the required number of points based on the configured rate.

What Happens in the GamiPress and EDD Integration

The integration has three layers. The first layer is GamiPress, where points types are created, for example credits, coins, gems, or whatever naming convention the site uses. The second layer is Easy Digital Downloads, which handles digital products, the cart, checkout, payment settings, and order records. The third layer is the add-on itself, which registers selected points types as payment gateways inside EDD.

As a result, the administrator is not managing an abstract "site currency" but a specific points type. If GamiPress has several points types, each one needs to be evaluated separately: is it appropriate for purchases, is it too easy to earn, does it need its own conversion rate, and should it be shown to all users at checkout.

How the Gateway Differs from Partial Payments

In the GamiPress documentation for EDD Points Gateway, the difference between Points Gateway and Partial Payments is called out separately. This is an important fork in the setup. The gateway is intended as a full payment method for an order paid with points. Partial Payments is meant for a different scenario, where points cover only part of the purchase and the remaining balance is paid another way.

The practical takeaway is this: if the store wants users to pay for the entire order with points, use GamiPress EDD Points Gateway. If you need to let users cover part of the total with points and pay the rest with money, look at the separate add-on for partial payments. Do not mix those expectations in the same flow. Otherwise, users will treat points like a discount, while the administrator will be testing the gateway as if it were a standard payment method.

Who GamiPress EDD Points Gateway Is For, and When Another Approach Is Better

This product should be viewed not as a universal loyalty program, but as a bridge between an existing gamification system and digital sales. If the site does not already have a meaningful way for users to earn points, enabling the gateway will not create loyalty on its own. Users need to understand how they earn points, where they can see their balance, and why that balance matters.

A good use case starts with a clear points economy. For example, a user earns credits for completing lessons, publishing useful materials, participating in a private club, or buying other digital products. They can then spend those credits on a small template, file, guide, icon pack, mini-course, or internal digital bonus.

Good Fit Scenarios

• An educational site where points encourage lesson completion and the EDD store sells extra materials.
• A community around digital products where active members get access to downloads without a separate cash payment.
• A store selling templates, presets, PDFs, or code where returning customers need a clear way to spend accumulated points.
• An internal bonus system where points are not converted into cash but are used as a closed on-site currency.

When the Add-on May Not Be the Right Fit

GamiPress EDD Points Gateway should not be the first plugin you install in an empty loyalty system. If you have not yet decided what actions should earn points, how much one point is worth, and how the balance is presented to users, start with the core GamiPress setup. Otherwise, checkout becomes the first place where the user learns about points, without understanding what they actually mean.

The add-on may also be unnecessary if what you really need is a coupon, an achievement-based discount, a referral program, or partial payment. For those use cases, the GamiPress and EDD ecosystem includes other solutions: discounts, points per purchase total, partial payments, or separate loyalty plugins. The gateway is useful when a points type should function as a payment method.

What to Check Before Installation

Before installing the add-on, do not just run through a formal checklist. Think in terms of a dependency chain. GamiPress EDD Points Gateway sits at the intersection of the user balance, the EDD cart, and payment settings, so a problem in any one of those layers can look like "the gateway did not appear" or "the points were not deducted."

Core Dependencies

The site should have WordPress, GamiPress, and Easy Digital Downloads installed and active. In GamiPress, there should be at least one points type you are willing to use for purchases. In EDD, checkout should already work, the checkout page should be configured, and there should be at least one test digital product you can use to verify the purchase flow without risking real customer orders.

In EDD, the payment settings are available in the admin area under Downloads -> Settings -> Payments. This is where EDD displays active gateways, the default gateway, test mode, and other payment flow settings. If the basic EDD checkout does not work with a test gateway, fix EDD first and only then move on to points-based payments.

Your Points Economy Before Enabling the Gateway

Before turning on points payments, answer three questions. First, which points type will become the payment method? Second, what conversion rate will be clear to users? Third, how will users see their balance before reaching checkout? If points are awarded too generously, your digital products may lose perceived value. If the conversion rate is too complex, buyers will wonder why one file costs exactly that many points.

For the first rollout, choose one points type and one small test product. Do not enable multiple points types across the whole catalog right away. A safe strategy is to start with a limited scenario, verify that the points are deducted correctly, and only then expand availability.

Test Environment and Rollback Plan

EDD supports test mode, which lets you verify the payment flow without a real transaction. This is especially useful for a points-based gateway: you can create a test user, manually award points in GamiPress, place a test order, and see how the balance, order details, and receipt page message change.

Before enabling it on a live site, test the scenario on a store copy or at least in EDD test mode. The rollback path should be simple: disable the gateway in EDD payment settings, restore the regular default gateway, and manually correct the test user balance if the check did not go as planned.

Installation and Initial Activation

Technically, installation looks like any other WordPress plugin add-on: upload the file through Plugins -> Add New -> Upload Plugin, then activate it. But after activation, what matters most is not the plugin row in the list. It is whether the points-based payment method appears in the EDD payment area.

Do not start by placing a real order. First confirm that GamiPress recognizes the correct points type, EDD recognizes the new gateway, and the test account role can complete checkout. If the site uses caching, JavaScript optimization, a custom checkout theme, or checkout blocks, test on the public checkout page itself, not just in the admin area.

Initial Verification Order

1. Make sure GamiPress is active and that a points type with a clear slug has been created in the GamiPress menu.
2. Confirm that Easy Digital Downloads is showing working store, cart, and checkout pages.
3. Activate GamiPress EDD Points Gateway in the WordPress plugins section.
4. Open Downloads -> Settings -> Payments and find the new payment gateway tied to the points type.
5. Enable only the gateway you plan to test first, then save the settings.
6. Create or select a test user, then give that user a sufficient balance of the chosen points type.

Signs That the Add-on Connected Properly

In the EDD admin area, a payment method based on the selected points type should appear. At checkout, the user should see the option to pay with points if the gateway is enabled and the order meets the conditions for using it. After a test purchase, EDD orders should contain the purchase record, and GamiPress should show either the updated balance or the corresponding earnings/logs entry, depending on how your setup displays that information.

If the gateway does not appear in EDD, do not immediately start reinstalling every plugin. The cause is often simpler: the points type was never created, the add-on is not active, the payment method is not included in active gateways, the checkout page is cached, the user is not logged in, or the test product was added to the cart in a way EDD does not expect.

Configuring the Points Gateway After Installation

This section matters more than the installation itself. GamiPress EDD Points Gateway becomes useful only after you configure the conversion rate, the payment method text, and a test scenario. In the official GamiPress logic for the points gateway, the key setting is the conversion rate between points and the store currency. That setting determines how many points must be spent for one unit of product price.

Choosing the Points Type

If GamiPress includes multiple points types, do not enable all of them automatically. One points type may be an in-game currency, another may represent reputation, and a third may be a rare achievement reward. The best payment option is usually the type that is actually meant to be spent. Reputation points, ranks, and achievements are often better left as status markers rather than payment resources.

Check the singular/plural name and slug of the points type. Users see the names, while the slug is used in internal links, shortcodes, and settings. If the points type name is sloppy or overly technical, checkout will feel less trustworthy. It is better to standardize the name in advance into something clear like "Credits," "Coins," "Stars," or another term already used in the site's interface.

Conversion Rate and the First Round of Math

The conversion rate should be simple. If a product costs 10 currency units and the rate is 100 points for 1 currency unit, the buyer spends 1000 points. That kind of example is easy to explain to users and easy for an administrator to verify. More complicated rates like 37 points for 1 currency unit may look mathematically efficient, but they make checkout harder to understand.

For the first rollout, use a rate that does not require a calculator. Then test it with three products: a low-priced item, a mid-priced item, and an expensive item. In each case, the point total should feel reasonable. If an expensive product becomes almost unattainable, users will stop seeing points as real value. If any product can be purchased after just a couple of simple actions, the system becomes too generous.

Example of a Starting Conversion Strategy

• Small bonus files can be priced so that an active user can afford them after a handful of meaningful actions.
• Core digital products are usually better kept more expensive so the points gateway supports loyalty instead of replacing all revenue.
• Premium items should be tested separately. In some cases, it is better to leave them on regular payment methods or use partial payment through another add-on.

Payment Method Text at Checkout

Users should immediately understand what they are selecting. Do not name the gateway something technical like "GamiPress Points Type Gateway." Use wording that matches the language of your loyalty system instead, such as "Pay with Credits," "Use Coins," or another clear label. On a non-English site, the external wording can be translated through localization tools or string settings if your setup supports that, but exact admin UI labels should still be checked against the actual screen.

A poor label creates support tickets. If the buyer does not understand whether points will cover the full amount, whether they can pay the rest with money, or why they cannot see the gateway, they may abandon the purchase. Add a short explanation near the balance or on the account page showing how many credits are available and where they can be used.

Default Gateway and Payment Method Order

EDD lets you choose a default gateway. For most stores, you should not make the points gateway the default right away. It is usually better to keep the standard money-based gateway as the default and show points as an additional choice. The exception is a private club or internal storefront where every product is intended to be paid for with points from the start.

If a user does not have enough points, they should know what to do next. In a full-gateway setup, it is better either not to show points as the only option or to explain clearly in advance that a sufficient balance is required for purchase. If you need a flexible "part points, part money" flow, that belongs in partial payments, not in a standard points gateway.

Points Economy for a Digital Store

Gateway setup does not end with checking a box in EDD. Once points become a payment method, they start shaping buyer behavior, the perceived value of digital products, and support workload. That means the administrator needs to decide in advance which products can be purchased with points, which actions award points, what limits are needed for expensive items, and how to explain the rules without writing a long legal-style page.

The biggest mistake is treating a points gateway like a free gift to the user. Inside the site, points always have a cost: they were awarded for activity, a purchase, lesson completion, community participation, or a manual admin action. If the conversion rate is disconnected from the real value of those actions, the program quickly becomes either useless or overly generous.

The "Earn and Spend" Link

Before launch, write down two lists on paper or in a document. The first list is how users earn points: purchases, lessons, reviews, comments, achievements, manual rewards. The second list is how they spend them: PDFs, templates, presets, mini-courses, restricted files, bonus downloads. Then connect those lists into one user journey. For example, the user completes three short lessons, earns credits, sees the balance in their account, and uses those credits to pay for a small resource in EDD.

That path works better than an abstract line like "earn points and buy products." Users need a goal they can realistically reach. If one action gives 5 credits but the cheapest download costs 5000 credits, motivation disappears. If one comment gives enough points to buy a core product, the store loses control over value.

Separating Products by Role

Not every download should be opened to points-based payment on day one. A practical approach is to split the catalog into three groups. The first group is low-risk bonuses: checklists, extra PDFs, mini-packs, small templates. The second group is core products you can start testing after a successful launch. The third group is products that are better left on cash payments or handled under separate rules: large bundles, licenses, subscription products, personal services, limited-availability items, or products with high support costs.

If the add-on in your configuration shows the points gateway across all checkout flows, users may add different products to the cart together. That is why you should test more than a single download. Test realistic cart combinations. If the store uses bundles, variable pricing, or discounts, decide in advance how the points gateway should behave against the final total. Do not promise rules you have not tested on the real checkout screen.

A Simple Starting Principle

For the first rollout, choose products where the result is easy to verify. One digital file, one simple price, one points type, one conversion rate, one test user. After the flow works reliably, expand the scenario. This order may not look impressive, but it protects you from a situation where users start buying different products in volume while the administrator still does not understand why the points deduction differs from expectations.

How to Explain the Rules to Users

The rules do not need to be long. A few clear points are enough: which points are used, where to check the balance, whether the order can be paid in full, what happens if the balance is too low, and whether points are returned when an order is refunded. Put those rules near the balance, on the loyalty program page, or in the store FAQ.

Do not hide the conversion rate. If the user sees only the final total at checkout, the deduction may feel opaque. A simple formula in plain language reduces support load: "1 unit of product price equals 100 credits" or "The price in credits is calculated automatically at checkout." Adjust the wording to match the actual capabilities of your interface, but do not leave users guessing.

How to Show the Balance and Prepare the User for Purchase

A weak point in many loyalty programs is that users learn about points too late. If the buyer sees the points gateway only at checkout, they may not understand why the system is offering payment with something it never mentioned before. That is why gateway setup works best when paired with a visible balance on the account page, in the user dashboard, in a widget, or on a page explaining the program rules.

GamiPress provides the [gamipress_points] shortcode to display a user's balance or the site's total points. For this guide, the more useful case is the current user scenario: show each customer how many points they have before they move on to the digital products.

Minimum Balance Block

If the site uses an account page or a dedicated loyalty program page, you can add a simple balance block with a link to the EDD catalog. The shortcode example below should be adjusted to match the slug of your points type:

[gamipress_points type="credits" current_user="yes" thumbnail="yes" label="yes" inline="no"]

After adding it, test the page while logged in as the test user. The balance should match what you see in the GamiPress admin area. If the shortcode does not display the current user, check the current_user attribute and make sure the user is logged in.

What to Write Next to the Balance

You do not need a long promotional description next to the balance. It is enough to explain the mechanic: points can be used at checkout as a payment method if the balance covers the order cost. If the store keeps some products available only through regular payment methods, say that clearly in the rules instead of making users discover the limit during checkout.

A strong user journey: the user sees the balance, understands the conversion rate, chooses a digital product, sees the same points type at checkout, and gets a clear purchase record after the order is complete.

Payment Mechanics: From User Balance to Order Record

To troubleshoot the add-on with confidence, you need to understand the data flow. Points are not an independent banking currency. They are an internal GamiPress balance that the gateway uses as a source of value. EDD, in turn, still records the order, stores the purchase contents, and shows the result in the order details.

Input: What Needs to Be Present Up Front

At the input stage, you have a user account, a balance in the selected points type, a digital EDD product, and an enabled payment gateway. If the user is not logged in, the points scenario can become ambiguous because the balance must be tied to a specific user ID. That is why, for stores that accept points-based payment, it makes sense to require login or automatic registration if that matches the broader EDD setup.

Product Logic: Where the Conversion Happens

The conversion rate turns the order total into a number of points. If the cart total is 10 and the rate is 100 points per 1 currency unit, the user needs 1000 points. It is important to test rounding behavior and how clear the total looks across several products. If the product uses price options, discounts, or taxes, test the real combination, not just the simple price of a single file.

Output: What the User Should See

At checkout, the user should see the points-based payment method and understand the final result. After purchase, they should get the standard EDD outcome: purchase confirmation, access to download links, and a record in purchase history if that area is in use. From the user's perspective, this should not feel like a "magic GamiPress operation," but like a normal digital order paid with points.

Verification: How the Administrator Checks It

The administrator checks two places. In EDD, open Downloads -> Orders and locate the test order. In GamiPress, check the user's balance and earnings/logs. If the EDD order exists but the balance did not change, review the gateway settings and the points type connection. If the balance changed but the order did not complete, look at the order status, checkout JavaScript, theme conflicts, and EDD settings.

Rolling It Out Across the EDD Catalog: Products, Discounts, and Order Statuses

After a successful test with one product, the work gets more nuanced. Easy Digital Downloads is often used not as a simple storefront with a couple of files, but as a full catalog with different downloads, pricing options, bundles, discount codes, customer history, receipts, and multiple payment methods. GamiPress EDD Points Gateway needs to fit into that system without exposing buyers to unexpected rules.

One Product, Multiple Products, and the Cart Total

The gateway operates at checkout, so the final order total matters. On a simple product, the calculation is easy to verify: price multiplied by the points rate. But a cart can contain multiple downloads, and users will expect the system to calculate the full total correctly. Test a cart with two standard products, then with a different price point, then with an insufficient balance. That helps you see in advance where users may need extra explanation or restrictions.

If the store sells bundles or packages, do not assume they are automatically safe for points-based payment. A bundle may have a different support cost structure, update model, and perceived value. In some cases, it is smarter to start with supplementary materials and unlock core bundles later, once your usage data shows how people actually earn and spend points.

Discounts and Coupons Used Alongside Points

EDD supports discounts, and GamiPress includes separate add-ons for achievement-based discounts. So decide in advance whether discount codes should apply to orders paid with points. In some loyalty programs, that is perfectly fine: the discount lowers the total, and the points are deducted from the reduced amount. In other programs, that creates a double benefit the store never intended to offer.

Do not state that "discounts always work" until you have tested that rule on a real checkout screen. Create a discount code, apply it to a test product, choose the points gateway, and see whether the result matches your expectation. If the result is questionable, it is better to document the restriction in your store rules or temporarily avoid combining coupons with points-based payments.

Order Statuses and File Delivery

For a digital product, the buyer judges success not just by whether the points were deducted, but by whether they received access to the file. EDD stores orders and lets the administrator open the order record, inspect the purchase contents, and view the download links. If a points-based purchase does not move the order into a status that unlocks the file, the buyer will treat the purchase as failed even if the balance changed.

That is why your testing should include the receipt page and the actual download link. Open the order in EDD, find the download link, and make sure the test user sees the same result on the public side of the site. If the file is unavailable, first check the download product itself: is the file attached, is access being restricted by another plugin, and is the receipt template still working properly?

Manual Adjustments and Support

Even with a careful setup, support will run into manual edge cases: the user bought the wrong product, the order was canceled, the balance looks wrong, or the administrator awarded points manually. Document the internal process: where to check order details, where to verify user points, who is allowed to adjust balances, and how to record the reason for a manual change.

Do not give every manager unrestricted access to manual points adjustments. Once points become a payment resource, the rights to change them should be handled just as carefully as the rights to manage orders. If several administrators work on the site, agree on a note-taking process: why the balance was changed, which order ID the adjustment relates to, and whether the user needs to be notified.

Practical Example: A Digital Bonus for User Activity

Let us look at a concrete scenario. The site offers educational materials and an EDD store. Users earn credits for completing lessons and commenting on assignments. The administrator wants to let users pay for a small PDF bonus with credits only, so active members can get the resource without making a cash payment.

Goal

The goal is a clear user path: the user sees their credits balance, opens the EDD product, adds it to the cart, selects credits at checkout, and receives a download link after purchase. The administrator should see the order in EDD and the reduced user balance in GamiPress.

Preparation

1. Create the credits points type, or use an existing type that is meant to be spent.
2. Create a test digital product in EDD with a small price and a clear name.
3. Enable EDD test mode if you are testing on a live site or on a copy with real settings.
4. Give the test user a balance larger than the product's calculated cost in credits.
5. Add a balance shortcode to the account page so the user can see their credits before checkout.

Setup Steps

In EDD, open the payment settings and enable the gateway tied to the selected points type. In the gateway settings, enter the text the user will see at checkout and define the conversion rate. For the first test, use a simple rate, for example 100 credits for 1 unit of store currency. Save the settings, clear checkout cache if any is in place, and open the site in a separate browser session while logged in as the test user.

Add the test product to the cart, go to checkout, and choose payment with credits. If the gateway is not visible, check whether the user is logged in, whether the gateway is enabled in active gateways, and whether the balance is sufficient. If the gateway is visible, complete the test purchase and continue to the confirmation page.

Verifying the Result

After a successful purchase, open the EDD order details. There should be an order record showing the selected payment method and the digital product. Then check the test user's balance in GamiPress. It should be reduced by the calculated number of credits. If the site displays the balance through a shortcode, refresh the account page and make sure the user sees the updated balance.

Quick validation summary: the order exists in EDD, the download link works, the GamiPress balance changed, and the user understands why that exact amount was deducted. Only after that kind of verification should you enable the gateway for real users.

A Note on Multiple Products and Discounts

After the basic check, repeat the same scenario with two products in the cart and with an active discount code if your store uses discounts. EDD calculates the order total according to its own cart logic, and the gateway needs to work against that final total. If the result looks unexpected, do not roll the gateway out across the full catalog yet. First decide whether points should apply to discounted products, bundles, variable pricing, and special offers.

Verifying the Result on the Public Side of the Site

Admin verification matters, but users judge the experience on the public-facing side of the site. That is why, after setup, you should walk through the entire flow from the customer perspective: balance page, product page, cart, checkout, receipt page, and purchase history. You cannot consider the setup complete just because the gateway appeared in the admin area.

What the Buyer Should Be Able to See

• The balance of the selected points type before purchase, or at least a clear message at checkout.
• A payment method name without internal technical wording.
• The final cost in points, if your version of the add-on and EDD displays that information.
• Purchase confirmation with a download link after the order is completed.
• An updated balance after the points are deducted.

What the Administrator Should See

Under Downloads -> Orders, there should be a purchase record. EDD keeps order history and lets you open individual orders to review the purchase contents, status, customer, and download links. In GamiPress, the balance change should be traceable. If the site uses blocks or shortcodes for user earnings/logs, those can also serve as an additional way to show the user their accrual and redemption history.

Check refunds separately. If the store refunds a purchase, the administrator should understand what happens to the points: are they returned automatically in your setup, does the balance need to be adjusted manually, or should the process be documented in the store rules? Do not promise automatic point refunds to users until you have tested that on a test order.

Compatibility Settings for Theme, Cache, and Checkout

A payment gateway lives in a sensitive part of the site. Even if the add-on itself is configured correctly, checkout can still break because of caching, JavaScript minification, template overrides, or custom theme blocks. That does not mean GamiPress EDD Points Gateway is broken. It means the integration needs to be tested as a payment flow, not as a normal widget.

Cache and Optimization

Checkout, cart, and the receipt page are best excluded from aggressive caching. That is a general EDD rule, but it matters even more in a points-based flow because the user's balance, available gateways, and order total depend on the current account. If cache serves an old state, the user may see the wrong balance or fail to see an available gateway.

If the gateway disappears after optimization is enabled, or the button to complete the order stops responding, temporarily disable JavaScript minification and bundling for checkout. Then re-enable optimization one module at a time. That approach is faster than reinstalling plugins at random.

Theme and Custom Checkout

Some themes or builders override checkout output. If the standard EDD checkout shows the gateway but your custom page does not, the cause may be the template rather than the add-on. Check the default checkout page, temporarily switch to a safe test theme, or disable custom blocks if you can do that on a staging copy.

Safe Improvement Without Code

For the payment flow, it is better not to add random JavaScript or PHP snippets. Instead, make a safe content improvement: add a balance block to the account page through the official GamiPress shortcode, along with a short explanation of how credits can be used. This is easy to roll back, does not interfere with checkout, and helps users understand the gateway before they buy.

Common Problems and Troubleshooting

Problems with GamiPress EDD Points Gateway usually show up in one of five places: the gateway is not visible, the balance is insufficient or unreadable, the order does not complete, the points are not deducted, or the user does not understand the result. Below is a practical troubleshooting path that starts with the symptom and moves to the actual check.

The Gateway Does Not Appear at Checkout

Symptom: everything seems enabled in the settings, but the user does not see the points payment option at checkout.

Possible causes: the points type was not created or is not connected to the gateway, the gateway is not marked active, the user is not logged in, checkout is cached, the theme outputs a custom payment block, or you are testing the wrong checkout page.

What to check: open Downloads -> Settings -> Payments and review active gateways and the default gateway. Then log in as a test user with a sufficient balance and open checkout in a no-cache state.

How to fix it: enable the gateway, save the settings, clear checkout cache, temporarily disable JavaScript optimization, and test the standard EDD checkout. If the gateway appears after that, restore optimization one setting at a time.

The User Sees the Gateway but Cannot Pay

Symptom: the payment method is visible, but the purchase does not complete or an error message appears saying payment cannot be processed.

Possible causes: not enough points, an incorrect conversion rate, the product price changed after discounts, the user is not authenticated, or the EDD checkout requires fields that were not filled in.

What to check: compare the order total to the user's balance. Calculate the required points manually using the configured rate. Check the required checkout fields, especially if registration or address settings were changed recently.

How to fix it: give the test user a sufficient balance, simplify the conversion rate, disable questionable discounts for testing, and place the order again. If the problem disappears, add the conditions back one by one.

The Order Is Created but the Balance Does Not Change

Symptom: an order appears in EDD, but the user still has the same balance in GamiPress.

Possible causes: the order did not reach the status the add-on treats as completed, the wrong points type was selected, the test is being checked under a different user, or checkout was interrupted before final processing.

What to check: open the order details in EDD and the user record in GamiPress. Make sure the user ID matches and that the points type is the same one enabled in the gateway.

How to fix it: repeat the test with a new order, a single product, and a simple conversion rate. If the issue repeats, disable third-party checkout add-ons and run a conflict test on a copy of the site.

Points Were Deducted but the User Did Not Get Access to the Download

Symptom: the balance decreases, but there is no download link on the receipt page or the order appears incomplete.

Possible causes: the order status in EDD does not allow file delivery, the product is configured incorrectly, the download file is not attached, the receipt page has been customized, or there is a conflict with an access-control plugin.

What to check: open the EDD product and the order details. EDD lets you inspect download links inside the order record. If the link is missing even there, the problem may be in the product setup rather than in the points gateway.

How to fix it: attach the file to the download product, test the purchase through the built-in EDD test gateway, and then repeat the purchase through the points gateway. If the test gateway also fails to deliver the file, fix the product first.

Buyers Confuse the Gateway with Partial Payment

Symptom: users expect to spend some points and pay the rest with money, but the gateway requires a sufficient balance to cover the order.

Possible causes: the interface does not explain the flow, the gateway name sounds like a discount, or the loyalty program rules are described too vaguely.

What to check: read the checkout page as if you were a new user. Is it obvious that this is a payment method? Is there a link to the credits rules? Can the user see their balance before placing the order?

How to fix it: rename the payment method, add a short explanation of how points-based payment works, and if you need a hybrid flow, consider a dedicated partial payments add-on instead of trying to force the gateway to behave like a discount.

How to Tell Whether the Store Is Ready to Launch

You should launch only after a series of tests. Do not stop at one successful order, because real checkout rarely matches the ideal case. Test different balances, multiple products, insufficient balance, a discount, a refund, and the regular money-based gateway. The better you understand the edges of the flow, the fewer support requests you will get after launch.

Minimum Test Set

• A user with a sufficient balance purchases one simple digital product.
• A user with an insufficient balance tries to choose the points gateway and gets a clear outcome.
• A purchase through a regular gateway still works after GamiPress EDD Points Gateway is enabled.
• The administrator can see the order in EDD and the balance change in GamiPress.
• The balance or account page shows the current number of points after purchase.
• A refund or canceled order has been tested against your store rules.

When to Enable It for All Users

Enable the gateway for the live catalog when the full path works consistently: balance before purchase, payment method selection, order placement, file delivery, balance change, and admin verification. If even one step is unclear, limit the rollout to one product type or one user group. For a digital products store, a gradual rollout is safer than turning it on across the entire catalog all at once.

FAQ on Setup and Usage

Can I use GamiPress EDD Points Gateway without Easy Digital Downloads?

No. The entire purpose of the add-on is to add a GamiPress points type as a payment gateway specifically inside Easy Digital Downloads. If the store runs on WooCommerce, you need a different gateway from the GamiPress ecosystem.

Does the user need an account to pay with points?

In practice, yes, because the points type balance is tied to a user. If EDD allows guest checkout, money-based gateways may still work, but points-based payment needs to validate a specific balance. For that reason, it is usually better to require login or use a carefully configured registration flow.

Why should the gateway not be the default payment method right away?

Because not every buyer has a sufficient balance. For a public store, it is safer to keep the regular money-based gateway as the default and show points as an additional option. A default points gateway makes sense in a private club or internal store where every purchase is designed to be points-based.

Can part of the order be paid with points and the rest with money?

That scenario is handled by a separate partial payments flow in the GamiPress ecosystem. Points Gateway should be understood as a way to pay for the full order with the selected points type. If your store rules require mixed payment, do not promise it to users until you have verified the appropriate add-on.

How can I confirm that the points were actually deducted?

After a test purchase, open the order details in EDD and the user's profile in GamiPress. Compare the original balance, the amount calculated from the conversion rate, and the new balance. As an extra check, review the public balance shortcode while logged in as that same user.

Will the gateway affect SEO or site speed?

The gateway belongs to checkout, not to indexable content. Any SEO effect is usually indirect: it simply makes the loyalty program easier to use. For performance, the important part is excluding cart, checkout, and the receipt page from aggressive caching and making sure minification does not break payment scripts.

What should I do if checkout starts behaving differently after an EDD or GamiPress update?

Start by repeating the test in the smallest possible scenario: one product, one points type, a simple conversion rate, test mode, and the standard checkout page. Then review the changelog for the core plugins, disable checkout optimization, and see whether the problem still occurs without third-party checkout add-ons.

When GamiPress EDD Points Gateway Is the Right Choice

GamiPress EDD Points Gateway is a strong option when the site already has a clear GamiPress points economy and the Easy Digital Downloads store needs to accept those points as a full payment method. The best results come when users can see their balance in advance, understand the conversion rate, buy a digital product, and receive a standard EDD confirmation without feeling like checkout turned into an experiment.

Before launch, verify the points type, the conversion rate, active gateways, test mode, order details, balance display, and behavior when the user does not have enough points. If all tests pass, you can download the installer and move on to careful setup on your site.

If what you really need is partial payment, an achievement-based discount, awarding points based on purchase total, or an independent loyalty program, do not force the gateway to solve the wrong problem. Choose a more precise add-on and keep the points gateway for the scenario where internal points truly become a separate payment method for digital orders.