Error – Stripe field doesn’t exist

And here is another pastebin for you: the current form, the one that doesn’t use Stripe at all. Again, this form shows the correct total on screen, but after the form is submitted, the total is shown as $0 in the submissions, on-screen notification message and all confirmation emails.

https://pastebin.com/TqWnXQ2T
(expires on 2/19)

Hi @ostinatofreak

Sorry for the delay here.

Could you please update your formula to:

({radio-1})+({radio-4})+({radio-5})+({radio-6})+({radio-7})+({currency-1})

This worked when I submitted the shared test

https://monosnap.com/file/Y1tKWX069TwcGAN8Vxrp9fNHMxuAtb

Let us know the result you got.
Best Regards

Patrick Freitas

That new formula unfortunately didn’t work – I still got “This value must be greater than or equal to 1.”

But after my more recent posts, I’m starting to think this has less to do with the formula than it has to do with Forminator’s behind-the-scenes handling of calculation fields. The “Total” field in the form is showing up correctly whether I use ({field}) or just {field}… but the amount gets reset to 0 after the user clicks Submit.

Hey @ostinatofreak

Thanks for response and, once again, I’m sorry it takes so long.

But I think we might be onto something, may be a bug that’s yet not identified, but I’d like to ask you for a bit more help on this.

I tested again the form that you recently shared and while initially I wasn’t sure, after multiple tests I noticed that it actually does reset the “Total” after submit in most cases but… it seems it resets it to the value of “Optional $25…” option.

If I keep it at default 0, the total is always reset to 0. If I set it, it in most cases is reset to whatever value I put there. Upon all submissions I got a single combination of options which actually submitted correct value but I missed which one (and I’m certain it was due to combination of options and not just “random fact”).

But what I’d like to ask you would be to test this too:

1. see if you can confirm that it resets for you to the value of “Optional: $25…” field as well (after submission)

2. then also see if the same happens if you actually remove the calculation field from “thank you” message

3. and finally, if it also happens if instead of “currency” type field you use a regular “number” type field for that “Optional: $25…” field.

Kind regards,
Adam

1. I just used https://washoetennis.org/membership-old/ and did Junior Membership ($50) with optional $15 donation. The whole transaction went through correctly, charging me $65 on my credit card.
2. I went to change the “After submission” Inline message (is that what you were talking about?), and the message already has no calculation field. It just says “Membership complete – thank you for your support!” I also went to the email notifications, and the email sent to the New Member just has {name} and {all non empty fields}, nothing else. So it appears that my scenario #1 was actually a test of your #2. So to do your #1 item, I added {calculation-1} into the on-screen confirmation (“$xxx received”) and also the email notification that goes out to the new member. This time with Junior membership ($50) again and optional $5 donation. It went through correctly as $55.
3. I replaced the currency field with a number field and updated the Total to include that instead. I used $0 optional donation and Junior Membership ($50), and the transaction was successful – it charged me $50, and all confirmations/notifications correctly displayed $50. So it seems that your currency field has some kind of bug in how it is handled after submission.

Hi @ostinatofreak

Thank you for response!

So ultimately – the third scenario (p. 3) would seem to be the key here. If you use a “number” type field instead of “currency” type filed, it all works fine for you, right?

I’m sorry for making this thread even longer but a lot has already been tested and discussed so I just want to make absolutely sure that we are on the same side.

If you can confirm that, then:

1. a solution/workaround for now would be to keep using the number field instead of currency one

2. and I would do a bit more testing on my own forms on my end and then report this to our Forminator developers as a bug so they could investigate it and include permanent fix with one of future releases.

Kind regards,
Adam

Yes correct, the workaround is successful. A couple other people used the form, even after I added a few more visibility rules that were there before, and it works, charging the correct amount on the credit card. It looks like Forminator indeed has a problem involving the currency field.

Hi @ostinatofreak

I performed a few additional tests in the form and noticed that some radio buttons have the following character in the options value: “&”

For instance, options that include text like this:
“spouse-&-children”

Should be switched to
“spouse-and-children”

For security purposes, characters like “&” should not be included in the options values, since they are sanitized and then not recognized when submitted. That’s the reason why the values is showing at zero in the submissions. I tested several submissions just changing the text option values as advised and there were no issues even with the currency field.

Hope this information helps.

Kind regards

Luis

There are no fields in the entire form that have the ampersand character in it. (And the only place that even mentions spouse/children is the Relationship field, which offers the options “Spouse” and “Children” each as separate options.)

Hi @ostinatofreak

Thanks for response!

Actually, unless you have changed and edit your form and it’s different than the one you shared with us – there are ampersands and other “special characters” there indeed. I didn’t notice that before but I’ve re-imported the form that you shared with us and checked and I can confirm what Luis mentioned above: there are such characters there.

For example, fields radio-1, radio-4, radio-5, radio-6 and radio-7, which all take part in calculations.

I think Luis information might have caused a bit of confusion as it may appear to be referring to fields “Relationship” (like e.g. select-11) – which is not the case. I’m sorry about that.

That being said, we have surely established that the currency fields is an issue here previously but I didn’t notice those special characters before. According to test that Luis did, it seems to be related as well.

But if you can fully confirm that there are no ampersands in your current form (in fields like those “Membership Type” fields mentioned above) and yet – the currency field still needs to be replaced, then I think we can rule it out and focus on currency. Yet, I’d like to get your ultimate confirmation on this as this so we could avoid any further confusion and just report the issue to our Forminator developers for further investigation and fix on our end.

Kind regards,
Adam

Please tell me exactly which field and exactly which value in the form uses an ampersand. The ampersand is the only “special character” you have mentioned specifically.

I haven’t touched any of the radio button field values, and the form has been working fine with people using it to renew their memberships.

Hi @ostinatofreak,

I hope you are doing well today!

For the all values on fields, it is better to avoid any symbols including +,$,& etc. – or _ would be fine. Please update the values accordingly (first one is label second one is value) on all fields and it should work well.

https://prnt.sc/kkxrO2QVGOyC

Kind regards,
Zafer

“there are ampersands and other “special characters” there indeed.”

So it turns out there were no ampersands. That’s some really unclear communication. I guess the word “or” should have been used… or a different special character (one that’s actually in my form) should have been mentioned instead, such as “there are dollar signs and other special characters there.” Specifically telling me that there is an ampersand in the form (and other special characters) makes me think I’m not looking in the same place in my form that you’re looking. Someone had to see the $ and + symbols in the form… so why didn’t they say “$ and other special characters” instead of throwing me off with “ampersand and other special characters”?

Again I’m inclined to leave it as is for the time being. This is the worst time of the year to make any changes to a form that is working, right in the middle of membership renewal. There have already been 30 submissions, all with a variety of options selected and donation amounts inputted (some donating, others not), and all of the submissions were successful with the correct amounts charged in the final submission. I’m sure that special characters might cause some kind of problems in some Forminator forms, but evidently not this one. For the purposes of this particular form, the presence of the Currency field was the only factor that had any effect on the outcome.

For the next release of Forminator, are you going to just change the sanitization algorithm so that all special characters are removed? Looks like it already removes some such as the front slash – not sure why it only sanitizes that one but not others.

I guess one interesting question might be why the special characters in this form ($ and + and maybe the () symbols) are not causing it to malfunction in any ways that affect the final submission (or notifications/confirmations) for the end user.

Hi @ostinatofreak

“For the next release of Forminator, are you going to just change the sanitization algorithm so that all special characters are removed? Looks like it already removes some such as the front slash – not sure why it only sanitizes that one but not others.”

I don’t see a task to keep extending this, in general, we should not use the special characters on a field value but we keep monitoring our tickets and in case this becomes something that we need to review it is possible we implement some changes in the future.

Best Regards
Patrick Freitas