Formidable Authorize.Net - WordPress Plugin

How to Set Up Formidable Authorize.Net for WordPress Payment Forms

Formidable Authorize.Net does more than just add a payment button to a form. This guide explains how to connect the Authorize.Net payment gateway to Formidable Forms, prepare the required fields, configure the payment action, test a sandbox transaction, show a receipt to the user, and troubleshoot why a payment might fail.

This guide is written for a site owner, webmaster, or developer who already has a WordPress site running Formidable Forms and needs to accept payments through Authorize.Net without building a full online store. We will not repeat the plugin's marketing copy. Instead, we will walk through the practical workflow: from preparing the site and credentials to diagnosing errors such as E00007 User authentication failed.

Special attention is given to details that are easy to miss: SSL, keeping sandbox and live credentials separate, card data storage, eCheck fields, conditional logic for different payment methods, post-payment actions, and checking the result in the log. If a feature depends on a specific version, plan, or Authorize.Net setting, the wording in this article stays appropriately cautious.

What This Payment Add-On Is Actually For

Formidable Authorize.Net handles a narrow but important task: accepting a one-time payment through a Formidable Forms form and sending the data to Authorize.Net. According to the official documentation, the add-on works with Authorize.net AIM payments, requires an Authorize.Net account, and requires SSL on the site, while recurring payments are not currently supported in this integration. That defines its scope right away: the product works well for applications, payments, donations, registrations, and orders with a clear amount, but it should not be treated as a full subscription platform.

The strength of this approach is that the form can collect customer data, calculate the amount, show conditional fields, send notifications, update values after payment, and display a receipt all in one flow. Unlike a separate cart, the form remains the main user journey: the user fills in the details, chooses a payment option, submits the form, and Formidable runs the payment action.

This setup is especially useful when the product or service does not need a WooCommerce catalog. For example, a consultation, event registration, application fee, non-recurring membership fee, one-time invoice, booking with a fixed price, or a donation with a user-selected amount. If the site needs inventory, products, shipping, coupons, order statuses, and refunds, WooCommerce or a specialized payment stack is a better fit.

Who It Fits Best

• Service websites where the payment amount is known from the form or calculated from selected fields.
• Nonprofit projects that need one-time payments or donations through Authorize.Net.
• Event organizers who rely on registration fields, notifications, and payment confirmation.
• Agencies and developers who already use Formidable Forms as a workflow builder.

When It May Not Be the Right Fit

If you need a full store, a subscriber account area, automatic plan changes, complex refunds, recurring billing, or many payment methods across multiple countries, this add-on alone may not be enough. In that case, Formidable Authorize.Net can still handle simple one-time forms, while more complex commerce is moved into a separate tool.

Key takeaway: think of this add-on as a payment action inside a form, not as a replacement for an entire ecommerce system. That mindset helps you design the fields, notifications, and result checks correctly.

What to Check Before Installation and Enabling Payments

Before installation, make sure the site and payment flow are ready to handle sensitive data. Formidable's official documentation repeatedly emphasizes the need for SSL on payment forms, and the separate Payment field page warns that storing full card data on your own site increases your responsibility. So this preparation is not a formality - it is part of security and reliable troubleshooting.

Technical Readiness of the Site

Start with the basic health of WordPress. Formidable Forms Premium and the required add-ons should be up to date, and Formidable Forms Lite must be installed and active because the premium version depends on it. If your hosting environment has strict security rules, the automatic Lite installation may fail, in which case you can add it manually through the standard WordPress plugin directory.

Check that the public form page opens over https://, there is no mixed content, page caching is not serving an outdated version of the form after changes, and the theme is not breaking the input fields. For payments, aggressive JavaScript optimization, deferred loading of form scripts, and caching pages with dynamic validation are especially problematic. If the payment form behaves inconsistently, first exclude that page from cache temporarily and test it without minification.

Your Authorize.Net Account

To make this work, you need either an Authorize.Net merchant account or a sandbox account. Do not mix them up: sandbox and production use different credentials, and Authorize.Net explicitly states that using production keys in sandbox or vice versa will cause errors. In the test environment, no real money is charged, but you can still verify gateway responses, test cards, and decline scenarios.

For a live form in Formidable, select the live environment and enter your real credentials. For a test form, use sandbox credentials and the testing environment in Formidable settings. Do not publish a test form as a live form, and do not leave a production form connected to sandbox keys.

Decisions to Make Up Front

• Will the form accept card payments only, eCheck only, or both.
• Where the amount comes from: a fixed value, a calculation, a service selection, or a user-entered field.
• What customer data is needed for the payment, the receipt, and internal processing.
• Whether shipping is needed, and if so, which form fields will be sent as shipping information.
• What should happen after a successful payment: an email, a field update, a receipt display, or an admin record.

These decisions are best made before you build the form. Otherwise, the payment action quickly turns into a pile of random settings, and it becomes hard to understand why a notification fired at the wrong time or why the user sees unnecessary banking fields.

Installing Formidable Authorize.Net and Running an Initial Check

Installation starts not with Authorize.Net, but with Formidable Forms being in the right state. The official Authorize.net Payment forms instructions say to first install and activate the current version of Formidable Forms Premium, verify the license, then go to Formidable - Add-Ons and enable the Authorize.net WordPress plugin. This guide does not cover the purchase flow or license entry, but the dependency matters: without the right access level, the add-on may not appear in the list.

Once it is enabled, do not build a live form right away. First make sure the add-on actually added payment capabilities to Formidable: the Payment field becomes available when the Stripe or Authorize.net AIM add-on is active, and the form settings should include the Collect A Payment action. If those elements are missing, do not start by blaming Authorize.Net. Most likely the add-on is not active, the premium portion of Formidable is not connected, or there is a conflict with another plugin.

Quick Post-Activation Check

1. Open Formidable - Global Settings - Payments.
2. Make sure the Authorize.Net tab is present.
3. Create a draft form and check whether the Payment or Credit Card field is available.
4. Open Settings - Actions & Notifications for the form and look for the Collect A Payment action.
5. Save the form without publishing it and confirm there are no errors in the admin area.

If everything looks correct at this stage, you can move on to entering credentials. If not, first check the Formidable version, whether the Lite plugin is active, whether admin caching is causing issues, and whether the current WordPress user has the right permissions. Do not paste real keys into a system that is not yet showing the basic payment action components.

Connecting Authorize.Net: Keys, Environment, and Safe Storage

The Authorize.Net connection revolves around three values: API Login ID, Transaction Key, and Signature Key. In Formidable's official documentation, the steps are described through the merchant account: open the Account tab, go to Security Settings, choose API Credentials & Keys, save the API Login ID, create a new transaction key and signature key, then paste those values into Formidable - Global Settings - Payments - Authorize.Net.

In practice, it is not enough to just copy the keys - you also need to keep test and live environments separate. An Authorize.Net sandbox account is completely separate from production, and test transactions are not sent to financial institutions. So use sandbox credentials for testing and live credentials for the real form. If the keys are mixed up, the payment may fail with an authentication error or an invalid gateway response.

How to Handle Keys Safely

• Do not send keys to a contractor in an open chat or paste them into public tasks.
• Do not keep screenshots with keys in the WordPress media library.
• After responsibility changes hands, create a new transaction key instead of forwarding the old one.
• Make sure the key is pasted without extra spaces before or after the value.
• Do not use sandbox keys in a live form or live keys in a sandbox form.

What to Check After Saving

After pasting the keys, click the standard Save button for the settings. Then return to the tab and make sure the values did not disappear because of a permissions issue or hosting security rule. The next step is a test transaction, not a visual page check. The payment integration should only be considered connected after the form sends a request, Authorize.Net returns the expected response, and Formidable records the result.

Do not go live without testing. Authorize.Net provides sandbox mode and test cards specifically so you can verify the amount, fields, decline flow, receipt, and notifications before real payments begin.

Building the Payment Form: Fields, Amount, and Payment Method

A payment form in Formidable has two layers: standard fields and the payment layer. The standard fields collect the name, email, service, quantity, address, or comment. The payment layer takes the amount, card or eCheck data, customer information, and shipping information, then passes them into the Collect A Payment action. The more clearly you separate those layers, the easier it will be to troubleshoot problems.

Fields for Card Payments

For a card-based flow, add a payment field that lets the user enter card details. Formidable's Payment field documentation shows several storage options: save only the last four digits, do not save the card number, save the full card number, or do not save and do not send card values to the server. According to the documentation, the last option is not supported with Authorize.Net. So the practical safe recommendation is to avoid storing the full card number and choose the most minimal storage option available in your configuration.

Also review the placeholder text and field labels. If the form is in Russian, it makes sense to use clear user-facing labels such as "Card Number," "Expiration Date," and "Security Code." But leave the system labels in the admin interface unchanged so support and documentation remain easy to follow.

Fields for eCheck

If you want to accept eCheck, Formidable's official instructions require adding two Number fields for the routing number and account number, plus a Single Line Text field for the bank name. Those fields then need to be mapped inside the payment action. It is important to remember that eCheck does not behave like a card payment: Formidable notes that eCheck status does not become successful instantly, and completion is verified later. That means emails and internal workflows should be configured with that delay in mind.

The Payment Amount

You can define the amount in different ways: as a fixed value in the action, as a form calculation, from a selected service, or from a quantity field. For a simple use case like "consultation payment," a fixed amount is enough. For event registration, radio buttons or a dropdown with clear options usually work better, with the final amount shown to the user before submission. For donations, you can let users choose the amount, but be sure to add a minimum value and a clear confirmation before payment.

Do not bury the final amount deep inside the form. The user should be able to see what they are paying for before submitting their data. That reduces disputes, helps support, and makes test transactions easier to verify.

Configuring the Collect A Payment Action Without Surprises

Once the fields are ready, open the form and go to Settings - Actions & Notifications. In Formidable's official instructions, the action is added through the E-Commerce tab or by searching for Collect A Payment. This is the action that connects the form to Authorize.Net and determines what happens after submission.

In the first section of the action, fill in the payment description, amount, currency, and payment method. If both card and eCheck are enabled, Formidable automatically adds a Gateway field with the authnet_aim and authnet_echeck options. This is not a decorative field - it is the logic switch. It controls which fields the user sees and which data will be sent.

Action Settings Map

The table does not replace testing, but it helps you avoid missing the blocks most likely to break the flow. Pay especially close attention to shipping information: if shipping fields are marked required in Authorize.Net or in the form, but your form does not send them, the user may see an error that is hard to interpret from the front end.

Conditional Logic for Card and eCheck

If one action allows both Authorize.Net card and eCheck, configure conditional logic on the fields. For the card field, use the condition Payment Gateway equals authnet_aim. For routing number, account number, and bank name, use Payment Gateway equals authnet_echeck. That way, the user only sees the set of fields that matches the selected payment method.

After configuring this, update the form and test the public page. Switch the payment method several times, fill out the fields in each mode, and make sure the form is not requiring hidden fields. A common mistake is marking eCheck fields as required at the form level while hiding them when the user selects card payment. In that case, card users will not be able to submit the form because a hidden required field is still missing.

Payments, Notifications, and Receipts After Form Submission

The value of a payment form goes beyond the actual charge. After submission, a second important layer begins: notifications, status changes, the receipt, and the record stored in Formidable. The official documentation says that actions such as Emails, Twilio, and Mailchimp can be triggered after payment completion or failure through the Trigger this action when setting. If you want an email to be sent only after a successful payment, disable the trigger on entry creation and select Successful Payment.

This is critical for paid registrations and paid applications. If an access email or ticket is sent immediately after the entry is created, the user may receive confirmation even if the payment fails. The correct flow is: the entry is created, the payment action sends the request, and only after a successful response does the email or field update run. For eCheck, add one important caveat: success may not be immediate, so actions tied to final confirmation should be tested separately.

Receipt via Shortcode

Formidable supports a shortcode for displaying a payment receipt:

[frm_payment_receipt id="[id]"]

You can place it in a View, email message, or success message. To display a receipt for a specific entry on a page, use this version:

[frm_payment_receipt id=25 layout=right]

The number in the example should be replaced with the ID of the needed entry. In a real setup, a dynamic ID for the current entry is usually used so the user sees their own receipt. The receipt header and footer text can be configured in Formidable - Global Settings - Payments - Authorize.Net.

What the User Should See After Payment

A good success message should do more than say "Thank you." It should explain that the payment was accepted or the application was submitted for review, where the email will arrive, where to find the receipt, and what to do if the user has questions. At the same time, do not expose unnecessary sensitive data on the public page. The last four digits of the card, the entry number, and a clear description are usually enough for reference.

Practical Example: Event Registration Form with Payment

Let's walk through a use case that fits Formidable Authorize.Net well: registration for a paid in-person seminar. You need a form where the user chooses a ticket type, enters contact details, pays by card or eCheck, receives confirmation only after a successful payment, and the administrator sees the entry in Formidable.

Goal

Create a form on a WordPress page that accepts a one-time participation payment, sends the payment to Authorize.Net, and shows a receipt. This use case does not require WooCommerce because there is no product catalog, inventory, or complex cart.

Preparation

• Formidable Forms Premium and the Authorize.Net add-on are active.
• Sandbox keys are saved in the global payment settings for testing.
• The form page loads over HTTPS and is excluded from aggressive caching.
• An Authorize.Net sandbox account is ready for testing.

Setup Steps

1. Create a form in Formidable - Forms - Add New and name it "Seminar Registration."
2. Add fields for name, email, phone number, and ticket selection. For ticket selection, use radio buttons or a select field with clear options.
3. Add a calculation field or total amount field if the price depends on the selected ticket.
4. Add a Payment or Credit Card field for card payments.
5. If you need eCheck, add routing number, account number, and bank name, then configure conditional display.
6. Open Settings - Actions & Notifications and add Collect A Payment.
7. In the action, select Authorize.Net, set the amount from the calculation field, define the payment description, and map the customer information.
8. Configure the email notification so the participant email is sent after Successful Payment, not just after the entry is created.
9. Add a short confirmation message and the receipt shortcode to the success message if that fits your flow.

Verification

Open the page in a private window, fill out the form like a normal user, and use an Authorize.Net test card for sandbox mode. Check three places: the user sees a clear result, the entry appears in Formidable, and Authorize.Net shows the test payment or the expected sandbox response. Then run a decline test, for example with data that triggers a sandbox decline. The form should display the correct error, and the confirmation email should not be sent as if the payment had succeeded.

A Common Issue That Gets Missed

If both payment methods are enabled, but conditional logic only controls field visibility while the fields themselves are still marked required regardless of the selected gateway, the user can run into an invisible validation error. After setup, always submit the form in every variant: card, eCheck, card decline, and incomplete eCheck data.

How to Validate Everything Before Going Live

Validation should follow the chain field - action - gateway - entry - notification - receipt. If you only look at the message saying "form submitted," you can miss a problem with the amount, keys, or email trigger. For a payment form, that is risky: the user may think they paid, the administrator may think the request came through, and the payment may still have failed in Authorize.Net.

Testing Checklist

• The form loads over HTTPS and does not show browser security warnings.
• The amount before submission matches the amount in the payment action.
• When card is selected, only card fields are visible and eCheck fields are hidden.
• When eCheck is selected, banking fields are visible and the card field does not block submission.
• After a successful sandbox transaction, an entry is created in Formidable.
• The participant email is sent only after a successful payment, if that is the intended flow.
• The receipt shows clear data without the full card number.
• If the payment is declined, the user sees the error and can correct their information.
• The Formidable log does not show repeating API errors.

Moving from Sandbox to Live

After a successful test, replace the sandbox keys with live keys, switch to the live environment, and run a minimal real payment if that is acceptable for your operation. Do not change the design, fields, and payment environment all at once. First confirm that the live connection works, then roll the form out more broadly.

If an error appears after switching to live, go back to the simplest question: did only the keys and environment change, or did you also change the form? The fewer differences there are between the last successful sandbox test and the first live test, the easier it will be to find the cause.

Safe Enhancements Without Editing Plugin Core

With Formidable Authorize.Net, there is no reason to invent undocumented hooks or edit the add-on files. But there are a few safe improvements supported by the official documentation and standard WordPress practice: styling the payment field with CSS, carefully setting up autocomplete, and using the documented filter for the invoice number.

Autocomplete Hint for the Card Number

The Payment field documentation describes how to add the autocomplete="cc-number" attribute through Settings - Customize HTML. Find the Payment box and replace [input] with:

[input autocomplete="cc-number"]

After saving, open the form in a browser and make sure the card field behaves as expected. If autocomplete hurts the user experience or conflicts with your project's security policy, the rollback is simple: restore [input] without the attribute.

Custom Invoice Number Through a Documented Filter

Formidable documents the frm_authnet_invoice_num filter, which changes the invoice number sent to Authorize.Net. Not every site needs this. It is useful when the site already has its own internal application numbering and you need the payment tied to that number. Add the code through a child theme or the Code Snippets plugin, not into WordPress core and not into Formidable files.

add_filter( 'frm_authnet_invoice_num', 'my_authnet_invoice_number', 10, 2 );

function my_authnet_invoice_number( $invoice_number, $args ) {
    if ( empty( $args['entry_id'] ) ) {
        return $invoice_number;
    }

    return 'EVENT-' . absint( $args['entry_id'] );
}

Verification is simple: run a test payment and compare the invoice number in Authorize.Net with the Formidable entry ID. If you do not need the number or it conflicts with your accounting workflow, disable the snippet. Do not overcomplicate this filter with calls to external services - the payment flow should remain fast and predictable.

Limits, Security, and Architectural Decisions

The main limitation of Formidable Authorize.Net is the lack of recurring payments support in the official documentation for this add-on. That does not mean Authorize.Net as a service cannot handle recurring payments at all, but this specific Formidable Authorize.Net integration is documented as a one-time payments solution. So the article should not promise subscriptions, recurring charges, or membership plans without separately checking the documentation for your version.

The second important point is how payment data is handled. The Payment field page clearly warns that storing the full card number is not recommended and creates additional responsibility. For most sites, it is more sensible to store the bare minimum: the last four digits or only the expiration date, if your selected mode and recordkeeping requirements allow it. If the project is subject to strict payment or industry compliance requirements, the setup should be reviewed by a security and payment infrastructure specialist.

When WooCommerce Is a Better Fit

If the payment is part of an order with products, inventory, shipping, taxes, coupons, and statuses, WooCommerce gives you a more appropriate data model. Formidable can still be used alongside WooCommerce for complex forms, but you should not force a payment form to act like a shopping cart when what you really need is a full order system.

When Stripe or PayPal May Be Better

Stripe in Formidable may be more convenient if you need modern payment methods, broad geographic coverage, and a more familiar integration for international projects. PayPal may be simpler for an audience that already trusts PayPal accounts. Authorize.Net is more often chosen when a business already has a merchant account, needs integration with a specific gateway, and wants tight control over the on-site form experience.

This comparison should not turn into a generic ranking. Focus on the use case: a form with one-time payment and an Authorize.Net account is where Formidable Authorize.Net is strongest; subscriptions, global payment methods, or full ecommerce are good reasons to evaluate other tools.

Use Cases Where a Form Works Better Than a Standard Cart

To decide whether Formidable Authorize.Net fits a specific site, it helps to look beyond the fact that a payment is being taken and focus on the data that needs to be collected with that payment. If the user needs to choose a product from a catalog, add it to a cart, and receive a shippable order, a form usually loses to a store. But if the real value is in an application, registration, calculation, or request, the form gives you more control with fewer unnecessary steps.

Paying for a Consultation or Service

For a consultation, the form can collect the name, email, phone number, topic, preferred time, agreement to terms, and a fixed payment amount. There is no real reason to create a product, cart, and checkout flow here. What matters far more is that the administrator receives a structured entry and the client gets confirmation after a successful payment. In Formidable, it is convenient to tie the amount to the selected consultation type and send different emails depending on the option chosen.

What to Check in This Scenario

• The email to the specialist is sent only after a successful payment if the consultation is paid.
• The entry clearly shows the selected time and service type, so you do not have to look for details inside Authorize.Net.
• The receipt text does not promise a consultation date if scheduling is confirmed manually.

Event Registration

For an event, the form is often more important than the store: you need to collect the attendee's full name, organization, number of participants, attendance format, agreement to the rules, and sometimes meal preferences or extra options. The payment action should pull the final amount from the calculation, and the participant notification should only run after payment. If there are multiple price tiers, show the total next to the submit button so the user does not discover the cost only after entering a card.

If an invoice is needed for accounting, you can use the documented invoice number filter or a separate internal number field, but do not edit the plugin files. For the support team, it is useful to include the entry ID and a short tier description in the email. That makes it easier to match the payment in Authorize.Net with the Formidable entry.

Donation Form with a User-Selected Amount

A donation form usually depends on trust and clarity. The user should understand how much they are sending, whether the payment is one time, and what confirmation they will receive. Since Formidable Authorize.Net is documented as a one-time payments solution, do not present this flow as a subscription or promise recurring billing. If you need monthly support payments, choose another tool or a separate verified integration.

For donations, quick amount options and an "Other Amount" field are helpful. But a custom amount field must include minimum validation: an empty value, zero, or a negative number should never reach the payment action. After testing, verify not only the successful payment but also the decline flow, because the user should be able to correct their information without losing the completed form.

Invoice Payment Form

If a company sends an invoice outside the site, the form can accept the invoice number, email, and amount. This use case requires extra care: if the amount is supposed to match an internal document, it is better not to let the user change it. If the amount is entered manually, add a clear admin review step and do not send an automatic "invoice paid" email until the payment has been reconciled.

Practical rule of thumb: the more the payment depends on form data, the more useful Formidable becomes. The more it depends on a catalog, inventory, and order status, the stronger the case for WooCommerce.

How to Design the Payment Page So Users Do Not Abandon the Form

Even a correctly connected gateway can lose payments if the page feels confusing. The user needs to see what they are paying for, how much they are sending, which fields are required, and what will happen after they click the button. For form-based payments in particular, do not hide the key summary information at the bottom of a long questionnaire.

Page Structure

Before the form, add a short explanation: the purpose of the payment, that it is a one-time charge, what will arrive by email, and where to go for help if there is a problem. Do not place long legal text before the first field. If terms are required, use a separate link and a consent checkbox. Inside the form, group the sections logically: customer details, service or amount selection, payment details, and confirmation.

The submit button should describe the action. For a payment form, "Pay and Submit Registration" is better than a generic "Submit." If the payment may go through eCheck and confirmation is not immediate, the post-submission message should explain that the request has been received and is waiting for payment processing to complete.

Mobile Testing

Many payments are submitted from a phone, but that does not mean the form should be designed like a mobile app. Just make sure the card fields do not collapse, labels stay readable, the gateway selection does not run off the screen, and the total amount is visible before the button. If the site theme changes field widths or hides validation errors, fix the theme CSS rather than the payment logic.

Minimal CSS for a Visible Total Block

If your form includes a total amount block, you can highlight it with CSS in the theme or another safe place for custom styles. Choose the class based on your form's actual HTML. The example below shows the idea, not a universal selector for every site:

.frm-payment-summary {
    padding: 16px;
    border: 1px solid #d8dee8;
    background: #f7f9fc;
    border-radius: 6px;
}

.frm-payment-summary .frm-total {
    font-size: 1.25rem;
    font-weight: 700;
}

Check the result on the form page and on a mobile screen. If the style does not apply, do not scatter random !important rules everywhere. First inspect the actual block class in the browser tools, or configure a separate HTML block inside the form with a clear class. The rollback is simple - remove the CSS or restore the previous class.

Why the Payment Fails and How to Diagnose the Error

Start troubleshooting with facts, not guesses. Formidable's official instructions point directly to the log file: plugins/formidable-authorize-net/formidable-payments/log/results.log. If payments are not completing, open the log and review the most recent entries. If file access is restricted, ask your developer or hosting provider to export the relevant section without exposing secrets.

E00007 User authentication failed

Symptom: the payment does not complete, and the log or response shows E00007 User authentication failed. Likely cause: incorrect API credentials, an extra space in the key, the sandbox/live environment is mixed up, or the transaction key is outdated. What to check: API Login ID, Transaction Key, Signature Key, the environment mode in Formidable, and the type of Authorize.Net account. How to fix it: generate a new transaction key, paste the values again into Formidable - Global Settings - Payments - Authorize.Net, save, and rerun the sandbox test.

The User Cannot Submit the Form Because Hidden Required Fields Are Blocking It

Symptom: when card is selected, the form still requires a banking field, and when eCheck is selected, it still requires the card field. Likely cause: conditional logic hides the fields visually, but their required status does not match the selected Gateway field. What to check: the Payment Gateway equals authnet_aim and authnet_echeck conditions, and the required status of the routing number, account number, bank name, and credit card field. How to fix it: configure the conditions for each payment method and test both scenarios separately.

The Success Email Is Sent Before the Payment Actually Clears

Symptom: the customer receives confirmation even though the payment failed or is still processing. Likely cause: the email action is triggered on Entry is created instead of Successful Payment. What to check: the Trigger this action when setting for the email and any related actions. How to fix it: use the successful payment trigger for payment confirmations. For eCheck, add a separate pending-state flow because confirmation may arrive later.

eCheck Stays in an Intermediate State for Too Long

Symptom: card payments finish quickly, but eCheck does not trigger the success email right away. Likely cause: eCheck is processed differently and may not complete immediately. Formidable's documentation says eCheck completion is checked periodically. What to check: the record in Authorize.Net, the Formidable log, and the post-payment action settings. How to fix it: do not promise instant access for eCheck - use separate confirmation wording and an internal status review.

The Error Only Appears on the Public Page, Not in the Admin Preview

Symptom: the form works in preview but breaks on the published page. Likely cause: caching, script optimization, a theme conflict, or a conflict with another plugin. Formidable's official conflict troubleshooting recommends temporarily disabling unnecessary plugins, removing custom code, switching to a default theme, updating Formidable and WordPress, and clearing site and browser cache. How to fix it: test on a site copy or in a safe maintenance window, re-enabling components one at a time.

When Formidable Authorize.Net Is a Strong Choice

Formidable Authorize.Net works well when you need a controlled payment form rather than a shopping cart: collect data, accept a one-time payment through Authorize.Net, send a notification after a successful payment, and display a receipt. Its strongest use cases are scenarios where the form is the main interface: registration, application, service payment, one-time fee, custom order, simple donation, or a cost calculation flow.

Before launch, verify three things: working SSL, the correct keys for the correct environment, and the right post-payment actions. Then run your test scenarios: successful card payment, declined card, eCheck if enabled, hidden fields, email after payment, and receipt. If that path works without errors, you can move on to live validation and publish the form for users.

If, after testing, you decide the product fits the job, you can get the Formidable Authorize.Net file and test it safely on a staging copy of the site or in a restricted environment. Do not put a payment form in front of live traffic immediately - payments require stricter validation than a standard contact form.