Gravity Forms Price Range - WordPress Plugin

Guide to Setting Up and Using Gravity Forms Price Range

Gravity Forms Price Range is not designed to turn a form into a complicated calculator. It serves a very specific purpose: it lets visitors enter their own amount while keeping clear limits in place. This is useful for donations, tips, pay-what-you-want services, voluntary contributions, prepaid requests, and any use case where a zero payment, an accidental extra zero, or an amount that is too small would be unacceptable.

This guide explains how the plugin works with the Gravity Forms Product field: what to prepare, how to choose the right field type, where to find the Min and Max settings, how to test validation before enabling payments, and how to distinguish a range error from a payment gateway failure. It also includes a practical donation-form setup with fixed suggested amounts and an "Other Amount" field.

It is important to separate the roles from the start. Gravity Forms Price Range does not create a payment gateway, change exchange rates, or calculate a product price using a formula. It adds limits to an amount entered by the visitor in a User Defined Price field. If the amount falls outside those limits, the form should return a validation error instead of submitting normally. That means the rule is enforced when the form is submitted, rather than existing only as a text hint next to the field.

What a Price Range Is For and When It Makes Sense

Allowing visitors to enter any amount seems simple until a form goes live. A visitor may enter the expected value, but they may also leave the field empty, accidentally add an extra digit, or enter an amount that no longer makes sense for the chosen payment model. For example, a nonprofit may be willing to accept any contribution but want to filter out token amounts that fall below processing costs. An event organizer may let supporters contribute more than the suggested amount but does not want the form to accept a mistaken amount with two extra zeros. A consulting service may offer a "pay what you think is fair" option while setting a minimum so that a booking does not become free.

Gravity Forms Price Range is built for exactly these situations. It does not choose an amount for the visitor, hide a product, or replace payment terms. It takes the number entered in the custom price field, compares it with the minimum and maximum, and either continues processing or displays an error. This is control over an allowed range, not a discount tool or a multi-tier pricing system.

Four Situations Where the Rule Is Truly Useful

• Donations with a minimum contribution. The field accepts a custom amount, while the organization sets a lower threshold at which processing the donation remains worthwhile.
• Tips or voluntary add-ons. The main service is already described on the page, and visitors can add an amount within limits that will not cause calculation issues.
• Pay-what-you-want pricing. The user keeps the freedom to choose, while a minimum price protects the product's basic economics and a maximum helps prevent typos.
• Fundraising for an event or initiative. Suggested amounts can appear as a separate list, while an "Other Amount" option remains available for visitors who prefer to enter a number manually.

In every case, start by answering a business question: what exactly do the lower and upper limits mean? The minimum may be a real payment-acceptance threshold, while the maximum may protect against incorrect input. Do not use an upper limit as a hidden way to push visitors toward a more expensive option. If campaign rules limit the amount, explain that next to the field in plain language. A visitor should not learn about an important restriction only after pressing the button.

Who the Plugin Is For, and When Another Approach Is Better

The plugin is a good fit for site owners who already use Gravity Forms and have created, or plan to create, a Product field with the User Defined Price type. In that type of form, setup is compact: the range is assigned to a specific field, and the rule lives alongside that field's settings. This is easier than custom validation when you need standard, fixed Min and Max values without unusual business rules.

Price Range is not the right choice when a price depends on several selections, quantity, region, customer status, or purchase time. That type of setup needs a Gravity Forms calculation field, conditional logic, or a specialized dynamic-pricing tool. The related Gravity Forms Conditional Pricing product is designed for pricing tiers chosen based on form conditions. Price Range can remain the final limit on a custom amount in that setup, but it does not replace calculation rules.

Do not confuse a custom price with a standard Number field. A Number field stores a number, but it does not automatically become a form product or appear in the total as the cost of a Product field. If the goal is to validate age, attendee count, or square footage, use validation or a calculation for the appropriate field. If the goal is to accept money, begin with a Product field.

What to Check Before Installation: the Form, the Money, and the Limits

A preliminary review saves more time than trying to fix an already published form. First, make a copy of the existing form or work on a test page. This is especially important if the form has an active payment gateway, notifications, or third-party integrations: changing a Product field affects the form total, and that total may provide the amount used by a payment add-on.

Confirm the Original Field Type

In the Gravity Forms editor, a Product field has several modes. Gravity Forms Price Range works only with User Defined Price. This mode displays one text input where a person enters a price. A standard Single Product field displays a predefined price, while Drop Down and Radio Buttons use prices from a list. They draw their values from a different source, so a free-entry range is neither needed nor the purpose of this plugin.

Confirm this in the field settings, not from the label shown on the page. A field may be called "Donation Amount" or "Your Support" but technically be a Number field. In that case, the plugin will not detect the target Product field. The sign that the setup is correct is the User Defined Price type selected in the Field Type section.

Identify Which Total Is Sent to Payment

If the form accepts payments, open its payment gateway settings and confirm which amount source is selected. In the official Stripe add-on settings, this may be a specific Product field or Form Total. When a form has only one product with a custom price, both approaches may sometimes produce the same figure. Once you add a donation, shipping, discount, or additional product, however, the outcomes begin to differ. Do not change the amount source by guesswork on launch day.

A useful practice is to write down the chain: what the user enters, which fields build the total, which gateway receives that total, and which notification confirms the event. This chain has two independent checks. Price Range validates the custom amount limits. The payment gateway separately checks whether it can process the total. Passing range validation does not mean the payment was successful, and a payment error does not prove that Min or Max has been configured incorrectly.

Match the Text Near the Field to the Actual Rule

If you write, "Enter an amount from $5 to $100," the settings must use exactly those limits, taking the form currency into account. Do not hide restrictions in a site policy or make visitors guess the format. A short description works better: "Enter an amount from $5 to $100. We will validate it before the form is submitted." This tells visitors that they can enter an amount within a range rather than choose one fixed rate.

Do not describe a standard upper limit as fraud protection. It may protect against an accidental extra zero, but it does not replace payment-provider requirements, transaction review, spam protection, or monitoring. If the form is open to public fundraising, configure Gravity Forms' built-in spam protection separately and check who receives request notifications.

A Minimal Pre-Launch Checklist

• A test page or form copy has been created and does not affect real payments.
• The form contains a Product field with the User Defined Price type, rather than a number field with a similar purpose.
• It is clear where the currency is configured and how visitors see its symbol.
• A minimum threshold has been defined, and the maximum limit has a clear reason.
• You know which Product field or form total the payment gateway uses.
• Test amounts are ready for below the minimum, at the limit, within the range, and above the maximum.

For a form that accepts real payments, test first in the payment provider's test mode. Do not make a real transaction the first test of new validation. After changing the form, test not only the amount but also the confirmation, notification, and actual payment status.

Installation and the First Check in the WordPress Admin Area

Install and activate Gravity Forms Price Range using the method provided with your Gravity Perks subscription. Then open the specific form containing the relevant product, not the global WordPress settings. The plugin is not intended to create a large standalone configuration page: its working controls appear in the settings of the target Product field.

In the form editor, add a Product field from the Pricing Fields group or select an existing one. Set its Field Type to User Defined Price. Save the form once before continuing with configuration. This simple step helps you see the current field settings and avoid confusing an unsaved editor state with a plugin issue.

Where to Find Min and Max

Open the settings for that specific field and go to the Perks tab. When Price Range is active, the Min and Max fields appear there. Enter the limits you need. You can set only a lower limit, only an upper limit, or both, depending on the use case. A form for open donations will often need only a minimum; adding a maximum also makes sense when protecting against incorrect input.

After entering the values, click Update or the form-save button used in your interface. Then open the form page in a new private browser window. A private window is not a complete diagnostic method, but it removes the effects of your logged-in administrator session and often shows the public form as a visitor will see it.

A First Safe Test Without Payment

While the payment gateway is disabled or in test mode, submit the form with a number below the minimum. The expected behavior is that the form remains on the page and the custom price field displays a message about the invalid amount. Then try a value equal to the minimum. It should pass this validation. Repeat the same test with the maximum and with a value one unit above it.

Do not test only the easy case of an amount in the middle of the range. Boundary-handling problems are most often discovered too late: an editor may assume the minimum amount is allowed when the rule actually excludes it, or a limit may have been entered with the wrong separator. Record all four outcomes in a test note. It will provide a reference point when the form is changed later.

Configuring the Amount Range: Min, Max, and a Clear Visitor Experience

It is better to configure Min and Max as an agreement between the page and the visitor, not as two arbitrary numbers. The lower limit answers the question, "What is the smallest amount that makes sense for this transaction?" The upper limit answers, "What amount can still reasonably be accepted without manual review?" If you cannot clearly explain each value, clarify the campaign rules before changing the form.

Minimum Only

A minimum works well for voluntary contributions when no upper limit exists or when setting one would be awkward. Enter the threshold in Min, leave Max empty, and explain near the form that a larger amount is allowed. This is a good option when you do not want to artificially limit a generous contribution but must exclude amounts below an acceptable level.

Do not replace the minimum with a browser-field attribute or a description-only note. A user may bypass an interface-level barrier through another input method, while server-side validation at submission must remain the final check. A strong form combines a visible hint with an actual Price Range rule.

Maximum Only

An upper limit is needed less often, but it can be justified. For example, a campaign may accept contributions only within a specific limit, while larger payments must go through a separate process. In that case, configure Max, tell the user about the available range, and provide an alternative contact path for amounts above the limit. Otherwise, the error message will feel like a rejection without an explanation.

Do not use a maximum to manipulate pricing. If visitors can choose their own amount, they should see the real limitation before pressing the button. Discovering it after submission is acceptable as protection against an error, but not as the only form of communication.

Both Limits: the Standard Setup for a Controlled Campaign

When a form has both a minimum and a maximum, the range becomes more predictable. For example, an organizer may invite contributions within a defined range and ask visitors to contact them directly for amounts above the maximum. Repeat the range in the user-facing text so that visitors do not need to infer it from indirect wording. The field description should state the units and rounding rule if that matters for the currency in question.

Gravity Forms Price Range validates the actual custom price entered when the form is submitted. Do not expect the field to automatically become a slider, a group of buttons, or a dynamic suggestion. If your use case specifically needs interactive package selection, create radio buttons with preset Product values and add a separate "Other Amount" path with a conditionally displayed User Defined Price field.

Preset Amounts and "Other Amount"

This is one of the clearest setups for visitors. In the first Product field, create Radio Buttons with several recommended values. Add "Other Amount" as an option with a price of 0. Then add a second Product field with the User Defined Price type. Enable conditional logic for it so that the field is shown only when "Other Amount" is selected in the first field. Apply Price Range to the second field.

This separation keeps things simple for most visitors without taking flexibility away from others. It is important to verify the total, however. When a visitor chooses a fixed option, the custom field should remain hidden and add no price. When they choose "Other Amount," the fixed option with a zero price should not affect the total, while the entered Product field becomes the sole source of the custom price.

How to Choose Values Without False Precision

Suggested amounts should reflect real support levels rather than serve as a decorative set of numbers. For a small campaign, three or four clear options are enough. If there are too many choices, visitors take longer to decide and are more likely to miss the custom-entry field. The Price Range limits do not have to match the outer suggested amounts: a valid minimum contribution may be lower than the first suggestion, and larger support may remain possible above the last suggestion up to the configured maximum.

Critical configuration outcome: a value at the boundary is allowed, a value immediately beyond the boundary is rejected, and the message explains what the user should do. If even one of these conditions is not met, do not connect the form to live payments.

How Validation Works: From Entered Amount to Submission Outcome

It helps to see the whole mechanism because doing so prevents the mistaken expectation that "the plugin should change everything on the page." A visitor enters a number in a Product field. Gravity Forms processes the form structure, and Price Range compares the amount with that field's settings. If the amount is within the allowed range, form processing continues. If it is not, the field receives a validation error, and the normal next steps - notifications, the payment gateway, a PDF, or a webhook - should not begin as though the form had been submitted successfully.

What Gravity Forms Validates Before Price Range

Gravity Forms documentation states that User Defined Price is validated as a valid positive number. Negative and unrecognized values are not valid custom prices. Price Range adds specific lower and upper limits to this base validation. As a result, testing may produce different messages: one relates to the number format, while another relates to an amount that falls outside the configured range.

This distinction matters during troubleshooting. If a person enters letters or a negative number, the issue is not Min or Max. If they enter a valid positive amount but receive a rejection, compare it with the field's range. Do not try to solve both cases with one generic message that hides the cause.

The Amount Limit and the Form Total Are Not the Same Thing

A form may contain other Product fields, shipping, discounts, taxes, or calculated values. Price Range applies to a specific User Defined Price, not necessarily to the overall Form Total. This gives you precise control over the custom portion, but it requires a deliberate model. If a visitor enters an allowed donation amount and then receives a discount or adds another product, the payment total may differ. That is normal if it is intentional, but it must be tested.

Before launch, answer two questions: does the limit protect only the entered contribution, or the entire order? If the overall total must be limited, a single Price Range setting may not be enough. Calculations or additional server-side logic designed for the form may be appropriate here. Do not disguise that type of business rule as a simple one-field setting.

Working with Payments, Notifications, and PDFs

When an amount is valid, the form entry may go to a payment gateway, notification, and other add-ons according to the settings of the specific form. Gravity Forms' official guides recommend checking feeds and testing changes in a sandbox because payment-feed settings can have their own conditional logic. With Stripe in particular, the amount source may be an individual Product field or the complete form total.

Gravity Wiz also notes Price Range integration with Gravity PDF invoice templates. This is useful when a successful entry must produce a document showing the same amount. The integration does not remove the need for a proper testing sequence: first confirm that the range allows the intended value and blocks an invalid one, then make a test submission, and only then check the amount in the generated document. A polished PDF from one successful case is not enough to prove that validation works.

Practical Setup: a Donation Form with Suggestions and a Custom Amount

Let us look at a model that shows both the strengths and the limits of Price Range. Imagine a nonprofit project page. It needs three simple support levels, an option to enter a custom amount, and protection from values that are too small or mistakenly too large. This is a process example, not a ready-made financial policy: the organization determines its own thresholds, wording, and payment gateway.

Form Goal and Components

You need a visible choice of suggested amounts, an "Other Amount" field, contact details, and a total. In the Gravity Forms field library, add a Product field and set it to Radio Buttons. Specify several suggested options. Add "Other Amount" with a zero price. Then add a second Product field, call it "Your Amount," and switch its type to User Defined Price.

Enable conditional logic in the second field's settings. The rule should show the field when the first field containing suggested amounts equals "Other Amount." Then activate Price Range and set Min and Max for the "Your Amount" field on the Perks tab. Add a clear description of the range and the amount format used by the form below it.

Editor Setup Steps

1. Create fixed suggestions. Add a Product field with the Radio Buttons type, clear labels, and real prices.
2. Add a custom-entry option. In the same group, create a separate "Other Amount" choice with a zero price so that it does not add a second charge.
3. Create a second Product field. Set its Field Type to User Defined Price and give it a clear visitor-facing label.
4. Link field visibility to the selection. Enable conditional logic for the second field and verify the exact value of the "Other Amount" choice.
5. Set the range on the Perks tab. Enter the minimum and maximum amounts, save the form, and verify that you edited the correct field.
6. Configure payment with a deliberate amount source. In the feed settings, choose the appropriate Product field or overall total based on your form model.

Then open the public page. When a fixed option is selected, the second field should not be visible. When "Other Amount" is selected, it should appear without a page reload if the theme and page setup do not interfere with Gravity Forms JavaScript. Enter an amount below Min and submit the form. The visitor should receive a clear error next to the field. Correct the amount to a valid one and confirm that it participates in the total calculation as expected.

Test Four States

Do not test the form as a whole "by eye." Test specific states. First: the user selects a fixed amount, the custom-entry field is hidden, and the total is correct. Second: the user selects "Other Amount," enters a value below Min, and receives an error. Third: the user enters a value exactly at the lower boundary, and the form proceeds with normal processing. Fourth: the user enters a value above Max, sees an error, and does not receive an early email claiming that the donation was successful.

If a payment gateway is enabled, add a fifth state: an allowed amount completes a test payment, and the expected amounts match in the form entry, notification, and payment-service dashboard. A difference among these three places often points not to Price Range but to the payment gateway using a different amount source than expected.

A Note About Required Fields

A field being required and a range being applied are separate rules. If the custom field appears only after "Other Amount" is selected, it should usually be required while visible. When the field is hidden, conditional logic excludes it from normal input. Test both paths: the form should not require a hidden field when a fixed amount is selected, and it should not accept an empty custom price when custom entry is selected.

Dynamic Limits with Filters: When Standard Min and Max Are Not Enough

Standard Min and Max settings are sufficient for a stable rule. However, Gravity Wiz documents the gppr_price_range_min and gppr_price_range_max filters, which let a developer change a limit for all applicable fields, for a form, or for a specific form field. This extension is appropriate only when the limit truly depends on another value and the rule cannot honestly be expressed as a fixed number.

A good example is a field where a user selects a base support level and the allowed custom amount should be a symmetrical range around that selected base. Gravity Wiz's official example uses the value of another field as a foundation and calculates the minimum and maximum using a specified variation. This is now a code-based configuration: before inserting it, you need to know the form ID, the custom-price field ID, and the source field ID.

A Safe Order for Adding Code

Do not insert the filter into WordPress core, the Price Range plugin files, or a parent theme. For a small, reversible change, use a managed snippet manager or a site-specific plugin. Gravity Wiz documentation also presents this as a more convenient way to manage code snippets than accumulating changes in functions.php. Save a backup before enabling the code and work with a test form.

Below is an adaptable framework only for a case where the lower limit must come from another field. It is not a universal recipe: replace the ID numbers with your form's actual values and make sure the source field returns a valid numeric value. If your task does not require a variable limit, you do not need code.

add_filter( 'gppr_price_range_min_123_4', function( $min ) {
    // 5 - ID of the field whose value becomes the minimum amount.
    $source_field_id = 5;

    return (int) rgpost( 'input_' . $source_field_id );
} );

Here, 123 is the form ID, 4 is the User Defined Price field ID, and 5 is the source field ID. The snippet changes only the lower limit for one specific price field. It does not create a product, enable conditional logic, or fix the amount source in Stripe. If you are unsure about the identifiers, use the Min and Max settings in the interface or ask a developer to verify them.

How to Test and Roll Back a Dynamic Rule

Prepare at least three source-field values and write down the expected lower limit for each one in advance. Then test an amount one unit below it, exactly at the boundary, and above it. If the setup also uses a maximum, repeat the test at the upper boundary. Do not stop at a single combination, because an error in the source-field ID may appear only with the second option.

If you encounter an unexpected error, first deactivate the snippet and confirm that the static range works. This is a safe rollback: it returns the form to the behavior configured through the Perks tab. Then check the IDs, input-value format, and conditional logic. Do not edit the code, payment feed, and several fields at the same time, or it will be impossible to tell which change caused the effect.

Custom Error Wording Without Changing the Mechanism

Gravity Wiz documentation describes the gppr_validation_messages filter for changing messages shown when a value is below the minimum, above the maximum, or outside both limits. This is useful when you need to speak to visitors in the language of the campaign rather than with a technical phrase. The message should explain what action to take, however, rather than hide the rule. Good wording states the allowed range and asks the visitor to correct the amount. Bad wording says only "Error" and leaves them guessing what to change.

Do not localize or rewrite messages using an unverified snippet from a random forum. Use the officially documented filter, install code through a managed method, and immediately test three states: below the minimum, above the maximum, and a value within the range. If translation is critical, first review WordPress's built-in translation tools and any compatible localization tool mentioned by the developer.

How to Design Limits Without Frustrating Visitors

A successful Price Range setup begins not by opening the Perks tab, but by modeling how a person moves through the form. They have a reason to enter an amount, see the field, understand the limits, enter a value, and receive a predictable response. If any of these steps is unclear, a technically correct Min or Max will feel broken. It is better to design the range as part of the form interface rather than as a hidden administrative setting.

Define the Allowed Boundaries First

The minimum should equal the smallest value the organization is genuinely prepared to accept in this process. It does not have to be the minimum suggested amount. If a visitor may contribute less than the recommended level and that transaction is acceptable, the lower limit should reflect the allowed value while suggested options can remain higher. Conversely, if a very small payment has an objective reason to be unacceptable, it is useful to explain that briefly in the field description without turning the text into a legal notice.

Set a maximum only when there is a clear reason. It may be a campaign limit, protection against an obvious typo, or a requirement to route a large contribution through a separate channel where details can be confirmed. Do not set an arbitrary maximum if the form promises unlimited support. In that case, visitors will see a conflict between the page text and the form response. If the limit exists only because of internal process constraints, provide a contact link or clear instruction nearby for amounts above it.

Use the Same Rule in Three Places

The range should match across three layers. First is the visible description near the field. Second is the Min and Max configuration on the Perks tab. Third is the team's internal documentation and instructions if staff answer visitor questions manually. A mismatch in even one layer creates unnecessary support work: an editor changes the explanation while the rule remains unchanged, or a staff member suggests an amount that will not pass the form.

It helps to assign ownership of the rule. This does not have to be a developer. A marketer or campaign manager defines the purpose of the thresholds, an editor is responsible for the explanation, and a technical specialist checks the form settings and payment path. This short agreement is more valuable than cumbersome documentation because the limit often changes with campaign content.

Rounding, Currency, and Input Format

Price Range compares a custom price with configured limits, but the visitor first interacts with the displayed format. Make sure it is clear near the field which currency the amount uses, whether decimal values are allowed, and how the person will see the total. Do not make visitors guess whether to enter a currency sign, spaces, or a decimal separator. The most reliable option for a public form is a short hint in a natural format that matches the form's own currency settings.

If the campaign accepts whole-dollar amounts only, explain why or show examples. If decimal values are allowed, test them separately on a test page rather than assuming the field will handle local formatting exactly as expected. Do not burden visitors with technical details: they only need to understand which number to enter and what total they will see. All complex rules remain on the form side.

An Error Should Bring the Person Back to Action

A range message should not feel like a rejection with no way forward. It is useful to state the allowed range near the field in advance and ask the visitor to adjust the entered amount if an error occurs. If the team uses the documented gppr_validation_messages filter, keep the terminology consistent with the field description. For example, do not call the amount a "contribution" in one place and a "product price" in another if they refer to the same transaction. Consistent language reduces repeat attempts and support requests.

At the same time, do not include internal details in the message: form IDs, feed names, payment-provider details, or internal campaign classifications. The visitor needs only the reason for the error and a clear next step. Technical details belong in logs and team notes, not in a public form.

Accessibility and Calm Visual Hierarchy

A border color should not be the only sign of an error. The field needs readable text, and the range description should remain available before and after an unsuccessful attempt. Do not place important conditions only inside an image, tooltip, or hover effect. Basic WordPress validation and Price Range's server-side validation are more reliable when the form remains understandable without additional JavaScript.

Test the form with a keyboard: can users move to the field, see its label, and correct the value after receiving a message? Test it on a narrow screen: does the range description drift too far from the field, and does the total overlap it? This is not a separate Price Range feature, but it is where users experience its rule. If an otherwise good configuration makes the interface confusing, the task has not been completed.

Notifications, Entries, and Payment Gateways: Do Not Confuse Events

A form with a custom price passes through several events that are often incorrectly described as one "successful payment." First, the visitor submits the form. Gravity Forms then creates or processes an entry according to the configuration. Notifications, a payment feed, and post-payment actions may run afterward. Price Range operates early in this chain: it should not allow an out-of-range value to proceed through normal successful processing. What happens next depends on each individual add-on.

Configure Messages According to the Event They Represent

For a simple form without payment, an administrative notification may be sent after a successful submission. For a payment, that does not always equal a confirmed charge. Stripe documentation for Gravity Forms describes post-payment actions and the conditions under which they run. That means an email saying "New request received" may be appropriate immediately, while an email saying "Payment completed successfully" should depend on a confirmed payment-gateway event if your process requires it.

This separation protects against a common mistake: a visitor corrects the amount, the form creates an entry, but a technical gateway failure prevents the payment from being completed. If the team receives only an early email, it may mistake the request for a paid order. Name notifications so they reflect reality: "New Request" for the fact of submission and "Payment Confirmed" for an event actually reported by the provider. Exact capabilities depend on the chosen add-on, so consult its documentation.

Why You Should Not Change a Feed After Tests Have Already Been Received

In a payment setup, a feed must be active at the moment of submission for the data to be processed. Creating or correcting a feed after an entry exists will not automatically process that older entry as though the feed had been enabled from the beginning. Therefore, every significant change to the amount source, conditional logic, or post-payment processing requires a new test with a new test entry. Do not try to reconstruct whether a new setup works from the history of old requests.

Create a small tracking table for the team: date of change, what changed, test entry ID, entered amount, form total, expected notification, and actual gateway outcome. This is not bureaucracy. It prevents tests from being mixed up when a form's hints, range, and payment conditional logic are being changed at the same time. For a major campaign, keep this table with the working instructions.

What to Check When There Are Multiple Product Fields

Multiple products are not inherently a problem, but they add more cases to test. If the form includes a fixed-price ticket, a voluntary contribution, and shipping, decide in advance what the range applies to. Price Range limits the custom price field, not the overall total automatically. A voluntary contribution may pass Min and Max while the overall total differs because of the ticket and shipping. That is not an error if the payment feed uses Form Total and this matches the order model.

After adding each new Product field, retest every conditional-logic path. Pay special attention to conditionally hidden fields. A hidden field should behave as described by the form: it should not add an unexpected price, remain required, or create a total mismatch. Test not only the selected path but also the path the user cannot see at that moment.

When to Add PDFs and External Services

Add an external webhook, CRM, or PDF invoice only after the basic form successfully passes all range checks. Otherwise, one issue spreads across several systems: it becomes unclear whether the amount, submission condition, field mapping, or document template is wrong. A stable order is: static range, public form test, test payment feed, notifications, then additional handlers.

For a Gravity PDF integration, the document becomes a separate item to verify. It should receive the value recorded in the form and accepted by your process. Do not treat a PDF as proof that the payment was completed. Depending on the specific workflow settings, the document may be generated at an event that differs from actual payment confirmation.

Verifying the Outcome After Publication: Form, Entry, and Payment

After configuration, it is not enough to see the Min and Max fields in the admin area. A real check must follow the visitor path. Start on the public page while logged out, then test the form in a regular browser and at a different screen width. Make sure the range description is not hidden by theme styles and that the error message appears next to the correct field and is readable.

A Test Matrix You Can Repeat After Changing the Form

If Stripe or another payment gateway is used, extend the matrix with a test payment. Confirm that the feed is active, its conditional logic has run, and the amount selected in the feed settings matches what you tested. Gravity Forms documentation notes that entries created without an active payment feed will not begin processing retroactively after the feed is created. That is why the sequence "accept live requests first, configure the gateway later" is risky.

Separate the Evidence of Success

For a form without payment, the evidence is the correct confirmation and an entry in Gravity Forms. For a payment form, you need at least three pieces of evidence: the form passed validation, the entry contains the expected amount, and the payment service confirmed the test transaction. An administrator notification is convenient, but it does not replace payment status: an email may be triggered by form submission rather than a successful transaction.

If you generate a PDF invoice through a compatible Gravity PDF template, verify that as well. Open the document, find the custom-price line, and compare it with the entry. It is better to find any discrepancy in test mode before documents reach recipients.

Troubleshooting: Why the Range Does Not Apply or the Amount Does Not Reach Payment

Start troubleshooting with the observed symptom rather than disabling large parts of the site. Price Range has a clear responsibility: a User Defined Price Product field, its limits, and its validation response at submission. If the issue lies beyond that responsibility, such as in payment-gateway conditional logic, it is more useful to check the chain step by step.

Min and Max Do Not Appear on the Perks Tab

Symptom: the form contains an amount field, but the Price Range setting does not appear. Likely cause: the field is a Number field, Single Product, a choice list, or another Product field type. According to the official documentation, the plugin works only with User Defined Price.

What to check: open the exact field, review Field Type, and make sure Price Range is activated. Do not rely on the visible field label. Fix: create or switch a separate Product field to User Defined Price, save the form, and reopen its settings. When to roll back: if an existing fixed-price field is already used for payments, do not change its type in the live form without a copy. Add a test field and verify the total there first.

An Out-of-Range Value Is Still Submitted

Symptom: a visitor enters an amount below Min or above Max, and the form continues processing. Likely causes: a different field was edited, form changes were not saved, another form is displayed on the page, or a cache is showing old markup. In a complex setup, the test may be using a fixed Product field while the limit is configured on the "Other Amount" field.

What to check: in the editor, compare the field ID and label, save the form, then temporarily add a test page-version number to the public text. Open the page while logged out and repeat the test. Fix: clear only the cache serving the test page and make sure the shortcode or block points to the intended form. When to roll back: if refreshing the page causes errors in other parts of the form, restore the previous form copy and repeat the change one step at a time.

A Format Error Appears Instead of a Min or Max Error

Symptom: a visitor sees an invalid-amount message even though they believe they entered an appropriate value. Likely cause: the number is not recognized or an unexpected character has entered the field. Gravity Forms validates a custom price as a positive number before Price Range validation runs.

What to check: repeat the test with a simple whole number inside the range. Check whether a field mask, custom JavaScript, or local formatting is interfering. Fix: provide an example of the expected format next to the field and temporarily remove a third-party input mask if it is changing the value. When to roll back: if the issue began after a formatting script was added, disable that script and return to the standard field before testing the enhancement again.

The Form Passes the Range Check, but Payment Is Not Processed

Symptom: an allowed amount does not trigger a Price Range error, but payment is not created or the gateway reports an error. Likely cause: the issue lies in feed settings, conditional logic, the amount source, or the payment service itself. Price Range is not a payment add-on.

What to check: confirm that the payment feed is active at the time of the test submission, its conditions are met, and the selected amount source provides a positive expected total. Enable logging for Gravity Forms and the payment add-on, then perform one controlled test. Fix: correct the amount source or feed condition according to the gateway documentation, then repeat the test in a sandbox. When to roll back: if multiple feeds were changed at once, restore the last changed feed and return to the previously working test configuration without altering Price Range rules.

Amount Mismatch Error or Conflicting Amounts

Symptom: the form shows a total, but validation or payment produces Amount Mismatch, or the form and payment-service data differ. Likely cause: a Product field or one of its choices has no price configured, or the overall form total does not match what the visitor saw on the public page. The Price Range developer recommends first checking the prices of all Product fields and assigning 0 to any missing values where necessary.

What to check: review all Product fields, including choices hidden by conditional logic and the "Other Amount" choice. Compare the total before submission with the amount used by the payment feed. Fix: assign explicit prices to missing choices, then repeat tests for every conditional-logic path. When to roll back: if you added new products to fix the issue and the total increased unexpectedly, remove only the last added configuration and restore the model with one custom-price source.

The Field Does Not Appear After Selecting "Other Amount"

Symptom: suggested amounts are visible, but the custom field does not appear. Likely causes: the condition compares a different value, the page template conflicts with Gravity Forms scripts, or an optimizer has changed JavaScript order. What to check: first place the same form on a clean test page using the standard WordPress editor. If it works there, the issue is more likely related to the page builder, modal window, theme, cache, or optimization.

Fix: follow Gravity Forms' safe conflict-testing approach: make a backup, test the theme and third-party plugins one at a time, and do not disable everything on the live site simultaneously. When to roll back: if disabling the optimizer restores field behavior, do not leave protection disabled permanently. Find an exclusion for the form scripts or contact the optimizer's support team with the clean-test results.

When Gravity Forms Price Range Is a Good Choice

Gravity Forms Price Range is justified when visitors need to enter a custom amount and the form owner understands its reasonable limits. In that situation, it does one thing well: it links a User Defined Price Product field to verifiable Min and Max values, then stops submission when the user goes outside the configured range. This is simpler and more transparent than hiding a basic rule in custom code.

Before publishing, repeat tests at both limits, confirm the correct payment amount source, and check every conditional-logic path. Once those checks are complete, you can download Gravity Forms Price Range and implement the rule first in a test copy of the form. This order preserves the convenience of custom entry for visitors while giving the site owner a controlled, verifiable outcome.