Need help with Virtual Merchant module

[kehrli]

Anyone ever figure out how to get virtualmerchant_today.php to work? I don't know how to even call it. When I try to specify the path to the file, my server gives a file not found error. There's something basic about how the store protects itself from people calling up specific php files that I don't understand.

But this should be a question that's not virutal merchant specific. I have a php file I want to call that's located down in the logs directory. How do I call it?

[rtw819]

Anyone ever figure out how to get virtualmerchant_today.php to work? I don't know how to even call it. When I try to specify the path to the file, my server gives a file not found error. There's something basic about how the store protects itself from people calling up specific php files that I don't understand.

But this should be a question that's not virutal merchant specific. I have a php file I want to call that's located down in the logs directory. How do I call it?

A few suggestions...

I would first recommend checking permissions on the folders leading to the log folder. You may also need to add or update the virtualmerchant_today.php script itself to match the filename prefix chosen in your configs. (Update the file prefix in the $extra variable in that file.)

If your web server's folder permissions are set to permit access to the files in the log folder, and if you know the path to the file itself, add it to your web browser's URL entry, and see if it comes up. You could try to view one of the log files directly if the PHP file doesn't load.

Example: https://my-zen-store.com/catalog/_some_long_path_to_log_folder_/virtualmerchant_today.php

Example 2: https://my-zen-store.com/catalog/includes/modules/payment/logs/virtualmerchant_today.php

Hope this helps.

[kehrli]

Thanks. That actually helped a lot. It got me to digging around and I realized I have simple SEO url installed, and I think that must be redirecting my attempts to directly access certain files. Either that or ZenCart (1.3.9h) is doing it.

I did a test, trying to access a files in higher directories. I can access files in my root directory. But when I try to access one in my includes directory, I get my store's 'page not found' screen. I used the same file in both locations. The permissions for both directories is 755 and permissions for the file in both locations is 644. When I access the one in the root it displays fine. The one in includes is "page not found".

Its really not that important, so don't bust a nut on this one. I just don't understand what mechanism is causing this, and I'd like to. But other than that, I can view my logs using encrypted FTP.

[kehrli]

I've been having an odyssey trying to debug a problem that I developed with the VM module after upgrading from 1.3.8a to 1.3.9h:

The error happens when I deliberately put in a bad credit card number. I get a blank page. I can't get a php error to show up anywhere, but it does issue the error email. So, by trial and error I've finally gotten down to the point where the 2 ZC versions seem to handle this integration differently.

It's when the VM module makes the call to redirect back to the checkout_payment page. The code being called is:

zen_redirect(zen_href_link(FILENAME_CHECKOUT_PAYMENT, $payment_error_return, 'SSL', true, false));

When that line of code executes in ZC 1.3.9h, it gives a blank page. But when it executes in ZC 1.3.8a, it works fine, and the error message is displayed to the customer (I have 2 other stores that haven't been upgraded yet, so could test it).

The URL that is called in each case, with the embedded message, is:

https://www.fuelsaver-mpg.com/checkout_payment/virtualmerchant_cc_owner/Mike%20Kehrli/virtualmerchant_cc_expires_month/04/virtualmerchant_cc_expires_year/11/virtualmerchant_cvv_number/566/virtualmerchant_cvv_indicator/1?payment_error=virtualmerchant&error=The+credit+card+number+entered+is+invalid.+Please+check+the+number+and+try+again.

However, when that call is executed in 1.3.8a, it works. When executed in 1.3.9h, it gives a white page. The only other clue is that the title metatag for the 2 pages is different. The titles read as follows:

1.3.8a

Step 2 of 3 - Payment Information : Unscented Products

1.3.9h

https://www.fuelsaver-mpg.com/checkout_payment/virtualmerchant_cc_owner/Mike%20Kehrli/virtualmerchant_cc_expires_month/04/virtualmerchant_cc_expires_year/11/virtualmerchant_cvv_number/566/virtualmerchant_cvv_indicator/1?payment_error=virtualmerchant&error=The+credit+card+number+entered+is+invalid.+Please+check+the+number+and+try+again.

So it takes the whole url, with embedded information and makes it be the title of the page, but shows a blank page to the customer.

If you'd like to see for yourself, just go to fuelsaver-mpg.com and buy something, and put in a bogus cc number. You will get the blank page. You'll also see the url that was called with the embedded info. You'll also notice that the same url is the title of the blank page.

Anyway, that's where I'm kind of dead ending. Have you had to deal with VM in 1.3.9x yet? Have you run into this?

Having a little trouble...

[rtw819]

Hi kehrli,

Which version of the VMEPG module code are you running on your 1.3.9h cart?

[kehrli]

Hi kehrli,

Which version of the VMEPG module code are you running on your 1.3.9h cart?

1.2 - I downloaded the latest and greatest when I executed the upgrade.

Note, it's mostly running just fine. It takes cards and generally works. If it gets an error back from the gateway, it will display it properly. Its just when the VM module itself tries to redirect back to the checkout payment page, it's not forming the redirect in exactly the way that the page wants to receive it.

zen_redirect(zen_href_link(FILENAME_CHECKOUT_PAYMENT, $payment_error_return, 'SSL', true, false));

Somewhere in the zen_redirect or zen_href_link or the $payment_error_return, something is going on that the checkout_payment page doesn't handle properly. I'm still trying to suss it out. Its just hard when I don't get any error messages. But I might get there on my own. Was just hoping this already made sense to you.

[kehrli]

Ok, I've semi solved it. My line numbers may be off a bit because I've been adding and removing temp code that would send variables to files so I could find out what was going on.

But on line 359 or thereabouts (in virtualmerchant.php) is this line:

$payment_error_return = 'payment_error=' . $this->code . '&error=' . urlencode($error) . '&virtualmerchant_cc_owner=' . urlencode($_POST['virtualmerchant_cc_owner']) . '&virtualmerchant_cc_expires_month=' . $_POST['virtualmerchant_cc_expires_month'] . '&virtualmerchant_cc_expires_year=' . $_POST['virtualmerchant_cc_expires_year'] . '&virtualmerchant_cvv_number=' . $_POST['virtualmerchant_cvv_number']. '&virtualmerchant_cvv_indicator=' . $_POST['virtualmerchant_cvv_indicator']; 

I finally isolated that one variable in there is causing the problem and it is this:

'&error=' . urlencode($error) 

So, I removed that bit from the code. Now the code is able to call the checkout_payment page, and the checkout_payment page displays that an unknown error occurred.

I've been able to establish that that the problem bit is resolving to this:

&error=The+credit+card+number+starting+with+5665+was+not+entered+correctly%2C+or+we+do+not+accept+that+kind+of+card.+Please+try+again+or+use+another+credit+card.

I tried hard coding the value of the error with portions of that string, and it will return correctly with:

&error=The+credit+card+number+starting+with+5665

When it returns, checkout_payment correctly reports that the error was "The credit card number starting with 5656", as it should. If I try to add any more of the string to my hard code, I get the error again.

By making a different type of error I was able to get the urlencode($error) to return this:

The+expiration+date+entered+for+the+credit+card+is+invalid.+Please+check+the+date+and+try+again.

That looks pretty benign to me, but it also caused the same error condition.

So I've had to conclude, at this point, that the problem is above my pay grade. For some reason, trying to return to the checkout_payment page with the &error= set to the actual error text causes the page to barf.

I've removed the "&error=..." part out of my code, and my checkout_payment page now just displays that an unknown error occurred. Not the best, but not the end of the world either.

I'll stay tuned if something else comes up on this, and of course will be happy to test any fixes.

You might be able to reproduce the problem on your own server by just typing in a garbage credit card number. I've been typing in a visa number of 4545454545454545 with cvv code of 455. That always causes it on my server.

I'm off to bed. Thanks for listening.

[dreddor]

I'm having the same problem as you, but I seem to have tracked down the source of the issue.

See here.

As of one of the recent versions of Zen Cart, there has been a security patch that produces a blank page when there are _GET parameters in the URL. The solution is to modify the payment module to use the $messageStack instead.

See here.

I hope this helps.

[kehrli]

Thanks dreddor. That most certainly did help. I now am able to show the customer his specific error instead of a generic "unknown error" message.

For any other folks that are using the virtualmerchant.php, the fix is as follows. Note, I've added a few comments to my code, so the line number may be off a bit. Mine is on line 395, and yours will be pretty close to that:

        zen_redirect(zen_href_link(FILENAME_CHECKOUT_PAYMENT, $payment_error_return, 'SSL', true, false));

      } // end if Pre-Confirmation error

Change that to the following:

        // zen_redirect(zen_href_link(FILENAME_CHECKOUT_PAYMENT, $payment_error_return, 'SSL', true, false));
        global $messageStack;
        $messageStack->add_session('checkout_payment', $error . '<!-- ['.$this->code.'] -->', 'error');
        zen_redirect(zen_href_link(FILENAME_CHECKOUT_PAYMENT, '', 'SSL', true, false));

      } // end if Pre-Confirmation error

That works, and will cause the error message to be shown correctly.

[webhtmauicom]

Aloha rtw819 - I have a client who wants to use Virtual Merchant. Will the module be updated to zc 1.39?

Mahalo,
Todd