Gravity Forms Conditional Pricing - WordPress Plugin

A Guide to Setting Up Gravity Forms Conditional Pricing for Flexible Pricing in WordPress Forms

Gravity Forms Conditional Pricing is not meant for basic text changes or simple field visibility. Its real purpose is more specific: changing the price of a Gravity Forms Product field based on conditions the user meets inside the form. In this guide, we will walk through how to set it up without turning your Product fields into a mess, how to structure pricing tiers, how to test the final result on the live site, and how to avoid losing your rules when options change later.

This guide is for site owners, webmasters, and developers who already use Gravity Forms for inquiries, registrations, service orders, quotes, or simple form-based sales. What follows is not a reworded plugin listing, but a practical workflow: preparing the Product field, building pricing logic, importing rules by CSV, troubleshooting errors, working through a group-order example, and identifying cases where a different tool may be a better fit.

The main idea is simple: conditional pricing should be one clear rule system, not a collection of hidden Product fields that are difficult to maintain. That is why it helps to understand your pricing logic before installation - what business rules you want to apply, which fields will drive the conditions, and where the user will see confirmation of the final amount.

This guide uses the original Gravity Forms and Gravity Wiz interface labels as they appear in the UI: Form Settings, Conditional Pricing, Select a Product, Save Pricing, Import Pricing Levels, Export Pricing. It is best not to mentally translate these during setup, because in the admin panel they usually appear exactly that way.

What Problem Conditional Pricing Solves in a Form

Gravity Forms' built-in conditional logic can show and hide fields. That is useful, but it becomes clumsy when pricing is involved. For example, you could create several Product fields with different prices and display the appropriate one based on a condition. That works on a simple form. But on a form with plans, quantity discounts, age groups, rush options, or date-based pricing, that approach quickly turns into a web of dependent blocks where it is easy to forget one field, break the total, or make the page heavier than it needs to be.

Gravity Forms Conditional Pricing works differently. The user sees a single Product setup, and the plugin applies the price based on rules. The rules resemble standard Gravity Forms conditional logic, but the result is not field visibility - it is the selection of a Pricing Level. A pricing level consists of a price and a set of conditions that must be met for that level to apply.

This approach is useful in several common scenarios:

• Event registration, where early registration costs less and late registration may cost more.
• Group orders, where the per-unit price changes as quantity increases.
• Service request forms, where pricing depends on urgency, region, selected package, or a user response.
• Sports, education, or club forms, where pricing depends on age, participant role, or membership type.
• Large pricing matrices that are easier to store and update through CSV than by manually editing dozens of fields.

The plugin is not a replacement for a full WooCommerce catalog, and it does not turn Gravity Forms into a universal storewide discount system. Its strength is forms with Product fields where pricing needs to respond to user input directly inside the form. If that is your use case, setup is usually cleaner than managing a stack of hidden products.

When the Plugin Makes Sense and When It Adds Unnecessary Complexity

Before installing it, separate the cases where conditional pricing is truly needed from the ones where standard Gravity Forms fields are enough. Product, Option, Quantity, Shipping, and Total already form a pricing system. Sometimes that is all you need: the user picks a product, chooses options, enters quantity, and Total calculates the amount. Conditional Pricing comes into play when the base price of a Product field must change based on a combination of conditions, not just from an Option field.

Who Will Benefit from It

Gravity Forms Conditional Pricing is usually a good fit for sites where the form acts like a mini configurator. That could be an event registration form, a service quote calculator, a personalized product order form, a training signup, or a membership form. If the admin needs to adjust price tiers without rewriting code, the Pricing Levels interface is much more practical than a custom JavaScript solution.

Three product traits are especially useful. First, pricing levels can be reordered, and that order truly affects the result. Second, the rules use familiar Gravity Forms logic. Third, large rule sets can be moved into CSV through export and import. For a form with a few rules, that is a convenience. For hundreds of pricing combinations, it becomes the foundation of maintainability.

Who May Not Need It

The plugin may be overkill if the form has one fixed price, a couple of simple Option fields, or a basic discount that would be easier to calculate with a formula. It is also not the right direct solution for Shipping fields, User Defined Price, Calculation Product, or Option fields, because the official documentation lists those types as unsupported by Conditional Pricing itself. In those cases, you need to rethink the form architecture: use a Product field as the pricing element you control, instead of trying to attach conditional pricing to an unsupported field type.

A practical check before installation: if you cannot point to a single Product field whose price should change based on user input, sketch the form out on paper first. Conditional Pricing works best when the form has a clear "pricing center."

What to Check Before Installation and Initial Setup

Preparation matters more than installation itself. The plugin works on top of Gravity Forms and its Pricing Fields, so problems often come not from Conditional Pricing directly, but from a weak form structure. Before turning the plugin on, review your fields, values, quantity setup, total calculation, and the way the form is rendered in your theme or page builder.

Check the Product Field Structure

In Gravity Forms, a Product field can be Single Product, Drop Down, Radio Buttons, or User Defined Price. Conditional Pricing can create rules for Single Product, Drop Down, Radio Button, and Hidden Product. But choice-based product types come with an important limitation: rules for individual choices depend on the choice order. If you remove or reorder Drop Down or Radio Button options after pricing is configured, you can break the rule mapping.

That is why you should lock down the option structure before setup. If you need to rename options often, use simple, unique values in Gravity Forms wherever possible. If the option order is still being discussed with the client, do not rush into building dozens of Pricing Levels. Finalize the options first, then build the rules.

Check the Fields That Drive the Conditions

The pricing level is selected by conditions. A condition can use any form field available to Gravity Forms conditional logic. For quantity, that might be a Quantity or Number field; for urgency, a date selection or toggle; for membership, Radio Buttons, a Drop Down, or a Hidden field populated from the current user. The more stable the source value, the fewer surprises you will see on the front end.

If a condition depends on a field that is itself hidden by other conditional logic, test that behavior separately. Gravity Forms warns that nested conditional logic has limitations. With pricing, this becomes especially visible: the user may see one total, but then hit a validation error on submission if values change out of sequence or the form scripts do not recalculate Total in time.

Check Total and the Test Payment Flow

If the form takes payment, visual checks are not enough. First, make sure Product fields have prices even if the price is meant to become zero. The official Conditional Pricing troubleshooting notes specifically call out the risk of an Amount Mismatch error when prices are blank. In practical terms, that means it is better to explicitly set 0 than leave a price empty when the field participates in the calculation.

Before launch, prepare a test page, open the form in a regular browser, and run several answer combinations. Compare three things: the Product field price, the Total on the form, and the final amount passed to your payment or email workflow. If all three match, you can move on to more complex rules.

Installation and Initial Validation in the Admin Panel

After installing and activating Gravity Forms Conditional Pricing in WordPress, setup does not happen on a global plugin page. Instead, it is configured inside the specific form. That makes sense: pricing rules are tied to a form's Product field, not to the entire site.

1. Open the target form in Gravity Forms and add a Product field if it is not already there.
2. Save the form with Update so the Product field becomes available in settings.
3. Go to Form Settings and open Conditional Pricing.
4. In Select a Product, choose the Product field whose price should change.
5. Add your first Pricing Level: set the price and the conditions under which it should apply.
6. Click Save Pricing, then open the form on the front end and verify the result.

What Counts as a Successful Initial Check

Do not begin with a full condition matrix. For the first validation pass, two pricing levels are enough: a base level and one level driven by a simple condition. For example, if the "Participant Type" field equals "Member," the price changes to a discounted rate. If that works, add the second and third levels.

After each save, test the public page in conditions that are as close as possible to the real user experience. If the form is embedded through a block, shortcode, page builder, or tab, test that actual placement, not just the admin preview. Dynamic pricing depends on JavaScript, so theme, cache, or page-builder conflicts usually show up on the live page itself.

Roles and Permissions to Keep in Mind

To manage Conditional Pricing settings, the user role must have the proper capability. The documentation lists gp_conditional_pricing_form_settings. If an administrator can see the form but not the Conditional Pricing screen, or gets a rule-loading error, check your role management plugins and access permissions. It may not be a plugin failure at all - the role may simply lack access to that section.

How Pricing Levels Work and Why Order Matters More Than Naming

A Pricing Level is a standalone price plus a set of conditions. When the user fills out the form, the plugin checks levels from top to bottom. The first matching rule wins. Because of that, the order is not cosmetic. If a broad rule sits above a narrow one, it can catch the user before the correct rule is even evaluated.

The "Specific to General" Rule

A good habit is to arrange rules from the narrowest to the broadest. If you are pricing for early registration, club members, and regular visitors, put the most specific combinations first. For example, "club member + early registration" should sit above just "club member." Otherwise, the user will get the standard club price and never reach the better early-registration price.

The same logic applies to quantity discounts. If the per-unit price changes at higher quantities, put the largest range first, then the middle range, then the smaller one. That way the form does not stop at a weak condition like "quantity greater than 2" when the user entered 20.

How to Name Levels for Easier Maintenance

Not only the conditions matter - human readability does too. Use clear labels in your internal project documentation: "VIP early," "Group 10+," "Rush delivery," "Youth fee." This guide does not prescribe one admin naming style, but in a real project it helps to choose one convention and stick to it. If someone else needs to maintain the rules later, they should understand not only the price but the reason behind the level.

Quick Validation After Reordering Levels

After changing the level order, run three tests: one user should match the strictest level, one should fall into a broader level, and one should get the base price. If all three are correct, the order is working. If the first test returns the general price, your narrow rule is either too low in the stack or written more loosely than intended.

Detailed Rule Setup: From One Product to a Large Pricing Matrix

Conditional Pricing starts with a simple interface, but it quickly becomes an editorial task. You need to decide what the source of truth is: the form interface or an external CSV file. For a few levels, the interface is convenient. For hundreds or thousands of rules, export and import are the better path, because they let you review the matrix in a spreadsheet, get business approval, and push it back into the form without clicking through every level by hand.

Basic Manual Setup

For manual setup, select the Product field, add a level, enter the price, and define one or more conditions. The conditions use familiar operators: is, is not, less than, greater than, contains, starts with, ends with. If you need to check empty values through import, the documentation describes special values EMPTY and !EMPTY.

In a typical project, it is smart to start with a decision table before touching the admin panel. It can be simple:

After saving, do not stop at a single test. Check edge cases: minimum quantity, a value exactly at the discount threshold, a value above the threshold, an empty selection, a regular user, and a user who qualifies for special pricing. Most mistakes are found at the edges, not in the middle of the range.

Importing and Exporting Rules with CSV

Once the pricing matrix gets large, the manual interface becomes slow. Conditional Pricing supports importing and exporting pricing rules. The practical workflow is this: create a few rules in the interface, click Export Pricing, use the exported file as a template, edit it in a spreadsheet, and then bring the rules back through Import Pricing Levels.

Import strategy matters. Replace All overwrites every existing level and is useful when the CSV is your only source of truth. Replace Matching is helpful when replacing levels for specific products or groups. Append adds new levels but does not update existing ones. For large tables, it is usually safer to treat the file as the source of truth and use replacement, but always save the current export first.

When an Import May Not Fully Complete

If the CSV contains too many unique products, conditions, or condition rows, you may hit the server's max_input_vars limit. The official FAQ lists this as a reason why an import may fail to bring in all rules. In practice, that means you should not try to fix the issue by clicking import again and again. First review the size of the spreadsheet and your hosting limits, then decide whether to split the import or adjust the server setting through hosting support.

Settings You Should Not Change Without a Reason

Do not change the Product field type or reorder options after the rules are already configured. This is especially important for Drop Down and Radio Button Products. Do not remove options unless you are ready to rebuild the rules. Do not aggressively hide Total or Product fields with CSS classes if the form is tied to payment or a WooCommerce integration - hiding should not remove the field from the calculation. If you need to hide a field visually, use a Gravity Forms-friendly approach such as gf_invisible, not a class that prevents the field from participating in the total.

Rolling back a questionable change is straightforward: restore the previous exported rules, recover the original level order, and clear the page cache if the form is embedded in a builder. If the issue started after a theme change or JavaScript optimization, disable optimization on the form page first instead of immediately rewriting the pricing rules.

Scenarios Where Conditional Pricing Really Shines

Conditional pricing is useful for more than discounts. Its real strength is that pricing becomes part of the form's logic. Here are several scenarios that show when the plugin delivers more value than standard Pricing Fields.

Quantity Discounts Without Dozens of Product Fields

For bulk pricing, the user enters a quantity, and the per-unit price changes once a threshold is reached. The important thing to remember is that Conditional Pricing changes the Product field price, and Quantity then participates in the line total calculation. If you need something like "3 items for a fixed amount," you may need to design the per-unit price so the final total matches the business rule. That is a normal part of pricing design, not a plugin flaw.

Date-Based Pricing, Rush Requests, and Early Registration

For early registration or rush requests, the condition may rely on a date, but in a real project you need to confirm which tool provides the necessary date/time conditions. In Gravity Wiz materials, current-date scenarios are tied to advanced conditional logic and date/time features. If the value you need is not available in the condition list, do not invent a pricing workaround. First add the confirmed tool that provides the required condition source.

Membership and Different Prices for Different User Groups

For member vs. non-member pricing, it works best to use a field that explicitly stores the user's status. That could be a form choice, a hidden field populated from user data, or separate site logic. A good setup should not make the user guess why the price changed. In the form description or confirmation, it helps to explain the pricing condition in plain language: "Member pricing applied after registration type selection."

Multi-Row Configurators and Nested Forms

Combined with GP Nested Forms, Conditional Pricing can help with group orders where child entries are counted as quantity or affect the price. This is a powerful setup, but it needs especially careful testing: verify adding, deleting, and editing a nested entry, quantity recalculation, final pricing, and form submission. If the user can manually change the quantity, consider a Read Only approach or another built-in way to protect the field from accidental edits.

Large Price Lists Where the Spreadsheet Matters More Than the UI

Some forms depend on pricing from not one or two conditions, but from a large matrix. For example: product size, print run, shipping region, finishing type, page count, or a combination of several attributes. In those cases, the admin interface is useful for checking results, but not for day-to-day maintenance. Your team will usually find an error faster in CSV than in a long list of Pricing Levels.

For these projects, it helps to assign one file as the source of truth. Its columns should be understandable not only to the developer but also to the product manager: condition, operator, value, price, and an internal review comment. After import, save that same file in the project system or the client's documentation. That way, a month later, nobody has to guess which rules were edited by hand inside the form and which came from the spreadsheet.

Do not let your CSV turn into an unmanaged database. If the rules are numerous, the spreadsheet needs an owner, a version, and a simple review process. After every import, export the rules from Conditional Pricing and compare them with the expected structure at least selectively: the top strict level, a middle level, the base price, and one empty or exception case. That editorial habit can save hours of troubleshooting.

When Conditional Pricing Is Better Than a Formula, and When It Is Not

A conditional pricing level is easy to read when the business logic sounds like this: "club members pay this price," "groups over ten pay less," or "rush delivery costs more." A formula is better when the business logic sounds like: "multiply square footage by a coefficient," "subtract a discount," "calculate the difference between dates," or "apply a minimum and round." In the first case, you select a finished price from a set of levels. In the second, you build the price as the result of a calculation.

In real projects, these approaches can sometimes be combined. Conditional Pricing may choose the base service price, while a calculation field adds the cost of extra parameters. But only combine them after separate testing. If the user sees a total assembled from several sources, document exactly what Conditional Pricing changes, what is added by an Option or Calculation field, and where the final Total is determined.

How to Maintain Rules After Launch Without Making the Form Fragile

After launch, the biggest risk is usually not a setup mistake but routine maintenance. An editor adds a new option to a Radio Button Product, a marketer asks for a temporary discount, a developer enables JavaScript optimization, or the client changes pricing ranges in the spreadsheet. All of those are normal changes, but each one can affect conditional pricing. That is why Conditional Pricing needs a small amount of operational discipline.

Document the Business Logic Separately from the Interface

Do not keep the meaning of your rules only in the admin panel. Create a short document: which Product field is the pricing center, which fields participate in conditions, which levels are considered strict, which values are baseline defaults, and who is allowed to edit the CSV. That is not bureaucracy - it is protection against the moment when a new editor sees ten levels and has no idea why one sits above another.

For every major change, record not only the new price but also the reason: seasonal pricing, a group discount, a new participant category, a temporary promotion, or a cost increase. Then, if a dispute comes up weeks later about why a user received a certain amount, you can reconstruct the logic without rereading every form condition.

Separate Content Edits from Pricing Edits

Content managers often need to change an option label, update descriptive copy, or rearrange a visual block on the page. But with choice-based Product fields, changing the order of choices can break Conditional Pricing rules. So set a rule internally: text around the form can be edited more freely, but the choices inside the Product field should only be changed after exporting rules and running a test.

If you need to rename an option without changing its meaning, first check whether the option has a stable underlying value. If the values are poorly configured or include complex characters, changing the label can unexpectedly affect conditions, imports, or exports. In that case, it is safer to schedule a technical update window: export, edit, import, then fully validate the matrix.

Do Not Trust Only the Form Preview

The admin preview is useful for quick checks, but it is not a substitute for the page where the form is actually embedded. On the live page, you introduce the theme, builder, optimization layers, cache, analytics, popups, styles, and extra scripts. Any of those can break dynamic price or Total updates.

After every meaningful change, test the form where users actually see it. If the form appears on several pages under different conditions, test all important placements. For multi-page forms, walk through the entire path from page one to submission, not just the pricing step. Sometimes the price updates correctly, but conditional navigation or a hidden field on an earlier step leaves behind a stale value.

Keep a Fast Rollback Plan

Your rollback path for Conditional Pricing should be clear in advance. At minimum, keep the last known-good pricing export, a list of test scenarios, access to the form page, and a clear understanding of which caches need to be cleared. If you are making changes before an important campaign, test them on a copy of the form first. Once verified, move the rules into the live form and rerun a short test matrix.

A solid maintenance rule: any change that affects the Product field, the order of choices, CSV import, JavaScript optimization, or the form embedding method should be treated as a pricing change and requires rechecking Total.

Practical Example: Group Order Discount in a Registration Form

Let us look at a concrete example without tying it to a specific site's pricing. Imagine a training registration form. The user selects the number of participants. You need to change the per-person price based on quantity ranges and show the correct total in Total. The goal is to create one Product setup where the price changes automatically, without forcing the editor to create a separate Product field for every range.

Goal

We want the "Registration" Product field to use a different per-unit price depending on participant quantity. For the user, this should feel straightforward: they enter a quantity, see the updated price and Total, then submit the form. For the admin, it should remain maintainable: discount thresholds are clear, and rule order does not break stricter conditions.

Preparation

Before setup, make sure the form includes a Product field, a Quantity or Number field for quantity, a Total field, and a test page with the form on it. The Product field must have a base price. If the quantity is copied from a separate field into Quantity, confirm that the copy behavior works before adding more complex pricing levels.

Setup Steps

1. Open the form and make sure the Product field has been saved.
2. Go to Form Settings - Conditional Pricing.
3. Select the Product field in Select a Product.
4. Create the strictest level first for the highest quantity range.
5. Below it, create the level for the middle range.
6. Below that, keep the general level or base price for smaller quantities.
7. Click Save Pricing and open the public form page.

In the rules, use testable conditions, not human summaries of a range. For example: quantity greater than a specific threshold. If ranges overlap, the order of levels should protect the most favorable or most specific case. Even if ranges do not overlap, still test the boundaries: exactly at the threshold, below it, and above it.

Verifying the Result

Open the form in a browser and try several values. For each one, write down the expected per-unit price and Total before testing. After changing the quantity, make sure Total updates without a page reload. Then submit a test entry if the form is not connected to a real payment flow, or use the payment workflow's test mode.

Example takeaway: the setup is only ready when the Product field price, the Total on the page, and the submitted data all match. If only the visual Total looks correct but payment validation rejects the amount, the configuration needs to be diagnosed before launch.

A Common Detail That Gets in the Way

If the form is embedded in an Elementor page, cached by an optimizer, or loaded inside a dynamic block, price recalculation may depend on page scripts. If the behavior looks strange, open the browser console first and check for JavaScript errors. If the issue started after enabling optimization or element caching, temporarily disable that setting for the form page and rerun the test.

How to Validate the Result Before Publishing

Publishing a form with conditional pricing without a test matrix is risky. Even if the interface looks correct, an error in level order or a blank Product field price may only appear under a specific combination. Validation should be just as structured as setup.

Test Matrix

Create a short list of test scenarios. It should cover every pricing level, all boundary values, empty or default states, and one case where no special rule should apply. For each scenario, write down the expected result before testing, not after. That protects you from accepting whatever result appears on screen as correct simply because it showed up.

Check UX and Explanatory Copy

The price can be technically correct and still be confusing to users. If pricing changes after a status, quantity, or date selection, add a short explanation near the form. You do not need to expose the full pricing matrix, but the user should understand why the total changed. For choice-based Product fields where the updated price is not always obvious next to the option, you can use official Gravity Wiz snippets to display price labels if the project truly needs that clarity.

A Small Visual Improvement That Does Not Touch the Logic

If you want to make the Product field price stand out more clearly, it is safer to start with CSS than with PHP or JavaScript. Here is an example for forms using the modern Gravity Forms theme framework. You can add it to a child theme or another safe location for custom CSS. It does not affect the calculation - it only makes the price more visible.

.gform-theme--framework .gfield--type-product .ginput_product_price,
.gform-theme--framework .gfield--type-product .ginput_container_product_price .ginput_amount {
  font-weight: 700;
  color: #2155d9;
}

Test the form on the page where it is actually published. If the style does not apply, the site is probably using a different Gravity Forms theme framework or overriding the CSS at a higher level. Rollback is simple: remove the snippet. Do not use CSS to hide critical calculation fields until you are certain the field still participates in Total and form submission.

Why Conditional Pricing Does Not Work and How to Find the Cause

Conditional Pricing troubleshooting should move from simple to complex: first the Product field structure, then level order, then JavaScript, permissions, import behavior, integrations, and payment validation. Do not change everything at once. If you do, you will not know which fix actually solved the problem.

The Price Does Not Change on the Front End

Symptom: the levels are saved in the admin panel, but the user still sees the base price. Possible causes include a condition that does not match, broken JavaScript on the page, a hidden source field, or a value that differs from what you expected.

Check the browser console, disable script optimization for testing, and temporarily simplify the rule to one obvious condition. If the simple condition works, the problem is in the more complex logic. If it does not, confirm that the correct Product field is selected in Select a Product and that the rules were saved with Save Pricing.

The Wrong Pricing Level Applies

Symptom: the price changes, but a broader level is selected instead of the intended one. In most cases, the levels are in the wrong order. Conditional Pricing checks rules from top to bottom and uses the first match.

Move the strictest level above the general one. Then test at least three scenarios: strict, general, and base. If the strict level still does not apply, compare each condition against the actual field value. With Drop Down and Radio Button Products, do not forget the risk of changing choice order after setup.

Not All Rules Appeared After Import

Symptom: the CSV imports, but some levels are missing. Check the import strategy, file structure, and the server's max_input_vars limit. With large files, that limit can prevent all products, rows, or condition columns from being processed.

Do not rerun the import blindly. First export the current rules, compare that file against the source of truth, and if needed split the import by product. If the limit is truly server-side, contact your hosting provider or server administrator.

Amount Mismatch Error or Payment Failure

Symptom: the user sees one total, but submission or the payment flow rejects the amount. The official troubleshooting guidance recommends checking that all Product fields and choices have prices. If the price should be zero, set 0 instead of leaving the field blank.

Then compare the Total on the form against the amount passed into the entry or payment workflow. If the form is connected to WooCommerce Gravity Forms Product Add-Ons, do not use hidden-total if it prevents Gravity Forms from including the product in the calculation. For visual hiding, gf_invisible is often a better fit, but only after testing.

The Settings Page Is Hidden or Error fetching pricing rules Appears

Symptom: a user with an editor or manager role cannot see Conditional Pricing or gets an error while loading rules. A likely cause is role restrictions. Check whether that role has the gp_conditional_pricing_form_settings capability or the matching permission in your role management plugin.

If you temporarily grant extra permissions for troubleshooting, return the role to the minimum required set afterward. Do not hand out broad admin access just to open one settings screen.

Elementor or Page Optimization Breaks Recalculation

Symptom: the price changes in a normal preview, but behaves inconsistently on an Elementor page. The official Conditional Pricing documentation mentions a conflict with Elementor's Element Cache setting. For troubleshooting, disable that option in Elementor - Settings - Performance and rerun the test.

If that resolves the issue, decide what makes sense for the project: keep an exception for the form page, change how the form is embedded, or revisit the optimization setup. If it does not help, run a standard theme/plugin conflict test and re-enable plugins one by one.

Compatibility, Limitations, and Safe Boundaries

The plugin has real strengths, but it also has clear limits. It is much better to account for those limits in the form architecture than to discover them after a campaign or email launch.

Unsupported Fields

Conditional Pricing is not designed for User Defined Price, Calculation Product, Option, or Shipping fields. If your use case centers on those field types, try changing the structure: the price that should vary by condition needs to live in a Product field. For shipping, you can sometimes use a Product field as the conditional shipping cost and then apply a confirmed workaround, but that is a separate architecture that should be tested with payment and totals.

Choice-Based Products and Option Order

With Drop Down and Radio Button Products, the main risk area is changing choices after setup. Because Gravity Forms does not provide a reliable unique identifier for individual choices in this context, rules may depend on the choice index. Deleting or reordering options can break the rules. Before making changes, export pricing, record the old order, and verify every rule after the edit.

Multi-Currency and PDF Invoices

The documentation notes support for the Multi-Currency for Gravity Forms Addon from IdeaWP and integration with Invoicing Templates by Gravity PDF. That does not mean every multi-currency or PDF scenario will automatically work without validation. If you use multiple currencies, taxes, PDF invoices, or a third-party checkout, test not only the form but also the final document, email, entry, and payment gateway.

Performance and Maintainability

One Product field with rules is usually easier to maintain than twenty hidden Product fields. But a large pricing matrix is still a large pricing matrix. If you have many rules, keep the CSV as the source of truth, document what each column means, and do not let several admins edit rules in both the interface and the spreadsheet at the same time. Otherwise, it becomes difficult to know which version is current.

Video on Member and Non-Member Pricing

The official Gravity Wiz listing for Conditional Pricing includes a dedicated video for the member vs. non-member pricing scenario. It is useful as a visual reference for the intent cluster around "how to set different prices for members and regular users" because it shows not abstract conditional logic, but a concrete pricing split inside the form.

After watching it, it makes sense to return to the Pricing Levels section and double-check rule order: membership scenarios are especially easy to break when a general level sits above the discounted one.

When Gravity Forms Conditional Pricing Is the Right Choice

Gravity Forms Conditional Pricing is worth using when the form has clear pricing logic: the Product field price needs to change based on user input, and maintaining that through dozens of hidden Product fields has become cumbersome. The plugin is especially well suited for quantity discounts, early registration, member pricing, age groups, rush services, and large pricing matrices that are easier to manage through CSV.

Before launch, verify three things: the Product field is supported, the Pricing Levels are ordered from specific to general, and Total matches the submitted data. If the form is connected to payment, WooCommerce, PDF invoices, or multi-currency logic, add a separate test for the full user flow. If everything lines up, you can download the latest version of Gravity Forms Conditional Pricing and safely test the plugin on a copy of the form or a staging page.

The best outcome is not just that the plugin "applies a discount," but that pricing becomes a clear part of the form itself. The user sees an understandable total, the admin understands the rules, and future changes can be made without risking the entire order structure.