Gravity Forms eCommerce Fields - WordPress Plugin

Guide to Configuring Gravity Forms eCommerce Fields for Payment Forms with Discounts and Taxes

Gravity Forms eCommerce Fields is most useful not as a standalone storefront, but as a calculation layer inside Gravity Forms. It adds tax, discount, and subtotal fields, refines how coupons and shipping behave, and provides merge tags for calculations and a clear order summary. This guide focuses on practical use rather than marketing copy: how to prepare the form, which fields to add, how to verify the calculation order, where discrepancies usually appear, and when a different tool is the better choice.

This article is written for site owners, WordPress administrators, form builders, and anyone collecting payments for events, services, deposits, small catalogs without a full store, or quote forms. We will also show how to use {subtotal}, {discounts}, {coupons}, and {order_summary}, why you should not blindly reuse the old {pricing_fields} tag in notifications, and how to diagnose errors like Amount Mismatch or Submitted Value does not match expected value.

Below, we will focus on configuring a product that is already installed. Instructions for purchasing, licensing, or bypassing activation are not relevant here. What matters is understanding how the product behaves inside a real form and how to safely verify calculations before publishing.

What Problem the Plugin Solves and Where It Works Best

Gravity Forms Pricing Fields already support products, options, quantities, shipping, and totals. The problem starts when the form stops being a simple "one product - one price" setup. A user selects multiple services, part of the cost needs to go into a separate subtotal, a discount should apply only to a specific group of items, a coupon should not reduce shipping, tax should be calculated after the discount, and the customer email needs a clean order table. That is where Gravity Forms eCommerce Fields becomes a practical extension of Gravity Forms' standard logic.

According to the official documentation, the plugin adds new pricing fields like Tax, Subtotal, and Discount, improves integration with Coupon and Shipping fields, and expands merge tags for calculations and summaries. This is not a WooCommerce replacement and not a universal payment gateway. Its strength is a calculation-based form with clear financial logic, where the user can see exactly how the total was built, and the administrator receives a readable order in the notification.

Typical use cases:

• Event registration with a base ticket, add-ons, a group discount, and tax.
• A service order form with multiple packages, extra work, a discount for a specific customer type, and a flat materials delivery fee.
• A preorder form where you need to show the subtotal before coupons, shipping, and tax.
• A custom product request where the final price depends on selected parameters, and the customer email should include a clear table.
• A form that sends data into a PDF invoice through a compatible tool, if the project already uses Gravity PDF.

It is important not to confuse this product with a full catalog, inventory, and order management system. If you need a cart, customer accounts, zone-based shipping, complex jurisdiction-based taxes, stock tracking, and order statuses like a full online store, WooCommerce is usually the more logical choice. Gravity Forms eCommerce Fields works best when the form remains the main interface and the calculation needs to stay transparent and manageable.

Who This Approach Fits and When Another Tool Makes More Sense

Before installing it, be honest about the problem you are solving. The plugin is a strong fit when you already use Gravity Forms, the form includes Pricing Fields, and the main pain point is taxes, discounts, subtotals, and notifications. It does not force you to build a store around WooCommerce or move the user into a separate cart flow. That makes it useful for services, events, applications, donations with add-ons, quote forms, and simple sales.

Good-fit projects

Gravity Forms eCommerce Fields is worth considering if your site collects payments or requests through forms and the buyer needs to see a transparent breakdown. For example, a course organizer may want to show the registration cost before discount, an early-bird discount, tax, and the final total. An agency may want to send the client a clean email listing the selected services. A small manufacturer may want to accept orders for a configurable bundle without setting up a full store.

The plugin is especially useful when the administrator needs to change the pricing logic quickly: enable or disable a discount, limit it to specific products, add a separate subtotal for a product group, output {order_summary} in the confirmation or notification, and keep the user inside the form while calculations update immediately.

When the product may be unnecessary

If the form contains only one Product field and one Total, with no coupons, taxes, discounts, order summary, or calculation merge tags, the plugin may be unnecessary. Standard Pricing Fields are enough for a simple "product plus total" scenario. It also will not solve problems related to order accounting, stock management, a complex catalog, customer accounts, or a full shopping cart.

A separate case is projects with legally complex tax requirements. The Tax Field in this plugin works as a configurable percentage field inside the form. That is useful for transparent calculations, but it does not replace tax advice, automatic rate detection by customer address, or specialized tax automation services. In those projects, use the plugin only as part of a confirmed business workflow.

Practical rule: if the main purchase screen is a Gravity Forms form rather than a product catalog, Gravity Forms eCommerce Fields can handle the calculation side. If the main purchase screen is a cart, product pages, and order management, it is better to design the process around WooCommerce or another ecommerce platform.

What to Check Before Installing on a Live Site

Preparation is not just a formality. The plugin changes how pricing fields and the order summary are calculated, so a form issue may show up not as a nice warning, but as an incorrect total, a failed payment, or a mismatch between the amount on the page and the server-side validation. Before installing it on a production site, run through a short technical review.

Core dependencies

• The site must have Gravity Forms installed and working, because this product extends its pricing fields.
• The form should use Pricing Fields such as Product, Quantity, Option, Shipping, Total, or Coupon if coupons are part of your workflow.
• If you use a Coupon Field, make sure the official Gravity Forms Coupons Add-On is active, because the standard Coupon Field is available only when that add-on is installed.
• If the form accepts payments, verify the payment add-on, test mode, and final amount consistency before sending users to the gateway.
• If the form is embedded inside a page builder layout, check caching and JavaScript optimization. Dynamic calculations depend on Gravity Forms scripts working correctly on the front end.

Backup and a test copy of the form

Do not start by editing your only live form. Duplicate the form first and configure the pricing logic in the copy. This is especially important if the original form is already collecting submissions, sending notifications, using conditional logic, or connected to payments. In Gravity Forms, it is easy to end up in a situation where everything looks correct visually, but a hidden pricing field still participates in server-side validation and breaks submission.

A safe workflow looks like this:

1. Create a site backup using your hosting provider's standard tools or a backup plugin.
2. Create a copy of the form and give it a clear name, such as Test - Event Registration.
3. Disable real customer notifications or replace recipients with a test email address.
4. If a payment gateway is involved, use test mode and a test page blocked from indexing.
5. After configuration, compare the amount shown in the form, the entry in Entries, the notification, and the payment attempt.

Option fields and clean values

Gravity Forms documentation highlights an important detail for Product and Shipping fields: if option labels contain special characters, HTML, ampersands, commas, parentheses, or similar symbols, it is better to enable Show Values and assign simple, unique values. For calculations, conditional logic, and submission validation, this is often more important than it looks. The user sees a polished label, but the system should receive a stable value without extra punctuation.

Quick pre-check: open your Product fields, Shipping choices, and Option fields, review both labels and values, and make sure every option has a price. If an option should be free, enter 0 instead of leaving the field blank. That reduces the risk of amount errors and makes it easier to diagnose issues if you hit Amount Mismatch.

Installation and Initial Validation in WordPress

Gravity Forms eCommerce Fields is part of the Gravity Perks ecosystem. According to Gravity Wiz documentation, Perks are managed through Spellbook: after installing Spellbook, the user opens Spellbook - Perks, finds the required perk, and activates it. This article will not cover purchasing or licensing, but it is important to understand that activating the perk itself is only the first step. The real configuration happens inside the form editor, in the Pricing Fields section.

What should change after activation

After activation, open your test form in the Gravity Forms editor. In the Pricing Fields group, the new eCommerce fields and the improved behavior of related fields should now be available or visible. Gravity Wiz documentation states that Tax, Subtotal, and Discount live under Pricing Fields. If you do not see them there, do not start changing the form at random. First check whether the perk itself is active, whether Gravity Forms is still enabled, whether WordPress shows a plugin error, and whether the current user role has any restrictions.

Quick check with an empty form

The fastest way to confirm the product is working is to create a temporary test form with one Product field, one Subtotal field, one Discount field, one Tax field, and one Total field. Do not move your complex live form over immediately. The goal is to confirm that the fields appear, totals update when the product changes, discount and tax affect the result in the expected order, and the form submits without errors.

1. Add a Product field with a simple fixed price.
2. Add a Subtotal field and leave it set to include all products if you are testing the general scenario.
3. Add a Discount field as either a fixed or percentage discount.
4. Add a Tax field with a percentage rate.
5. Add a Total field and open the form in preview or on a test page.
6. Submit an entry and compare the total in the form with the entry in the admin panel.

If this minimal form works, the issue in the real form is probably not the plugin installation itself, but the specific logic: hidden products, conditions, empty prices, formulas, or a script conflict.

Subtotal, Discount, and Tax Fields: Calculation Logic Without Confusion

The real value of the plugin is not the number of new fields, but where they sit in the calculation chain. According to Gravity Wiz developer notes, the processing order is Subtotal, then Discounts, then Coupons, then Shipping, then Taxes, and finally Total. Keep that sequence in mind whenever a setup seems questionable.

Subtotal Field: a separate control point for the subtotal

The Subtotal Field shows the sum of line items before taxes and discounts. It can apply to all products, selected products, or all except selected products. The documentation points out a critical detail: excluding a product from a specific Subtotal field does not exclude it from the overall order subtotal. Those are different things. This type of subtotal is meant to give the user feedback and simplify formulas, not to silently remove a product from the order.

A good example is a conference registration form. There is a main ticket, a workshop, a dinner add-on, and shipping for printed materials. You can create a subtotal called "Participation" that includes the ticket and workshop but not shipping. The user sees the education-related portion separately, while the overall Total still calculates the full order according to the form's rules.

When to add multiple Subtotal fields

Multiple subtotals are useful when the form sells different groups of items: services, materials, shipping, surcharges. But do not add a subtotal for every individual product. Otherwise, the user gets unnecessary accounting-style detail, and troubleshooting becomes harder. Group only the parts that genuinely help explain the order or are needed for formulas.

Discount Field: a controlled pricing adjustment

The Discount Field can be either a fixed amount or a percentage. According to the documentation, it can apply to the overall form total, specific products, or all products except selected ones. In practice, this is cleaner than trying to create a discount with a negative Product field. The Discount Field clearly tells the user that it is a reduction and fits better into the order summary.

If the discount should apply only under certain conditions, use conditional logic. For example, a "Participant Type" field can display the discount only for students, and a "Ticket Quantity" field can trigger it only for group purchases. The key is not to hide the discount in a way that shows one amount to the user while the server receives another. A hidden pricing field must either be properly excluded or have a predictable value.

Tax Field: tax as a percentage applied after discounts and coupons

The Tax Field supports percentage values. It can apply to all products, specific products, or all products except selected ones. Gravity Wiz documentation notes that tax affects the Total, but is not included in Subtotal and Discount amounts. Shipping is included in tax and Total, but automatically excluded from discounts and coupons. That means the tax field should be validated not only against the overall amount, but also together with shipping and coupons.

If tax should apply only to part of the order, configure it to include only the relevant products. Do not hide that logic inside a complicated formula in a separate Product field when the rule can be expressed directly through Tax Field settings. The closer your logic stays to the built-in field types, the easier it will be to explain the result to a client and to find mistakes later.

Coupon and Shipping after plugin activation

The Coupon Field remains a Gravity Forms field and is available when the Coupons Add-On is active. Gravity Forms eCommerce Fields changes the integration: coupons do not include shipping, do not affect Subtotal or Discount fields, and appear in the totals section of the order summary. The Shipping Field also keeps its role, but shipping is not included in subtotal, discounts, or coupons, while still being included in tax and the final total. These details are exactly what usually explain the question, "Why is the amount different from what I expected?"

Result check: after adding discount, coupon, shipping, and tax, create three tests: without a coupon, with a coupon, and with shipping. In each test, compare Subtotal, Discount, Coupon, Shipping, Tax, and Total. If one line does not match expectations, fix that field rule rather than trying to rewrite the whole calculation at once.

Detailed Configuration After Installation: From a Simple Calculation to a Reliable Form

It is better to configure the form step by step instead of taking a "let's add everything and see what happens" approach. Follow the chain: products - options - subtotal - discounts - coupons - shipping - tax - total - notifications. That way, you can stop at the exact point where the amount starts going wrong.

Step 1. Clean up the Product fields

The Product field is the foundation of the entire calculation. In Gravity Forms, it can be Single Product, Drop Down, Radio Buttons, User Defined Price, Hidden, or Calculation. For most pricing forms, it is best to start with simple types: Single Product for a fixed item, Drop Down or Radio Buttons for package selection, Quantity for quantity, and Option for product add-ons.

Check the following:

• Every option has a price, even if that price is 0.
• Choice values are unique and do not depend on decorative labels.
• Hidden products are used only where you clearly understand why the user should not see them.
• Calculated Product fields do not create a loop with {subtotal}.
• The Quantity field is connected to the correct product and does not allow unexpected decimal values where a whole-number count is required.

Step 2. Add Subtotal only where it helps the user

The Subtotal Field does not have to appear just once. But each subtotal should answer one question: "What part of this order should the user understand separately?" If there is no answer, leave a single general subtotal or do not add one at all. In more complex forms, it is useful to create subtotals for groups such as services, materials, participation, or add-ons.

The setup depends on whether the subtotal should include all products or only a selected group. If the field is needed for a formula, note its ID, because the specific merge tag looks like {subtotal:9}, where 9 is the ID of a particular Subtotal field. This is the official workaround for cases where the general {subtotal} cannot safely be used in multiple calculated Product fields because of recalculation loop risk.

Step 3. Configure Discount without chaining discounts

Gravity Wiz documentation points out a limitation: discount calculations are based on the Subtotal field, so chained discounts are not supported. If the form contains two Discount fields of 10% each, the second one should not expect the first one to have already reduced the calculation base. Both will reference the original subtotal. That is not a bug, but a product rule.

If your business logic requires a cascading discount model, it is usually better to rethink the scenario. In many cases, you can replace the chain with one Discount field using the correct percentage, conditional logic, or a separate calculated field, but do not promise a pricing mechanic the plugin does not support. For marketing discounts, one clear rule is usually enough: "early registration discount," "group discount," or "discount for a selected package."

Step 4. Add the Tax Field and verify the tax base

The Tax Field works with percentages. Choose whether it applies to all products, only selected products, or all except selected products. If the form includes shipping, remember that shipping is included in taxes and Total. If that does not match your legal or business scenario, do not try to "tweak" the final amount manually without validation. It is better to confirm the pricing rules and choose a field structure that reflects the real tax base.

Step 5. Rewrite confirmations and notifications using {order_summary}

Gravity Forms can output {pricing_fields}, but Gravity Wiz explicitly recommends using {order_summary} instead for this product, because the standard merge tag may display incorrect information when the pricing field logic has been modified. The newer {order_summary} outputs a preformatted HTML table with products, subtotal, discount, coupons, shipping, taxes, and grand total.

Review both Confirmations and Notifications. In the admin email and the customer email, it is better to replace the old order block with {order_summary}, then send a test submission. If the email passes through a template or PDF integration, do not assume all output channels behave the same way. Validate the email, the on-screen confirmation, and the PDF separately if PDF output is used.

Merge Tags and Order Summary: What to Output in Emails and Calculations

Merge tags are one of the strongest parts of this product. They connect the visible form, calculated fields, notifications, and confirmations. Gravity Forms eCommerce Fields adds {subtotal}, {coupons}, {discounts}, and {order_summary}. Each one has a specific job, so it is not a good idea to use the same tag everywhere.

{subtotal} for formulas and control totals

{subtotal} returns the sum of all product prices and can be used in Number and Product field calculations. If it is used inside a Calculated Product, that calculated product is automatically excluded from the subtotal calculation. But there is an important limitation: the general {subtotal} cannot be used in multiple calculated Product fields, or a recalculation loop will occur. The official workaround is to create a separate Subtotal field, exclude the calculated products, and use that field's tag in the format {subtotal:ID}.

In practice, that means this: if you need one calculated fee, you can carefully use the general subtotal. If you have multiple calculated product lines, it is better to create dedicated subtotal fields for each piece of logic. Yes, that adds one more setup step, but it makes the form easier to read and reduces the risk of endless recalculation.

{discounts} and {coupons} for transparent reporting

{coupons} returns the total coupon deductions, while {discounts} returns the total of discount and coupon deductions together. This is useful when a notification or internal calculation needs to separate a "field-based discount" from a "coupon," or when you want to show the total reduction in price. In a plain customer email, you may not need to output both if you already use {order_summary}. But for internal notifications to a manager, these tags make it much easier to see why the total went down.

{order_summary} as the main order table

{order_summary} works best as the primary user-facing order output. It shows the product list, subtotal, discounts, coupons, shipping, taxes, and final amount. On the confirmation screen, it helps the user verify immediately that the form captured the correct set of items. In the customer notification, it works like a receipt or a short order specification.

If you want to display the order summary directly inside the form before submission, Gravity Wiz documentation suggests using {order_summary} together with GP Preview Submission or Live Merge Tags in GP Populate Anything. Do not add that layer if you do not have the matching tool. Without it, the merge tag usually resolves in the confirmation or notification rather than in an arbitrary place inside the live form.

When a small CSS tweak helps

The official product FAQ describes an approach using a "pseudo Total" via a Number field and {subtotal} when you need conditional logic based on the form amount. It also mentions the gf_total CSS class for styling a Number field to look like a Total field. If you use that approach, it is safer to add the CSS in a child theme or your theme's standard custom CSS area rather than editing Gravity Forms or Gravity Wiz files.

Below is a minimal appearance tweak. It does not change the calculation, does not interfere with submission, and is easy to roll back by removing the CSS. Before using it, add the gf_total class in the Custom CSS Class setting of the target Number field.

.gform_wrapper .gf_total input {
  font-weight: 700;
  background: #f7fafc;
  border-color: #8aa4c8;
}

.gform_wrapper .gf_total .gfield_label {
  font-weight: 700;
}

The validation is simple: open the form on the front end, change the selected products, and confirm that the field looks like a total while not breaking the calculation or becoming editable where the user should not be able to change the amount. If the style conflicts with the theme, remove the CSS and keep the default appearance.

Field Architecture: How Not to Turn the Form into an Unmanageable Calculator

In complex forms, the main mistake is usually not a specific tax percentage but the architecture itself. An administrator adds a Product field for every possible surcharge, hides some fields with conditions, uses negative prices as discounts, then adds a calculated product for a fee, and finally tries to output a summary in the email. Visually, the form may still work, but a month later it becomes hard to maintain. No one understands which line is a real order item, which line is an internal calculation, and which line is just user guidance.

Gravity Forms eCommerce Fields works best when you separate fields by role from the start. Some fields create actual order items. Some explain an intermediate amount to the user. Some change the amount: discount, coupon, shipping, tax. Others exist only for logic and should not look like products. That separation makes the form predictable and much easier to troubleshoot.

Fields that create real order lines

Product, Option, and Quantity fields should describe what the user is actually paying for. If the user is buying a ticket, a service, a bundle, or an add-on, that should be a Product or Option. If a field exists only for an internal formula, do not name it like a product or output it in the email unless there is a clear reason. Otherwise, the customer will see a strange order line and the manager may mistake it for a real item.

For products with mutually exclusive choices, use Drop Down or Radio Buttons. For add-ons, Option fields are usually the better fit. User Defined Price makes sense only when the user is truly entering the amount: a donation, an agreed surcharge, or a deposit. If the price should be calculated by formula, use a calculated Product, but do not mix it with multiple subtotals unless you have separately tested for loop issues.

Fields that explain the calculation

The Subtotal Field is not just "one more total." It is an explanatory line. It tells the user: "Here is the amount for the selected items before discounts, coupons, shipping, and taxes." If the form sells several groups of services, a subtotal can show one group separately. For example, "Participation Cost" and "Additional Materials" are more meaningful than one long list with no intermediate checkpoints.

But too many subtotals are counterproductive. If you show five subtotals in a row, the user starts comparing lines and no longer understands which amount is the base for the discount or tax. A well-designed form usually shows one or two clear subtotals and lets the order summary explain the rest after submission.

Fields that change the amount

Discount, Coupon, Shipping, and Tax should stay in their intended roles. Do not use Shipping as a hidden service fee if it is not actually shipping. Do not use Tax as a general rush surcharge. Do not use a negative Product as a discount when the Discount Field matches the meaning. Those shortcuts may feel fast, but they make the order summary less transparent and testing much harder.

If a discount depends on the selected package, configure the Discount Field for specific products or enable it with conditional logic. If a promo code should be validated as a code, use the Coupon Field with the Coupons Add-On. If tax should be shown to the user as a separate line, use the Tax Field. When each financial operation uses the right field type, the order summary becomes clearer for both the user and the administrator.

Internal fields and labels for the team

In larger forms, it helps to agree on naming conventions in the admin area. The user may see a short label, while the administrator needs to understand the field's role. For example, an internal field can be named Subtotal - services only, while the public label is "Services Subtotal." If a field uses a specific subtotal ID in a formula, document that in a form note or in the admin-only field description.

Bottom line: design field roles first, then configure percentages and conditions. In ecommerce forms, a messy architecture is almost always more expensive than a careful setup at the start.

Compatibility with the Page, Theme, Cache, and Builders

Gravity Forms calculations do not happen only on the server. On the front end, the user sees totals update dynamically, which means the form depends on scripts loading correctly, clean HTML markup, conditional logic, and browser events. Because of that, the same form may work in Gravity Forms preview but fail on the live page if the theme or optimization layer interferes with the scripts.

Cache and JavaScript optimization

If the site uses JavaScript bundling, minification, defer, or delay, test the payment form page separately. Dynamic fields, conditional logic, coupons, and total updates should work immediately after the form loads and after every selection change. If optimization delays the Gravity Forms script until the first interaction or changes the load order, the amount may not update when it should.

A practical approach is to test the form first with optimization disabled on a test page. Then re-enable optimization and exclude either the form page or specific scripts if the problem returns. Do not conclude that "the plugin does not work" until the form has been tested without aggressive caching.

Page builders and blocks

The form may be embedded through a shortcode, block, widget, or page builder element. What matters is that the builder does not cache the form HTML as a static block or move scripts into a place where they no longer initialize correctly. Be especially careful on pages where the same form embed is duplicated inside a popup, tab, accordion, or hidden container. Hidden containers sometimes interfere with calculations and conditional logic because the form initializes before the user can actually see it.

If the form needs to open in a popup, test it first on a normal page without the popup. Then move it into the popup and compare the behavior. If the problem appears only inside the popup, the cause is usually not the Tax or Discount Field itself, but the form initialization after the container opens.

Theme and custom styles

The theme may affect the appearance of tables, labels, radio buttons, selects, inputs, and total rows. That is not always a problem, but the order summary and pricing fields still need to remain readable. Check the mobile view: long product labels, discount or tax rows, and total values should not overlap. If the theme styles tables aggressively, the order summary may look fine in an email notification but appear too compressed on the confirmation page.

Fix these issues with child theme CSS or custom CSS, not by editing plugin files. The CSS should be narrowly scoped to the specific form or container so it does not change every table on the site. If the form has a unique ID, use it in the selector and test the result on both mobile and desktop.

Multilingual setups and translations

Form fields, confirmations, and notifications are usually translated at the form level. Perk system strings can be translated with standard tools like Loco Translate, as noted in Gravity Wiz documentation. Do not edit plugin files just to translate them. After translation, review not only labels but also the order summary: line names, currency, number formatting, and the customer email should all feel natural in the selected language.

If the site uses a multilingual plugin, do not change option values just for translation. User-facing labels can be translated, but values used in conditional logic and calculations are safer when kept stable. That reduces the risk of a discount rule or selection check failing after translation.

Test Matrix for a Form with Tax, Discount, and Coupon

One test submission proves almost nothing. In an ecommerce form, combinations matter: with and without a coupon, with and without shipping, with and without a discount, with visible and hidden Product fields. A test matrix helps you avoid missing edge cases and quickly identify the line where the calculation starts to drift.

Build the table before publishing. It does not need to become a separate ten-page document. A short matrix with the expected subtotal, discount, coupon, shipping, tax, and total is enough. If the form is important to the business, save that matrix with the task or in the site's internal documentation. The next time Gravity Forms, Gravity Perks, the theme, or the optimization stack is updated, you will be able to rerun the same checks.

How to record the expected result

Do not rely on "it looks about right." For each test, write down the expected numbers. For example: base ticket, dinner, subtotal, discount, coupon, shipping, tax, total. If the form amount differs, you will immediately know where to start looking. Without a written expectation, the discussion turns into guessing: is the tax misconfigured, did the coupon apply in the wrong place, or is shipping included in the base when you forgot that rule?

When to roll back a configuration

Rollback is not only for fatal errors. If you add a new Discount Field and can no longer explain why the total ended up where it did, it is better to disable that field and return to a simpler form. First get the base amount working clearly, then add one condition at a time. This matters even more in payment forms: the user should never pay an amount the administrator cannot reproduce manually.

After major changes, save a form export or create a new copy. Gravity Forms makes it fairly quick to work with duplicates, and for ecommerce logic that is far cheaper than reconstructing discount rules from memory later.

Practical Example: Event Registration with a Group Discount and Tax

Let us walk through a scenario that shows the product well. You need to build a seminar registration form: the attendee selects a ticket, can add dinner, receives a group discount when buying multiple seats, sees tax, and gets an email with the order summary. This is not a universal template for every site, but it shows the real relationships between the fields.

Goal

On the public page, the user should see the selected items, the subtotal before discounts and tax, the discount, the tax, and the final amount, then receive a clear confirmation after submission. The administrator should see the same data in the entry and notification.

Preparation

• A test Gravity Forms form already exists.
• Gravity Forms eCommerce Fields is active.
• If coupons are needed, the Coupons Add-On is active and a test coupon has been created.
• The payment gateway, if used, is running in test mode.
• Notifications are temporarily being sent to the administrator rather than real customers.

Configuration steps

1. Add a Product field called "Seminar Ticket" with a fixed price, plus a Quantity field if multiple seats can be purchased.
2. Add an Option field called "Dinner After the Seminar" or a separate Product field if this should appear as its own order line.
3. Add a Subtotal Field called "Participation Subtotal" and include the ticket and dinner if both belong to the participation portion.
4. Add a Discount Field called "Group Discount." Choose a percentage or fixed amount and configure conditional logic so the discount appears only for the required seat count or participant type.
5. If coupons are used, add a Coupon Field and confirm the coupon exists in the Gravity Forms Coupons Add-On.
6. Add a Shipping Field only if there is actual delivery of materials. Do not use shipping as a hidden surcharge if it is really just a normal service.
7. Add a Tax Field and choose which products the tax applies to.
8. Add a Total Field and place it after all fields that affect the amount.
9. Insert {order_summary} into the confirmation and notification so both the customer and the administrator see the same order structure.

Validation

Create several test submissions: one ticket without dinner, multiple tickets with the discount, a ticket with a coupon, an order with shipping, and an order without shipping. For each submission, record the expected amount manually: subtotal, discount, coupon, shipping, tax, total. Then compare it against the public form, Entries, and the email.

A detail that often breaks the scenario

If a discount or product is hidden through conditional logic, make sure the field is actually visible at submission time when its value is supposed to be part of the calculation. The Submitted Value does not match expected value error is often tied to conditional logic and hidden Product fields. If a field should be excluded, its state must match Gravity Forms logic rather than being visually hidden only by the theme or CSS.

Validating the Result Before Publishing the Form

Once the form looks ready, do not publish it immediately on a live traffic page. First test it from three perspectives: user, administrator, and payment system. That three-way review saves a lot of time: the user sees the visible total, the administrator sees the entry, and server-side validation protects against amount tampering.

User-side test

Open the form in conditions that are as close to real as possible: a normal WordPress page, the active theme, optimization plugins enabled, and the same block or shortcode that will be used on the site. Change product selections and check whether Subtotal, Discount, Tax, and Total update without a page reload. If the amount updates only after submission or does not update at all, check the browser console for JavaScript errors.

Admin-side test

After submission, open the entry in Gravity Forms Entries. Compare the selected products, quantities, discounts, tax, and total. If the email shows one thing, the entry shows another, and the form shows a third, start with the order summary and merge tags. Make sure the notification uses {order_summary} rather than the old {pricing_fields}.

Payment test

If the form accepts payment, the amount on the page must match the amount received by the payment add-on. An Amount Mismatch error or payment failure often points to a missing price in Product choices, a hidden field, a JavaScript conflict, or a difference between client-side and server-side calculation. Do not start with the payment gateway. First verify the prices of all Product fields and the submitted total.

After that review, you can move the settings from the copied form into the working form or replace the form on the page. If you are changing an existing form that already has traffic, it is better to choose a low-activity period and keep the old copy available for a quick rollback.

Special Scenarios: PDF Invoices, Conditional Amounts, and Payment Fees

This product includes a few scenarios that are worth discussing separately. Not every site needs them, but they often come up in commercial forms.

Invoices through Gravity PDF

Gravity Wiz documentation describes integration with Gravity PDF Invoicing Templates. The idea is that flexible Tax and Discount fields can flow into business-oriented PDF invoice templates if the project uses compatible templates. This is useful for forms where you need a PDF with tax, discount, and order line items after submission.

Test the PDF separately. One comment on the official order summary markup snippet shows that not every order summary change is automatically reflected in Gravity PDF. So for a PDF-based workflow, it is not enough to see a nice email. You need to create a test entry, open the PDF, and confirm that the template actually displays the required lines.

Conditional logic based on the amount

Gravity Forms does not always allow you to use the actual form total directly in conditional logic. In the Gravity Wiz FAQ, the suggested workaround is to create a Number field, enable calculation, and insert {subtotal} to get a "pseudo Total" that can be used in conditional logic rules. This is useful if you want to show an extra block once the order reaches a certain amount.

Use that approach carefully. The field should make sense to the administrator, should not confuse the user, and should never replace the real Total. A better admin label might be "Subtotal for logic," and the field should only be hidden or styled after proper testing.

Payment processor fees

The Gravity Wiz FAQ includes a sample formula for adding a Stripe fee through a calculated Product field based on {subtotal}. That is technically possible, but the solution must match your business rules and the payment provider's policies. This article does not give legal advice. From the form's perspective, only one thing matters: if you add a fee as a calculated product, it must be clearly visible to the user, must not create a loop with subtotal, and must pass payment testing.

Product-specific discounts and coupons

The Discount Field is the closest option for product-specific discounts because it can apply to particular products. But the documentation clarifies that this is a separate logic from the Coupon Field and does not work directly as a product-specific coupon. If you need a coupon that applies only to selected products, review the official Gravity Wiz snippets and the limitations of the exact solution you plan to use. Do not promise a client a "coupon for only one item" until you have validated it in the form.

Why Calculations Can Break and How to Diagnose Them

Errors in ecommerce forms rarely look the same. Sometimes the user sees the wrong Total. Sometimes submission fails during value validation. Sometimes payment fails because the amount does not match. Below is not a generic "clear the cache" checklist, but troubleshooting focused on common Gravity Forms eCommerce Fields and Pricing Fields symptoms.

Incorrect Total or tax is calculated from an unexpected amount

Symptom: the user selects products, the subtotal looks correct, but the final amount is higher or lower than expected. This often appears after adding a Tax Field, Shipping Field, or Coupon Field.

Possible cause: an incorrect assumption about the calculation order. Shipping is excluded from discounts and coupons, but included in taxes and total. The Tax Field affects Total, but is not included in Subtotal and Discount amounts. Coupons also do not affect Subtotal or Discount fields.

What to check: temporarily disable coupon, shipping, and tax one at a time, submitting a test entry after each change. If the issue disappears after disabling shipping, verify whether shipping is really supposed to be taxable. If the issue is related to the coupon, review the Coupons Add-On and the coupon rule itself.

How to fix it: rebuild the form so each financial line uses the correct field type: shipping as Shipping, discount as Discount, tax as Tax, and the base item as Product. Do not use negative Product fields as a discount substitute when the Discount Field handles the scenario more clearly.

Submitted Value does not match expected value

Symptom: the form looks complete, but submission throws a submitted versus expected value error.

Possible cause: conditional logic is hiding or showing Product fields differently from what the server-side validation expects. The user may have submitted a field value that is considered invisible or invalid at validation time.

What to check: walk through the scenario slowly, changing each condition and watching which Product fields become visible. Disable CSS-based hiding if it is being used instead of native conditional logic. Confirm that choices have simple values.

How to fix it: use Gravity Forms' built-in conditional logic, do not hide important pricing fields with styles alone, assign unique values, and test the form on the live front end.

Amount Mismatch or a payment error

Symptom: the amount on the page is one thing, but submission or payment throws a mismatch error.

Possible cause: missing prices in Product choices, hidden fields, a JavaScript error, an optimization conflict, or a mismatch between the client-side and server-side calculation. Gravity Wiz troubleshooting officially recommends confirming that all Product fields and choices have prices, using 0 where needed, and comparing the submitted total with the total shown on the front end.

What to check: open the form without minification or deferred script loading, inspect the browser console, then compare the test entry with the total shown on the page. Do not jump straight into Stripe, PayPal, or Square settings until you have confirmed the form total is stable.

How to fix it: fill in missing prices, temporarily disable conflicting JavaScript optimization on the form page, simplify the conditional logic, and retest payment in test mode.

{order_summary} does not match the PDF or an older email

Symptom: the email or confirmation shows the correct order summary, but the PDF or another output channel looks different.

Possible cause: different channels use different templates and do not necessarily apply the same markup filter. In comments on the official order summary markup snippet, people discussed cases where a change was not reflected in Gravity PDF.

What to check: test the email notification, confirmation page, and PDF separately. Make sure each channel really uses {order_summary} or a compatible mechanism.

How to fix it: use {order_summary} for email and confirmation. For PDF, rely on Gravity PDF documentation and the exact template you are using rather than copying an email snippet as if it were a universal solution.

JavaScript errors break dynamic calculations

Symptom: the amount does not update when options are selected, the discount does not appear until submission, or the subtotal becomes "stuck."

Possible cause: a JavaScript error on the page, an optimization conflict, aggressive caching, a page builder, or a third-party script. Gravity Wiz documentation specifically recommends checking the browser console because script errors can break front-end calculations.

What to check: open developer tools, go to the Console tab, and repeat the product change. If the error appears only after a certain optimization script loads, exclude the form page or Gravity Forms scripts from optimization.

How to fix it: disable bundling and deferred loading of critical scripts on the form page, run a theme and plugin conflict test, then bring optimization back gradually.

Product Video: Automatic Subtotal for Selected Products

The official Gravity Wiz page links to a specific video covering auto-calculated subtotals consisting of specific products. It is useful because it addresses a narrow intent: how the subtotal works for a selected group of Product fields rather than a general Gravity Forms overview. Watch it after the sections on the Subtotal Field and merge tags so you can connect the visual walkthrough to the configuration logic.

When Gravity Forms eCommerce Fields Is the Right Choice

Gravity Forms eCommerce Fields is worth using if you need a WordPress form with transparent ecommerce logic: products, subtotals, discounts, coupons, shipping, taxes, and a clear order summary in the email or confirmation. It is a strong tool for pricing forms, registrations, services, simple orders, and any scenario where Gravity Forms remains the user's main interface.

Before launch, do not stop at a visual check. Create a test copy of the form, verify the calculation order, replace old summaries with {order_summary}, run several submissions under different conditions, and compare the final amount on the page, in Entries, in the notification, and in test payment flow. If everything matches, you can get the WordPress version and move on to a careful validation on your own site.

If what you really need is not calculation inside a form but a full store with a cart, catalog, order statuses, and more complex logistics, do not force a form to behave like a store. In that case, it is better to choose a store-oriented architecture and leave Gravity Forms for requests, quizzes, leads, and focused payment scenarios.