10 Commonly Reported Form Errors: Part One

Written by Amy Jorgenson on November 6, 2013

Posted in Form Optimization

Running into errors with your form? As a support specialist, I talk to hundreds of Formstack customers a week, and I come across some errors more than others. Because of this, I wanted to list 10 of my most commonly reported errors (and how to fix them!) in a two-part blog series. Whether you’re having form problems or not, check out this list as a reference for future issues you might encounter.

Today, we will cover the first five errors on my list:

1. “I am getting a ‘No Response’ in the Payment Status column of my Submissions Database.”
PayPal WPS: “No response” in the Payment Status column in your database can mean two things: users are abandoning the process when they are redirected to PayPal before actually paying OR that they took a very long time to actually complete their payment so there was a time-out in getting the status back to Formstack, ending in a “no response”.

Check your Paypal account. If you HAVE the funds in your PayPal account, then the second thing is happening. If you DON’T have the funds in your PayPal account, then people are not completing the payment process.

If the form correctly redirects to PayPal upon submission, then individuals CAN most likely submit their payment.

Other payment processors: You may not be connecting to your payment processor. This could be caused by a few things:

  • Incorrect API credentials: Check your API credentials in the integration settings and verify that they are correct. You may even need to request a new API.
  • You may have the integration switched off: Make sure you toggle the integration switch in the top right corner of the integration settings to “on”.
  • Your payment processor integration may be in “test” mode: Make sure you switch the integration mode to “production” or “live” when you are ready to begin accepting payments.

2. “Individuals are being charged several times what they are supposed to.” or “Individuals are being charged incorrectly.”
First, check your integration settings. If you have chosen the single item mapping option for your price field, you will have one price field and one quantity field to map to. Chances are, you are mapping the Total field from your form to the price/amount field in the integration settings and you probably have the quantities built into that total field on your form. In this case, make sure you don’t have something mapped to the quantity field in your integration settings, since it is built into your total field. You can leave the quantity field unmapped – which we automatically assume as “1”. If you have done this, don’t worry! It is a common mistake.

Second, make sure your total or price field default calculations are correct. If there are multiple fields involved in the final calculation, you may need to trace it back to each of those fields and ensure that the proper value is set on those fields and options.

Third, if you are choosing to map to multiple items, make sure EACH item has their OWN price field (and quantity field if necessary) and that they are mapped accordingly. If you choose this type of mapping, the items cannot all exist in one field. For example, choosing to map to multiple items when your items all exist in a single Select List field on your form with their associated values will not work. You have to put them in their own field – possibly separate Checkbox fields with only one option on each field and then their own corresponding quantity fields if necessary.

3. General “Invalid XML”
Constant Contact: So, individuals are not being added to your lists in CTCT. You go to refresh your lists in Formstack in case they are out of sync with the lists in CTCT, but you get an “Invalid XML” error when you attempt to refresh your lists. This is because your CTCT credentials are incorrect. Click “login” at the top of the integration settings and follow the steps to re-grant access to a valid CTCT account.

Other integrations: Somewhere, you or an end-user, is submitting an invalid character to a 3rd party integration. The common invalid character culprits are:

<

>

,

&

/

The comma and apostrophe are included in this list because if that character is copied from an outside source (as opposed to typed directly into a field) it may not be the exact character. Basically, copying and pasting is a “no-no” unless you paste it into something like Notepad first to strip the formatting.

If one of the characters listed above is in one of your field labels, values, or options, and you are getting the “invalid XML” error, remove it! If someone submitted it on your form, you can edit the individual submission record, remove that character, and rerun the integration.

4. “I’ve tried many things and when my form is submitted it just won’t invoke PayPal WPS. Just the standard completion message comes up.”
The problem is, you cannot have two redirects at the same time – PayPal WPS and the Thank You message (or any other Submit Action that redirects). If you offer multiple payment methods, or only some are paying via PayPal WPS, you can have multiple redirect Submit Actions, but you will need to add Routing Logic to those redirect Submit Actions so that they occur at separate times, based on separate conditions.

For example, if you offer payment via check or PayPal WPS, you can still set up a Thank You message to appear if individuals opt to pay by check. Just make sure you apply Routing Logic to the PayPal WPS Submit Action to only run if payment method is credit card/PayPal (made in a field selection on your form).

5. “Please fill in a valid value for all required fields.”

This error will pop up at the time of submission if you have either not answered a required field, OR if your answer is not in the proper format (i.e. email address, phone, or address field).

Hopefully you can use this list in the future if you encounter any of these errors in the app. Have questions about any of the errors? Please feel free to ask in the comments below – and stay tuned for the second half of these questions in part two of the “Commonly Reported Errors” series!