Gravity Forms Pay Per Word - WordPress Plugin

Guide to Setting Up and Using Gravity Forms Pay Per Word

Gravity Forms Pay Per Word is not meant for a standard contact form. It is built for situations where the price of a request depends on the length of the text. In this guide, we will walk through how to connect a Gravity Forms text field to a product field, set a per-word price, decide when to use a base price, limit the minimum and maximum text length, and verify that the final amount matches what the user sees.

This article is intended for a site owner, webmaster, or service editor who needs to accept orders for copywriting, classified ads, translation, proofreading, product descriptions, legal documents, or similar work. It does not cover license purchasing, and it is not meant to replace the official documentation. The goal is different: to provide a practical roadmap for what to install, which fields to create, which settings to review, where calculations usually break, and how to safely get the form into a working state.

It is important to understand where this solution fits in the WordPress ecosystem. Gravity Forms Pay Per Word is a separate add-on from the Gravity Perks suite by Gravity Wiz, and it runs on top of Gravity Forms. That means before you start configuring it, you should already have Gravity Forms working, understand the basic structure of form fields, and decide in advance how payment or request handling will work: cost calculation only, a quote request, a paid form, or the first step toward a manually issued invoice.

How the Plugin Turns Text Into an Order Price

The main idea behind the plugin is simple: the form includes a field where the user enters text, and a product field that receives a price based on the number of words in that text. In practice, though, it helps to see the full chain, not just the final amount. The user types or pastes text into a Paragraph or Post Body field. The plugin counts the words in that field, multiplies them by the configured price per word, applies the base price and base word count if set, and then updates the price of the matching product in the form.

This setup is different from a standard calculator based on number fields. In a typical calculator, the user enters the quantity manually, for example 500 words or 3 pages. Here, the text itself is the source of the quantity. That reduces errors because the client does not need to count words separately and manually copy the number into another field. The price changes while the user is typing, so the visitor sees an estimated cost before submitting the form.

According to the official documentation, Pay Per Word works with Paragraph and Post Body fields. The setting is enabled on a Single Product field through the Perks tab. That is the key architectural detail: the plugin does not turn a text field into a payment field by itself. Instead, it adds pricing logic to a Gravity Forms product field. In most cases, the form needs at least three elements:

• A Paragraph or Post Body field where the user enters the text to be counted.
• A Single Product field from the Pricing Fields group, where Enable Pay Per Word is turned on.
• A Total field, if the user needs to see the final amount for the full request or payment.

If the form includes additional paid services, they should be set up using Gravity Forms pricing fields: Product, Option, Quantity, Shipping, or other compatible fields. This matters for payments because Gravity Forms payment add-ons typically rely on the product total and overall form total, not on an arbitrary text block.

Quick check: if the price does not change while typing, do not start with the payment gateway. First, test the "text field -> Single Product -> Total" chain on a simple test page with no cache and no extra scripts.

Where Gravity Forms Pay Per Word Is Actually Useful

The best use case for this plugin is a service with a clear per-word pricing model. That is not limited to copywriting. It also works well for classified ads, translation, editing, product descriptions, reviews, paid listings, custom instructions, transcription, and documents where workload depends on text length.

The plugin is especially useful when the client needs to understand the price quickly without going back and forth by email. If a site sells proofreading, a visitor can paste in a text sample, see the amount immediately, and submit the request. If an editorial site accepts paid ads, the user can type the ad text, let the form count the words, and see the publishing cost. If an agency offers translation services, the form can provide a preliminary estimate, while a manager later adjusts the final quote based on language pair, subject matter, and urgency.

Use Cases Where Per-Word Pricing Makes Sense to the User

The more transparent the pricing rule is, the fewer disputes you will have after submission. Good examples look like this: "the first 100 words are included in the base price, and each additional word is billed separately" or "the price is calculated based on the actual number of words in the text." The user can see how their input affects the price, and the site owner receives a structured request.

• Paid listings: the user writes an ad, the form counts the words, and the publishing price is displayed.
• Editing and proofreading: the client pastes in a text, gets a quick estimate, and submits the material for review.
• Translation services: the form counts the source text, while additional fields can specify the language pair or urgency.
• Legal and business documents: the form helps estimate the workload, but the final decision is better left to a specialist.
• Store content: the site owner orders product descriptions and sees the cost of the text batch in advance.

Use Cases Where You Should Not Rely on Word Count Alone

Per-word pricing does not always reflect the actual difficulty of the work. Technical translation, medical content, legal contracts, advertising copy, or terminology-heavy writing may need to be priced differently from a standard informational paragraph. In these cases, Pay Per Word works better as a preliminary estimate rather than a final payment amount with no review.

You should not promise users that the amount will always be final if the service still depends on manual review of source quality, urgency, subject matter, formatting, research, or additional approval. A better message in the form description would be: "The form shows a preliminary estimate based on word count. The final price may be adjusted after the text is reviewed."

Who This Plugin Is a Good Fit For and When It Is Not

Gravity Forms Pay Per Word is a good fit for anyone already using Gravity Forms and wanting to add one clear calculation without building a custom calculator. If your site already has forms, notifications, confirmations, payment fields, and request handling in place, this add-on fits naturally into the existing workflow. It adds the missing piece - word counting and per-word pricing - without forcing you to rebuild the entire form.

A strong candidate for installation is a site where users enter text themselves and expect transparent pricing. That could be a small editorial team, a translation bureau, an agency, a classifieds platform, a product description service, a consulting business, or an internal client form. In those projects, payment is not the only concern. Trust matters too: the user should understand exactly why the amount changes.

The plugin may be unnecessary if the job is really just a simple numeric calculator. For example, if the client is still entering the number of pages, hours, or items manually, standard Gravity Forms fields or a more general calculator may be enough. It also does not replace a full order management system if you need a client portal, document history, revision approval, editorial workflow, task statuses, or file exchange.

The main takeaway is simple: Pay Per Word is strongest when text itself is the billable unit. If the text is only a description of the request and the actual price depends on other factors, this plugin may not be the right tool.

What to Check Before Installing It on WordPress

Before installation, it helps to prepare not only WordPress itself but also the pricing model behind the form. Many issues with these forms are not caused by the plugin but by unclear rules: what counts as a word, whether there should be a minimum charge, how tax or surcharges should be shown, what happens with empty text, how pasted content from an editor is handled, and where the user will see the final amount.

Technical Requirements

First, make sure Gravity Forms is already installed, activated, and displaying forms correctly on your site. Pay Per Word is an add-on for Gravity Forms, so it is not useful on a site without the core form builder. If Gravity Wiz is being used through Spellbook, Perks are installed and managed through that platform plugin. If the plugin is installed manually from a ZIP archive, the standard WordPress process applies: upload the plugin archive, install it, and activate it in the admin area.

You should also check how the form will be embedded on the page. Gravity Forms official materials describe several insertion methods: the Gravity Forms block, a shortcode, and a theme-code call. For initial setup, it is best to use a regular block or shortcode on a test page. That makes it easier to isolate a pricing issue from a theme issue, page builder issue, or a problem with manually embedding the form in code.

Business Rules

Before creating fields, answer four questions. First: is the price charged for every word or only for words above a base limit? Second: should the user see only the total, or the word count as well? Third: is there a minimum and maximum text length? Fourth: does the form accept payment immediately, or does it only send a request to a manager?

Those answers determine the form structure. If there is a minimum charge, enable a base price. If there is a word limit, add Gravity Forms Word Count or at least explain the rule clearly in the field instructions. If payment is required, test the final value carefully with the payment add-on. If the form is only for requests, you can show the estimate to the user and include the amount in the notification without charging immediately.

Content and Legal Constraints

A form where users paste long text may collect personal data, business information, or document excerpts. For that reason, it is a good idea to place clear consent text, a data processing policy, and an explanation of what happens after submission next to the form. Pay Per Word itself does not address the legal side of storing requests. That responsibility belongs to the site owner and the Gravity Forms configuration.

Required step before publishing: create a test form on a private page and verify the calculation without cache, without a payment gateway, and without extra conditional fields. Only then should you add payments, notifications, and more complex workflows.

Installing It and Enabling the Feature in a Form

Installation depends on how Gravity Wiz products are managed on your site. In the current Gravity Wiz documentation for Gravity Perks, management is handled through Spellbook, which helps you find, install, and update individual Perks. In some projects, the plugin may be installed manually like a standard WordPress ZIP plugin. In either case, you do not need to build authentication inside the form, and you do not need custom code for the core word-count pricing feature.

Basic Installation Flow

1. Make sure Gravity Forms is installed and that you can create a standard form.
2. Install Gravity Forms Pay Per Word using the method available for your site: Spellbook or uploading the ZIP archive in WordPress.
3. Activate the plugin and open the editor for the target form.
4. Add a Paragraph or Post Body field where the user will enter text.
5. Add a Single Product field from the Pricing Fields group.
6. Open the Single Product settings and go to the Perks tab.
7. Enable Enable Pay Per Word, choose the text field, and set Price Per Word.
8. If needed, enable the base price and base word count.
9. Add a Total field, save the form, and test the result on the page.

If the Paragraph or Post Body field you just added does not appear in the Word Field dropdown, the official documentation recommends saving the form first and then trying again. This is a normal editor behavior: some settings only become available after the form has been saved with its updated field structure.

Initial Test Without Payments

Do not connect a payment add-on until the basic calculation is working consistently. Open the page with the form as a regular user, enter a short text, then add a few more words and see whether the price changes. Next, paste in a full text, delete it, enter a single word, and check how the form behaves with an empty field. The goal of this first test is to confirm that the formula updates on input and that Total matches the Single Product pricing logic.

If the form uses conditional logic, test the no-logic version first. Hidden fields and conditional rules can affect whether data is available for pricing or payment. Once the core connection is working, add extra fields one at a time and retest after every change.

Detailed Setup for Per-Word Pricing and Base Cost

The Pay Per Word configuration looks short, but this is where many future errors are introduced. The Single Product field should be clear to both the administrator and the user. The text field should be tied to the correct source of words. The final price should behave predictably with an empty value, a short text, a long text, and any additional paid options.

Choosing the Field the Word Count Comes From

In the Word Field dropdown, select the field where the user will enter the billable text. If the form contains multiple text areas - for example, "Ad Text," "Order Comment," and "Publishing Notes" - do not tie the product field to the comment field. Otherwise, the user will see the price change based on a secondary note instead of the main text.

For longer content, Paragraph is usually the better fit. For WordPress publishing workflows, Post Body may make more sense. The important thing is not to mix the pricing field with a field used for internal comments. If you need to count several text fields together, Pay Per Word does not provide a universal "sum everything" button in the default settings. In that case, it is better to rethink the form structure or use other confirmed mechanisms, such as Word Count and additional snippets from the Gravity Wiz library, if they fit your version and use case.

Price Per Word

The Price Per Word field sets how much one word adds to the total. For a typical site, it is best to start with a simple decimal rate that is easy to explain to the user. If the rate includes a fractional amount, test the currency format and rounding in a real workflow. Do not rely on how it looks in the form editor alone: save the form, open the page, and see how the price changes when entering 1, 2, 10, 100, and 101 words.

If the final total needs to be rounded to a whole number or a fixed increment, do not invent your own payment-side workaround. Gravity Wiz provides an official snippet for rounding Pay Per Word to the nearest whole amount. Add that kind of customization only after testing the base calculation, and only through a safe code placement method such as Code Chest for JavaScript or Code Snippets/a child theme for PHP, if the specific snippet requires it.

Base Price and Base Word Count

Base Price is useful when the service has a minimum charge. For example, an editor may charge a fixed amount for the first portion of text because even a short submission still requires review, communication, and administrative handling. When you enable a base price, you define how much that first block of words costs. Base Word Count sets how many words are included in that block.

Test the base values at the edges. If the base includes 100 words, test 0, 1, 99, 100, and 101 words. The user should not see an unexpected jump. If the extra cost starts only after the base word count is exceeded, explain that next to the field: "The first 100 words are included in the price. Each additional word is billed separately." If the base price is charged even when the field is empty, make the field required or add conditional logic so you do not end up charging for an empty order.

Total Field and Additional Paid Options

The Total field is not required for the Pay Per Word math itself, but it is almost always useful to the user. It displays the combined price of all pricing elements in the form: the word-based product, options, quantity, shipping, or any other payment-related fields. The official Gravity Forms documentation highlights the role of Pricing Fields: Product defines the item or service, Option changes the product price, Quantity multiplies the amount, and Total displays the final sum.

If your text-based service includes options such as "rush," "SEO review," "publish on site," or "additional editing," build them as Gravity Forms pricing elements rather than plain checkboxes with no price. Otherwise, the user may select a service and see no change in the total. After setup, be sure to test combinations: text only, text plus one option, text plus multiple options, minimum length, and large volume.

Limiting Word Count with Gravity Forms Word Count

Pay Per Word handles pricing. Word count limits are easier to manage with Gravity Forms Word Count because it is a separate Perk designed to set minimum and maximum values for supported text fields. Gravity Wiz official documentation explicitly states that Word Count integrates with Pay Per Word: you can set minimum and maximum length limits, and Pay Per Word will calculate the cost for those words.

This combination is useful for improving submission quality. A minimum helps filter out texts that are too short to evaluate properly. A maximum protects the form from excessively long pastes and from cases where a user accidentally inserts the wrong document. But the limit should be explained before submission, not only through an error message. It is better to write something like this next to the field: "Minimum 50 words, maximum 1000 words."

Practical conclusion for this section: the configuration is only complete after you confirm three things: the price changes during input, Total shows the expected amount, and the word limits do not interfere with a normal user workflow.

Practical Example: A Form for Estimating Text Editing Costs

Let us walk through a realistic workflow. Imagine the site accepts requests for editing short texts. The user should paste in the text, choose urgency, see a preliminary cost, and submit the request. Payment can be added later, but the form itself should already provide a clear estimate.

Goal

Create a form where the client pastes in text for editing and sees the amount beside it or below it. The base price includes the first small portion of text, and words above that limit are charged at a rate. The user can also choose urgency, but that option should be a separate pricing setting so it appears clearly in the final total.

Preparation

Before building the form, create a test page where it can be embedded without a complex page builder. Prepare the service rules in advance: what is included in the base price, how extra words are charged, which texts are not accepted automatically, and what happens after submission. If the form will send a notification to a manager, prepare the email template ahead of time with the word count, final amount, and a link to the Gravity Forms entry.

Setup Steps

1. Create a new form and name it something clear for the administrator, for example "Text Editing Estimate."
2. Add a Name or Email field if you need to contact the client after submission.
3. Add a Paragraph field labeled "Text for Editing" and make it required.
4. Add a Single Product field labeled "Editing by Word Count." In the field settings, open Perks.
5. Enable Enable Pay Per Word, choose the "Text for Editing" field in Word Field, and set the per-word price.
6. If there is a minimum charge, enable Base Price and set Base Word Count.
7. Add an Option field or another pricing element for urgency if it affects the price.
8. Add Total and place it where the user will see the amount before submitting.
9. Save the form, embed it on the test page, and test text input.

Testing with a Short Text

Enter one short sentence and see whether the base price is applied. If the field is required, try submitting the empty form and review the message. The user should understand that they need to paste in text, not guess why the form will not submit.

Testing at the Word Count Threshold

If the first 100 words are included in the base price, paste in a text close to that length and then add one more word. This will show you the exact point where the price starts increasing. The threshold should match your intended pricing model. If the amount changes unexpectedly, double-check Base Word Count and Price Per Word.

Testing with an Extra Option

Select urgency or another paid option and make sure Total changes. If only the visible label changes but the amount does not increase, the option was probably added as a regular field rather than a pricing element. Use Pricing Fields for paid options.

A Common Friction Point

If a user pastes text from an external editor, it may contain extra spaces, line breaks, or unusual separators. The default Pay Per Word behavior counts words according to its own rules, and Gravity Wiz offers snippets for cases where the counting method needs to be adjusted. Do not add them in advance "just in case." First, test with the types of text your real clients actually submit, and only then decide whether the counting method needs to change.

Working Setups for Services Where Text Volume Matters

The same Pay Per Word mechanism can be used in different ways. A common implementation mistake is to build the form as a technical experiment: text field, price, submit button. What matters to the user, however, is the actual service. That is why, after the basic test, it is worth choosing one primary use case and building the form around it: explain the rules, add only the necessary clarifications, and avoid turning the order process into a long questionnaire.

Paid Listings and Short Publications

For ads, the key value is predictability. The user writes the text, sees the price immediately, and understands how shortening or expanding the ad affects the final amount. The base price is especially useful here because it can cover the minimum publication, moderation, and request processing. If the platform limits ad length, the Gravity Forms Word Count combination helps prevent overly long submissions.

In a form like this, you do not need to ask for everything. The text of the ad, category, contact details, publication term, and agreement to the rules are usually enough. If category affects the price, it should be set up as a pricing element or as a condition that displays the appropriate product field. Result check for an ad form is straightforward: the user changes the text, Total changes, the selected category does not break the calculation, and the entry stores both the text and the amount.

A Typical Ad Form Pitfall

Users may try to work around the pricing by entering long hyphenated strings, symbols, or forced line breaks. There is no need to overcomplicate the form right away. First, collect real examples of submissions and see how often this actually affects the calculation. If it becomes a recurring issue, review the official snippet for split words on specific characters and add it as an explicit platform rule, not as a hidden tweak.

Editing, Proofreading, and Translation

For editorial services, word count is only one factor. Text complexity, language, urgency, and subject matter can all affect the final estimate. That is why Pay Per Word is often better used here as a preliminary cost calculator. The user gets a ballpark figure, while the manager sees the source text and can refine the price after reviewing it.

A practical form structure includes contact details, the text, service type, urgency, subject area, and a comment field. The important part is not to tie the price to the comment. The comment is for the manager, while the billable text should live in a separate Paragraph field. If the service has a minimum handling fee, enable Base Price. If the text is too short for a meaningful review, add a minimum through Word Count or explain the rule clearly in the field description.

Translation-Specific Testing

Test how the form behaves with text in different languages if your audience actually submits that kind of content. Do not promise perfect counting across all language-specific cases unless that has been confirmed through testing. In the form description, you can state honestly that the estimate is preliminary and will be confirmed after the source text is reviewed.

Product Descriptions and Bulk Requests

Online stores and agencies often order descriptions for multiple products. That raises an important question: should the form count one combined text or several separate blocks? Standard Pay Per Word works best with one primary text field. If the user pastes in the entire batch at once, the form can provide a combined estimate. If each product needs to be counted separately, it is better to think through the structure in advance: separate forms, repeatable blocks through another solution, or manual review after file upload.

For bulk requests, it can be helpful to add a "Number of Products" field as reference information, but it does not necessarily need to be part of the price if pricing is already based on word count. Otherwise, the user may end up with a double calculation: words multiplied by the rate, and then multiplied again by product count. That approach only makes sense if it truly matches the business rules and is clearly explained next to the form.

Legal and Business Documents

For documents, per-word pricing can be a useful guide, but it rarely reflects the full scope of the work. One short clause in a contract may require more attention than a long informational text. That is why, for legal and business documents, the form should clearly separate the preliminary estimate from the specialist's final review.

In this case, it helps to add a checkbox or a short callout such as: "Word-based pricing provides a preliminary estimate. The final quote depends on the document type." Do not hide that in the FAQ. The user should see it before submitting. If you collect payment immediately, it is better to limit the workflow to straightforward documents with clear rules and treat more complex cases as quote requests without automatic payment.

What Should Be Included in the Entry and Manager Notification

Once the form is submitted, the job is not done. Pay Per Word helps calculate the price, but the manager still needs to process the request without manually piecing everything together. A good Gravity Forms entry should answer these questions: who submitted the text, which text is treated as billable, which rate was applied, which options were selected, what amount the user saw, and whether the form stated that the price was only a preliminary estimate.

Minimum Entry Contents

The entry should include contact fields, the billable text, the product field with the calculated price, Total, and all additional options. If word limits are enabled, it is also helpful to save or at least display the word count through a confirmed method, if one has already been implemented. Without that, the manager can still verify the text manually, but a separate value speeds up processing and reduces disputes.

Do not put everything into the notification. In large forms, {all_fields} can produce too many internal lines. It is better to build the email around meaning: name, email, service type, text, options, final cost, and a link to the entry. If the form uses a preliminary estimate, add a note for the manager such as: "Review the text before confirming the price."

Separating the Request from the Payment

There are two valid working approaches. The first is a form that accepts payment immediately based on the calculated amount. That works well for simple services with transparent rules. The second is a form that stores the request and shows a preliminary estimate, while a manager confirms the order manually. That approach is better for complex texts, unusual subject matter, and services where the quality of the source text affects the cost.

Do not mix these approaches unless there is a real reason to do so. If the user has already paid, raising the price manually afterward will feel confrontational. If the estimate is preliminary, do not present it as a completed payment flow. Use the same meaning in both the form text and the confirmation: either "preliminary estimate" or "order cost."

Testing Notifications

After setup, submit several test requests. Check not only the admin email but also the user email if it is enabled. The user should receive a clear confirmation, not a list of technical field names. If the email contains "Product Name," "Price," and "Quantity" in an awkward format, edit the notification template. The pricing structure is for the system, but the client needs a clear service description.

Using It with Word Limits, Conditional Logic, and Payments

Once the basic setup is complete, additional requirements usually appear. You may need to limit text length. You may need to show different fields for different service types. You may need to send the user to payment only under specific conditions. All of these can be handled with Gravity Forms and related add-ons, but it is important not to blur the responsibilities of each component.

Pay Per Word Calculates the Price, Word Count Controls Length

If you need to charge by word count and also reject texts that are too short or too long, use Gravity Forms Word Count. In its field settings, you can define minimum and maximum values. Pay Per Word will continue calculating the price, while Word Count handles the allowed range. That is a clean separation: one Perk calculates money, the other validates text length.

This approach is helpful for forms where submission quality matters just as much as payment. For example, it may not make sense to accept only 5 words for editing, and it may be impractical to accept 50,000 words for translation through a standard form. Limits help set boundaries and reduce manager workload.

Conditional Logic Helps Split Different Types of Work

Gravity Forms supports conditional logic for fields, confirmations, notifications, and certain workflows. In the context of Pay Per Word, it is useful when different services need different sections of the form. For example, the user selects "Editing," "Translation," or "Ad Placement," and the form displays the relevant follow-up questions.

Conditional logic needs to be handled carefully, though. If the text field is hidden, the product field is tied to it, and the user submits a different workflow, the calculation may no longer match what you expect. For a more complex form, it is often better to create separate product fields for different workflows or manage visibility so that the active product is always connected to the active text field.

Connect Payments Only After the Calculation Is Verified

If the form needs to accept payment, first make sure the Total shown on the page matches the expected cost. Only then should you connect Stripe, PayPal, or another supported Gravity Forms payment workflow. In payment forms, it is especially important that all Product fields and choices have prices. The official Pay Per Word documentation specifically mentions the Amount Mismatch error and advises checking the prices for all Product fields, including zero values where no price should be charged.

The payment layer should not be expected to fix calculation errors. If the Total is wrong before payment is enabled, the payment gateway only makes the problem more expensive. Test in this order: text-based calculation, options, Total, entry submission, notifications, and only then payments.

How to Show the Calculation to Users Without Extra Noise

A per-word pricing form should be transparent, but not overloaded. The user does not need to understand the internal structure of Single Product, Base Price, and Total. They only need to see three things: where to paste the text, how the price is calculated, and what the amount will be before submission.

Field Labels

Do not give the product field a technical label such as "Pay Per Word Product." Use something the user will understand instead, such as "Editing Cost," "Ad Price," or "Preliminary Translation Estimate." The technical logic stays in the settings, while the user sees normal service language.

It is also helpful to place a short note next to the text field: "Paste your text here. The price will update automatically." If there is a base price, explain it in one line. If there is a word limit, show the range. If the final amount may be adjusted manually, say so before submission.

Where to Place Total

The Total field usually works best near the submit button or on the last step of a multi-page form. If the form is long, the user should see the amount before taking the final action. In multi-page forms, you can show an interim total on the page with the text and a final total before submission. The important thing is not to hide the amount so thoroughly that the client only discovers it after clicking the button.

How to Avoid Overloading the Interface

You do not need to display every technical variable. In most cases, the text field, the product line, and Total are enough. If you want to show the word count as a separate value, use a confirmed snippet from the Gravity Wiz library to store the word count in a separate field, or use another safe implementation based on the documentation. But do not turn the form into an accounting spreadsheet if the user simply wants to submit text.

Rule of a good form: the user should understand the total without needing instructions. If the form requires a long explanation of "how the price works," the pricing model or field labels probably need to be simplified.

Special Modes: Rounding, Characters, Lines, and Separators

The official Pay Per Word documentation includes links to snippets that extend the plugin's behavior. They are useful, but they go beyond the basic setup. First, make sure you understand how standard word counting works. Then decide whether a different counting method is actually necessary.

Rounding the Price

Rounding makes sense when fractional cents look odd for your type of service. For example, a per-word rate may produce a final amount with a small decimal fraction, while the business wants to display whole numbers. Gravity Wiz publishes the Round Up Price snippet for rounding the calculated Pay Per Word price. Use it only after confirming that the base rate itself is correct. And make sure to test not just the amount shown on the page but also the saved order total.

Charging by Character Instead of by Word

Some services are billed by character rather than by word: short ad copy, SMS text, listings with strict character limits, or translation work with custom pricing rules. The Pay Per Word FAQ states that this behavior is supported through a two-part snippet: PHP and JavaScript. This is important because if you change the counting method on the front end, the server side has to follow the same rule. Otherwise, you may end up with a mismatch between the displayed amount and the amount stored after submission.

This mode should only be implemented when the service rules genuinely define pricing by character. If the client expects per-word pricing, switching to characters without a clear explanation will reduce trust in the form.

Charging by Line

For classified ads, poetry, line-based transcript work, or short publications, it may make more sense to count lines instead of words. The Gravity Wiz library includes a Pay Per Line snippet. It lets you use the Pay Per Word interface while calculating cost by line. This is not a universal replacement for word count: line breaks become part of the business rule, so the form should clearly explain what counts as a line.

Splitting Words on Special Characters

Some texts include hyphens, underscores, periods, articles, or technical markers. Standard counting may interpret them differently from what the service owner expects. For cases like that, Gravity Wiz documents the gpppw_word_count filter on the front end and provides snippets for splitting words on special characters. Use them carefully and only after testing real examples. If different clients submit text with very different structures, changing the separators may help one use case and break another.

Safe Enhancements Without Editing the Plugin Core

You should not modify Gravity Forms, Gravity Forms Pay Per Word, or theme files directly. Those changes will be lost during updates, and a mistake can break the calculation. It is safer to rely on form settings, Code Chest for form-specific CSS or JavaScript, a child theme, or a dedicated snippets plugin if a specific customization is truly needed.

A Small CSS Tweak for the Total Price

The safest and clearest example is to visually highlight the final amount and the pricing field. This does not change the math and does not interfere with payments. Below is a CSS example for a form using the Orbital theme. Replace GFFORMID with the form ID and FIELDID with the target field ID. The easiest place to add code like this is Code Chest or another safe CSS location in your theme.

/* Highlight the total price field in a specific Gravity Forms form */
.gform-theme--framework#gform_wrapper_GFFORMID #field_GFFORMID_FIELDID {
  --gf-ctrl-border-color: #246bfe;
  --gf-ctrl-bg-color: #f7fbff;
  --gf-ctrl-label-color-primary: #16345f;
}

.gform-theme--framework#gform_wrapper_GFFORMID #field_GFFORMID_FIELDID .ginput_container {
  font-weight: 700;
}

After adding the CSS, open the form page, enter text, and make sure the highlight appears only on the intended form. If the style affects other forms, the ID selector is too broad. Rolling it back is simple: remove the CSS or restore the previous values. This tweak is not required in every project, but it is useful when Total gets visually lost next to a long text field.

When an Official Snippet Is Better Than Custom Code

If you need to change the calculation itself - rounding, characters, lines, or custom separators - use the official Gravity Wiz snippets as your starting point. They are tied to specific Pay Per Word filters and take into account that the calculation must remain consistent both on the front end and after submission. Custom JavaScript that only changes the visible amount in the browser can lead to payment errors or entry mismatches.

A Practical Combination with Gravity Forms Notifications

A useful combination that does not require any unverified integrations is to use standard Gravity Forms notifications. After a request is submitted, the manager should receive the text, client contact details, selected options, and total cost. This is not a special Pay Per Word integration with an external CRM. It is simply a normal Gravity Forms workflow: the form collects the data, and the notification sends it to the administrator. Test the email with a sample submission and make sure it includes both the amount and the text, but not extra internal fields that confuse the manager.

Checking the Result Before Publishing the Form

Publishing a per-word payment form without control tests is risky. A pricing error may go unnoticed with one short text and only surface on a real order. Your testing should reflect different user behaviors: one user types text manually, another pastes a large block, another deletes part of the text, another changes options before submitting.

Control Test Checklist

• Empty field: the form should either block submission or show a clear zero calculation if empty text is allowed.
• One word: the price should match either the base price or a single unit rate, depending on your model.
• Base threshold: test text exactly at Base Word Count and immediately above it.
• Large text: paste in a long block and make sure the page does not freeze and the amount updates.
• Options: enable each paid option and check Total.
• Entry submission: compare the amount shown before submission with the amount stored in the Gravity Forms entry.
• Payment: if a gateway is connected, run a test payment using the payment solution's own safe test mode.

What to Review in the Gravity Forms Entry

After submission, open the entry in the admin panel and compare the fields. The text should be saved in the correct field. The product line should reflect the calculated price. Total should match what the user saw before submitting. If the amount in the entry differs from the amount on the front end, look for the issue in extra scripts, snippets, cache, conditional logic, or payment fields.

Testing on the Real Template

Even if the test page works, also verify the form in the exact place where it will be published. Page builders, popups, script optimizers, and cache layers can change the JavaScript load order. Pay Per Word uses JavaScript to update the price while the user types, so browser console errors can directly affect the visible calculation.

Troubleshooting Common Issues

Pay Per Word issues usually fall into four categories: incorrect field mapping, JavaScript not updating, totals changing after submission, or users not understanding the pricing rule. It is best to troubleshoot from simple to complex. Do not change several settings at once, or it will be difficult to tell what actually fixed the issue.

The Price Does Not Change While Typing

Symptom: the user enters text, but the product field and Total stay the same. Possible causes include the Single Product field being linked to the wrong text field, Enable Pay Per Word not being enabled, the field not being saved before selecting it in Word Field, or the required JavaScript not running on the page.

What to check: open the form editor, select the product field, and review the Perks tab, word source, and per-word price. Then open the form on a simple page and check the browser console. If everything works on a simple page, the issue may be related to cache, minification, a page builder, or the method used to embed the form.

How to fix it: save the form, reselect the correct field in Word Field, temporarily disable JavaScript optimization for the form page, and run a conflict test using the Gravity Forms methodology. If the issue appeared after adding a custom snippet, disable it and return to the default logic.

The Required Text Field Does Not Appear in the Word Field List

Symptom: the Paragraph or Post Body field has been added, but it cannot be selected in the Pay Per Word settings. The official documentation gives a simple recommendation for this case: save the form and try again. The editor needs to refresh the field structure.

What to check: make sure this is a supported field type, not Single Line, HTML, or a regular note field. If the field was created inside a more complex conditional structure, test the basic form first without extra layers.

How to fix it: save the form, refresh the editor, reopen the product field, and select the word source again. If the field still does not appear, create a new test Paragraph field and see whether that one appears. This will tell you whether the issue is tied to a specific field or the form configuration as a whole.

The Final Total Changes After Submission

Symptom: the user sees one amount on the page, but a different amount appears in the entry, notification, or payment. This is a critical issue for paid forms. Possible causes include conflicting snippets, a missing price on another Product field, conditional logic errors, JavaScript interference, a cached page, or a mismatch between front-end and server-side calculation.

What to check: compare the form behavior without the payment gateway and then with it enabled. Check all Product fields and choices. If any field is missing a price, assign a zero value where the item is meant to be free. The official Pay Per Word documentation lists this as one way to troubleshoot Amount Mismatch.

How to fix it: first make sure all pricing fields use explicit values, then disable custom snippets, then test the form on a clean page. If word counting has been customized through both PHP and JavaScript, make sure both parts are working together. Once the amount is stable, reconnect the payment step.

The Word Limit Does Not Match the Price Calculation

Symptom: the form calculates the price, but still accepts text that is too short or too long, or it blocks text where the user expects to continue. This usually happens because Pay Per Word only handles pricing, while word limits are set separately through Word Count or not configured at all.

What to check: open the text field settings and review the Word Count parameters if that Perk is being used. Compare the minimum and maximum limits with the business rules. Test text with line breaks and pasted content from an external editor.

How to fix it: define clear boundaries, add a helpful note below the field, and test threshold values. If the count needs to interpret special separators, review the official word-splitting snippets, but do not change the algorithm without a real reason.

The Form Breaks After Caching or Script Optimization

Symptom: everything works in the editor and on the test page, but on the live page the amount does not update, submission hangs, or console errors appear. With Gravity Forms, this is often tied to the theme, page builder, JavaScript optimization, or caching.

What to check: temporarily exclude the form page from aggressive optimization, disable script combining and deferred loading on that page, and create a clean page with the same shortcode or block. Gravity Forms recommends running a conflict test: temporarily switch to a default theme and enable plugins one by one if the issue cannot be isolated another way.

How to fix it: keep the exception for the form page or Gravity Forms scripts if that resolves the issue. If a specific plugin causes the conflict, update it or contact its developer. Do not try to patch over a broken load process with an additional script.

When Gravity Forms Pay Per Word Is the Right Choice

Use this plugin if your use case fits the model "text -> word count -> price" exactly. It works especially well for forms where the user pastes in text and needs to see a clear price immediately. At the same time, it should not be treated as a full order management system: job statuses, client accounts, editorial workflows, and more complex arrangements will need to be handled by other tools.

Before publishing, test the form on a staging page, configure clear labels, add Total, and think through the base price and word limits. If everything works consistently, you can move on to the live page and test compatibility there with the theme, cache, and payments. When you are ready to repeat the setup on your own site, use the link get the Gravity Forms Pay Per Word file and, after installation, start not with payments but with a simple test form.

The main sign that the setup is ready is not the presence of every possible snippet, but predictable behavior. The user enters text, the price changes in a clear way, the total matches the entry, and the manager receives enough data to process the request. If that chain works, Pay Per Word is doing its job cleanly and without unnecessary complexity.