Inappropriate “PayPal amount must be greater than 0” message

Hi @dholtzman

I hope you’re well today and thank you for contacting us!

Based on your description I can tell that we are dealing with two issues here:

1. The “0 value” issue

In most cases such issues are in some way related to complex calculations and/or visibility conditions but that’s a general information. We’d need to analyze and test the form itself to tell more and it would be best if you could share export of the form with us.

To do so:

– go to the “Forminator -> Forms” page
– click on a little “gear” icon next to the form in question
– select “Export” option
– copy given export code and put it on https://pastebin.com
– include link to that “paste” in your response below.

Note: this will only share the form itself; all the data that has been submitted so far, as well as all your PayPal/Stripe/Captcha and similar integration keys will safely stay on your site and will not be included in export (we don’t need them anyway).

2. The “resubmit” issue with PayPal

This is, unfortuantely, a bug in the plugin. If the form is correctly filled-in (so all required fields are provided and there’s no validation errors) right in the “first go” – payment will work.

But if either form gives an error or PayPal payment is not completed (e.g. you cancel it/close window) and then you try to re-submit it – it won’t work. The only way in this case currently is to reload the page with the form and fill-in the form from scratch.

This is a bug and our developers are already aware of it and working on the fix. It’s a relatively fresh discovery and I’m afraid I don’t have ETA on the fix yet – but it is “on the table” so should be fixed in one of upcoming releases.

Best regards,
Adam

Thanks very much for your quick and helpful response. We do indeed have “…complex calculations and/or visibility conditions.” The exported form is here: https://pastebin.com/vVx8hEW6.

Hi @dholtzman,

I tested the form in my system but I couldn’t replicate the exact issue. Seems like it works fine in “Sandbox” mode and more specifically with “Live” mode.

Could you please check and see whether you are able to replicate the same issue when you switch the PayPal field to “Sandbox” mode?

If you can confirm the issue is only with Live, could you please check how it behaves if you try changing the “Visibility” from “Hide” to”Show” as mentioned in the following screenshot:

Screenshot at 18:30:36.png

Please do make sure to delete the PayPal field 1st save the form and then re-add the PayPal field before applying the above visibility.

Please do let us know how that goes.

Kind Regards,

Nithin

Thank you again.

I have confirmed that this issue occurs in Sandbox as well as Live mode. Despite this, I tried the steps you suggested on our test site, as well as several other changes to simplify the form. Finally, I reproduced the issue on a test form with only three fields: a currency field, a required checkbox, and a PayPal field with the amount taken from the currency field. So calculations and visibility conditions were not the source of the problem in this case.

This led me back to a thread that I wish I had read more carefully the first time I saw it: https://www.ads-software.com/support/topic/paypal-amount-must-be-greater-than-0/. It appears that unless there is a default value in the field used for the PayPal Amount, the “PayPal amount must be greater than 0” message displays when the form is submitted with required fields omitted. If there is a default value, the correct error message displays (“Please correct the errors before submission”).

Our problem now is that we do not want to have preselected defaults in the fields that may contribute to the Total field: the three “Subscriptions” radio-button fields and Donation. The only workaround I have come up with is to create a number field with an arbitrary default value, include it in the Total calculation, set it to be hidden when there are values in the subscription or Donation fields so that it no longer affects the Total, and then hide it completely from the user with CSS.

This appears to be working on our test site, but it is a bit of a kludge. Do you have a better solution? Or have I missed something along the way? Thanks.

Hello @dholtzman,

Thank you for the detailed explanation!

I was able to reproduce the same issue, and have reported this to the developers for further troubleshooting.

We’re also awaiting their feedback on other possible workarounds, and will let you know when there’s an update.

Please note, that it may take us longer to reply than before, depending on the complexity of the tasks the devs are currently working on.

Best Regards,
Dmytro

Hi @dholtzman

I got response form our developers.

Would you please try with this code added to the site?

add_action('wp_footer', 'wpmudev_fix_paypal_error_message', 9999);
function wpmudev_fix_paypal_error_message() {
    global $post;
    if ( is_a( $post, 'WP_Post' ) && !has_shortcode($post->post_content, 'forminator_form') ) {
        return;
    }
	?>
	<script type="text/javascript">
	jQuery(document).ready(function($) {
        setTimeout(function() {
			$('.forminator-custom-form').trigger('after.load.forminator');
		},100);

		$(document).on('after.load.forminator', function(e, form_id) {
			if ( e.target.id == 'forminator-module-448' ) { //Please change the form ID
                $('.forminator-response-message').on('DOMSubtreeModified', function(){
                    var payment_error = $(this).find('.forminator-label--error span').text();
                    if ( payment_error == 'PayPal amount must be greater than 0.' ) {
                        $(this).find('.forminator-label--error span').text('Please correct the errors before submission.');
                    }
                });
            }
        });
    });
    </script>
    <?php
}

To add it:

– create an empty file with a .php extension (e.g. forminator-paypal-value-fix.php)
– copy and paste above code into it
– replace the number 448 in this part

forminator-module-448

with an ID of your form (form ID is the number you see in form’s shortcode)

– save the file and upload it to the “/wp-content/mu-plugins” folder of your site’s WordPress installation

Best regards,
Adam

Thank you!

In order to make this code work, I had to add an opening PHP tag at the beginning, and unselect the “Load form using AJAX” behavior option. Is changing this setting likely to cause any issues?

Since the code includes the new error message text, we modified this to let users know they need to reload the form and start over before correcting errors. We still hope you will be able to fix this issue in a future update!

Our form toggles between PayPal buttons and a Submit button. We just noticed that it is possible to correct and resubmit the form when the Submit button is active–the issue only affects PayPal submissions. Is this correct?

We also noticed that when there are omitted required fields with no PayPal button, there is no error message at the top of the form. Instead the page scrolls up to the first omitted field. Is there a reason why the “Please correct the errors before submission” message is not generated in these cases?

Finally, we are using an updated mu-plugin you sent us last May to toggle between the PayPal and Submit buttons, but I see that there is also a “Switch PayPal field’s visibility with Submit button” option in the PayPal field Advanced tab. From very brief testing, this seems to do the same thing. Is there a difference between the two approaches?

I apologize for all the additional questions. We’re trying to understand this as thoroughly as possible. Thanks again.

Hi @dholtzman

In order to make this code work, I had to add an opening PHP tag at the beginning, and unselect the “Load form using AJAX” behavior option. Is changing this setting likely to cause any issues?

In case you are using it in child theme > functions php usually tag is already opened but in case a mu-plugin yes the tag is necessary.

About the load from Ajax, the code should work with or without that,

If you are using Load from Ajax you can remove this line:

 setTimeout(function() {
			$('.forminator-custom-form').trigger('after.load.forminator');
		},100);

Our form toggles between PayPal buttons and a Submit button. We just noticed that it is possible to correct and resubmit the form when the Submit button is active–the issue only affects PayPal submissions. Is this correct?

It is correct, the issue is only affecting the PayPal field, if it is hidden the Form is going to bypass the payment not returning the error.

We also noticed that when there are omitted required fields with no PayPal button, there is no error message at the top of the form. Instead the page scrolls up to the first omitted field. Is there a reason why the “Please correct the errors before submission” message is not generated in these cases?

The top form it will return a generic response but it should then return field level the correct one, for example “this field is required”, in case it isn’t happening can you share the form configured to replicate this issue?

Finally, we are using an updated mu-plugin you sent us last May to toggle between the PayPal and Submit buttons, but I see that there is also a “Switch PayPal field’s visibility with Submit button” option in the PayPal field Advanced tab. From very brief testing, this seems to do the same thing. Is there a difference between the two approaches?

I guess you are referring to https://www.ads-software.com/support/topic/an-error-occurred-while-processing-the-form-2/

That code is to switch visibility without the need to re-enter a new one, for example:

If the button submit shows with option X then PayPal will not show, but if you select option Y then the submit button hide and PayPal will show up, Using the default visibility you would need to configure both rules, in the PayPal and Submission button while the code should automate it a bit.

But it is a custom code so we can’t guarantee it keep working in future updates, I would go with the visibility rules from PayPal instead.

Best Regards
Patrick Freitas

Hi @dholtzman

We haven’t heard from you in a while, I’ll go and mark this thread as resolved. If you have any additional questions or require further help, please let us know!

Kind Regards,
Kris