Jump to content
  • Checkout
  • Login
  • Get in touch

osCommerce

The e-commerce.

Sale emails NOT sending to admin


DesertCoder

Recommended Posts

All,

 

One of my stores is not sending sales emails to the admin email address. When I run a test transaction through our third-party biller, it works like a champ. I get the confirmation from the store with the full order and shipping info.

 

When a real customer makes an order we don't get the email to the admin email address. In fact, I can't even find record of the sale in the admin area. From my research, this seems to be a common problem, but no clear cut answers to help me figure this out.

 

I tried switching from sendmail to SMTP, the results are the same, we get email from test transactions, but not from real buyers and still no record in admin.

 

Specs:

osc 2.3.3

 

Server OS: Linux 3.2.45

Database: MySQL 5.5.30-30.2

HTTP Server: Apache

PHP Version: 5.2.17 (Zend: 2.2.0)

 

Shared hosting on Host Gator

 

Any suggestions would be greatly appreciated.

 

Sincerely,

 

DesertCoder

Link to comment
Share on other sites

Hi - which payment processor are you using? Sounds like your store is maybe creating the order after payment callback/customer return from the payment company - in your test mode that's coming through but in live mode it's not. Hard to guess without knowing the company but have a look and see if there is a different callback/return method for live vs test

Link to comment
Share on other sites

@@Bob Terveuren @@cloudhosting14 we are using CCBill. There is an osc add on that allows the store to communicate with CCBill, and as seen in the test transaction, everything works fine. Butthe fact that NO DATA is showing up in the Admin area and we get no emails is maddening.

 

The process for testing is the exact same process as a real order. Sleect an item, go through checkout and then when the customer gets to order confirmation and clicks the 'Confirm Order' button, they are taken to CCBill's site where they provide their credit card info. Once the process is approved (or denird), they are automatically redirected back to our store. Test or real transaction, that's how it works.

 

So we get emails for test transactions, but not for real ones and no data is collected in Admin.

 

If there is any other info needed, please let me know. This is killing us.

 

Cheers,

 

DesertCoder

Link to comment
Share on other sites

@@Bob Terveuren @@cloudhosting14 To further clarify, there is no test mode. The biller, CCBill, provides us with a list of credit card numbers in their system to allow us to run test transactions. So the same process is being used, the same web pages are being used, it's just that we're using a 'dummy' credit card number to run the tests. Everything else is the same.

 

That's why this is so confusing, because we DO GET order emails from these test transactions, just not for actual customer orders.

 

I hope that helps clarify the issue. If not, please let me know.

 

Cheers,

 

DesertCoder

Link to comment
Share on other sites

Hi

 

This one? http://addons.oscommerce.com/info/6141

 

The bank should send the customer back to www.yourstore.com/checkout_process.php where the code in the function before_process() in the addon should kick in:

 


function before_process(){
global $HTTP_GET_VARS;
//Check to ensure all needed information is passed back
if (($HTTP_GET_VARS['subscription_id'] == '' || $HTTP_GET_VARS['responseDigest'] == '') && ($HTTP_GET_VARS['reasonForDecline'] == '')){
tep_redirect(tep_href_link(FILENAME_CHECKOUT_PAYMENT, tep_session_name() . '=' . $HTTP_GET_VARS[tep_session_name()] . '&payment_error=' . $this->code . "&reasonForDecline=" . urlencode("Error in configuration, please contact website owner"), 'SSL', false, false));
}
if ($HTTP_GET_VARS['subscription_id'] != ''){
//valid the subscription_id with the md5 and salt
$responseDigest = md5($HTTP_GET_VARS['subscription_id'] . 1 . MODULE_PAYMENT_CCBILL_DYNAMICPRICING_SALT);
//If Digest Does not match fail transaction (hacking attempt)
if (strcmp($responseDigest, $HTTP_GET_VARS['responseDigest']) != 0){
tep_redirect(tep_href_link(FILENAME_CHECKOUT_PAYMENT, tep_session_name() . '=' . $HTTP_GET_VARS[tep_session_name()] . '&payment_error=' . $this->code . "&reasonForDecline=" . urlencode("Digest Does Not Match"), 'SSL', false, false));
}
}
else {
//Transaction failed, redirect back to checkout page with the decline reason
tep_redirect(tep_href_link(FILENAME_CHECKOUT_PAYMENT, tep_session_name() . '=' . $HTTP_GET_VARS[tep_session_name()] . '&payment_error=' . $this->code . "&reasonForDecline=" . urlencode($HTTP_GET_VARS['reasonForDecline']), 'SSL', false, false));
}
}

 

There's three places in there that the intended order can get booted back to checkout_payment - if that is happening to a valid payment then you're not going to get any order registered in your store and no emails.

 

You could narrow it down a bit by looking to the url in checkout_payment and see if you can match the error shown to 'Digest Does not Match', 'Error in config....' etc

 

There's no mention of any differences between test & live card transactions in their docs - any chance there is some sort of admin setting at their end that needs a tweak?

 

If, on the other hand, the return from the bank is not going to checkout_payment but you are getting some other problem then it's likely not that function!

Link to comment
Share on other sites

@@Bob Terveuren Thank you for that very thorough answer. I just ran another test transaction and again, I received the email as I should have. BUT, I notice in the URL that checkout_success.php is part of the return path. Could this be the problem, and if so, why would I get emails for the test transaction but not for real ones?

 

Thank you so much for your help, I appreciate it!

 

Cheers,

 

DesertCoder

Link to comment
Share on other sites

@@Bob Terveuren Correction, the approval URL DOES direct back to checkout_process.php, I checked with the biller on the URL:

 

www . sitename.com/store/checkout_process.php?subscription_id=%%subscription_id%%&osCsid=%%osCsid%%&responseDigest=%%responseDigest%%

 

I mistook checkout_success.php in the final store notice that my transaction was approved. I hope this helps?

 

And yes, the link to the add on you posted is correct.

 

Lastly, the test transaction performs perfectly, no errors, no problems.

 

Cheers,

 

DesertCoder

Link to comment
Share on other sites

Hi

OK if your valid transaction is coming back to something like www .sitename.com/store/checkout_process.php?subscription_id=%%subscription_id%%&osCsid=%%osCsid%%&responseDigest=%%responseDigest%%

 

then it's failing in the function I pasted above as one (or more) of the values coming back from the bank are missing, the md5 check is failing or possibly the PHP session is getting lost. - for whatever reason what's broken in the live cards is not broken with a test card

 

You can check if it is the HTTP_GET stuff by substituting something like this

 

function before_process(){
global $HTTP_GET_VARS;
//Check to ensure all needed information is passed back
if (($HTTP_GET_VARS['subscription_id'] == '' || $HTTP_GET_VARS['responseDigest'] == '') && ($HTTP_GET_VARS['reasonForDecline'] == '')){
//tep_redirect(tep_href_link(FILENAME_CHECKOUT_PAYMENT, tep_session_name() . '=' . $HTTP_GET_VARS[tep_session_name()] . '&payment_error=' . $this->code . "&reasonForDecline=" . urlencode("Error in configuration, please contact website owner"), 'SSL', false, false));
exit('1.Empty variable');
}
if ($HTTP_GET_VARS['subscription_id'] != ''){
//valid the subscription_id with the md5 and salt
$responseDigest = md5($HTTP_GET_VARS['subscription_id'] . 1 . MODULE_PAYMENT_CCBILL_DYNAMICPRICING_SALT);
//If Digest Does not match fail transaction (hacking attempt)
if (strcmp($responseDigest, $HTTP_GET_VARS['responseDigest']) != 0){
//tep_redirect(tep_href_link(FILENAME_CHECKOUT_PAYMENT, tep_session_name() . '=' . $HTTP_GET_VARS[tep_session_name()] . '&payment_error=' . $this->code . "&reasonForDecline=" . urlencode("Digest Does Not Match"), 'SSL', false, false));
exit('2.md5 failure');
}
}
else {
//Transaction failed, redirect back to checkout page with the decline reason
//tep_redirect(tep_href_link(FILENAME_CHECKOUT_PAYMENT, tep_session_name() . '=' . $HTTP_GET_VARS[tep_session_name()] . '&payment_error=' . $this->code . "&reasonForDecline=" . urlencode($HTTP_GET_VARS['reasonForDecline']), 'SSL', false, false));
exit('3.declined');
}
exit ('4. Something else');
}

 

Not tested it but hopefully no grammatical errors in the PHP - running a valid (or invalid) card through at CCBill should trip you to a white screen with just something like 2.md5 failure on it - if you run a valid card and end up at a proper page rather than an exit message then it' the session that's gone away.

 

If you look at the white screen then you should get 1... 2.... 3... or 4....

 

that should narrow down which bit is screwing up

Link to comment
Share on other sites

Archived

This topic is now archived and is closed to further replies.

×
×
  • Create New...