Hm, this is an interesting case you've got here. We have noticed this behavior before, but extremely infrequently and could not successfully determine the cause.
What you've presented seems like a valid reason as to why this is getting dropped on the floor, although if it redirects from POST to GET and then returns a 404, it seems like it would never make it to your application code at all.
What is your '/main/checkout/process' method in your controller annotated with? I believe the Authorize.net docs say that it sends a POST to your application, so it should be annotated with @RequestMapping(method=RequestMethod.POST).
Another thing I would check is your http vs https configuration. I know Authorize.net will error out if it tries to connect to an https URL that has an invalid certificate, which could happen if you are on some QA/dev server that doesn't have the right SSL certificates installed. The fix for this would be to configure spring security to use http for the process url on your QA/dev server, but then use https for production (where the certificates should be installed).
Keep us posted on additional information you find. Thanks!
The Broadleaf forums are being retired as a readonly archive of questions. For active discussions and questions, check out the broadleaf-commerce tag on Stack Overflow
which is actively monitored by the Broadleaf team.