payment is not captured until the end of submission

[teewuane]

I'm running into an issue where I think our email server is timing out so emails aren't being sent.

But what happens is the entry is submitted, it is stored in the db, the SMTP request (on of them, to staff or to the contact) times out.

So we never submit the payment to our processor (authorize.net). But the entry is still submitted.

I'd like to talk about changing the email requests to being asynchronous and moving the payment step up so that it captures payment first before even storing the records in the db.

[devinemke]

The general priority here is the upload of the submission file, and the commit to the database. Sending out email notifications and interacting with payment gateways is of course important, but considered secondary. Submissions, once captured, can always be paid later. Submitters can click pay now in their submission history dashboard when logged into their accounts.

Do you have access to SMTP logs to figure out what is happening with outgoing mail?

[teewuane]

That makes sense. We did find out that the SMTP password changed so that was the issue, but it's a blocking issue. I'd like to maybe make a pull request that changes those smtp calls to be async. (I'm not super familiar with php but I'll figure it out assuming there is a way to do it haha)

[devinemke]

Let me figure out the best way to implement this. How about a simple boolean in the General Configuration called halt_on_mail_error or some such? When checked (the default) the submission process will halt and throw an error if the mail send returns false. When unchecked, the mail send will fail silently, and carry on with the rest of the process (including connecting to a payment gateway, if configured). There should still be some visual feedback that the mail failed, but again, the rest of the process will carry on.

This would be a global setting that would affect every SM function that sends mail (not just submissions). What say you?

[devinemke]

@teewuane Ok I have implemented this requested feature.
As discussed there is a new configuration directive called halt_on_mail_error which defaults to true.

When true all form processes that send mail will stop when a mail error is encountered.
When false the process will carry on and a generic error message will be displayed at the end:

- Form processed, but a mail error has occurred. Please check SMTP logs for more details.

Remember to run the data structure update so that this new configuration directive is added properly.
Please test and make sure that this solves your problem. If so please close this issue. Thanks. -DE