The URL to the registration page is http://scottgoodwinassociates.com/emergency-simulation-subscription/. If you enter fake info for the registration and you can select visa with a card number of 4444444444444444, so that you get past the initial popup warning, you can see the bug in action.
Also, I enabled debugging in Safari and the only thing that comes up in the console is CSS issues, but nothing Javascript related.
You may need to report this as a bug here:
https://github.com/WebSharks/s2Member/issues
I’ve experienced the “processing… processing” issue before as well. I officially reported it but we couldn’t reproduce it or figure out what could have been happening. I was never able to successfully reproduce it.
I too have v140328 installed. Tried to perform a test checkout on my dev machine using mobile Safari, and it went through fine.
There’s a post on the late s2member community forums about this as well:
https://www.s2member.com/forums/topic/form-stuck-on-processing/
This is an odd one because there’s no backend way to detect or log this sort of problem due to this being a client-side issue. I mean, the “processing… processing…” thing takes place in the user’s browser and doesn’t appear to actually submit the form anywhere. The s2member JavaScript intercept the form submission and doesn’t send it to the payment gateway for processing. It’s just stuck in limbo.
This prevents any backend logging from WordPress’ debug.log to s2member’s various payment logs to collect any data on what funny business may be happening.
Since your live installation is able to reproduce this consistently, it really may be best to report this as a github bug that they evaluate and reproduce on their end.
Thank you jumbo. I create a bug report. It ended up being an issue with allowing a custom password to be created on registration. So for no I set the option to no and it seems to be working.
I’ve tested s2Member Authorize.Net Pro-Forms using both an iPhone 5 and an iPad, both running iOS 7 and using the stock Safari browser. I tested it with and without Custom Passwords enabled and in both cases the Authorize.Net Pro-Form submits properly.
Here’s a YouTube video of me successfully testing an Authorize.Net Pro-Form using Safari on an iPad running iOS 7: https://www.youtube.com/watch?v=SDROFSRsKu4
I have been entirely unable to reproduce any issue submitting Authorize.Net Pro-Forms on iOS.