Need help with Virtual Merchant module

[i8beef]

Fair enough. I've modified my code to this. I have a problem though.

After posting the data to Virtual Merchant, I'm just ending up looking at a very blank page at https://demo.myvirtualmerchant.com/V...emo/process.do. Meaning it's not redirecting back to me on the approval, or on decline, or having it send in test mode is throwing a wrench in the gears, or sending to the demo server acts in some wierd way I'm not familiar with or something.

Here's my process button code. Should all be correct now...

$process_button_string = zen_draw_hidden_field('ssl_merchant_id', MODULE_PAYMENT_VIRTUALMERCHANT_MERCHANT_ID) .
zen_draw_hidden_field('ssl_user_id', MODULE_PAYMENT_VIRTUALMERCHANT_USER_ID) .
zen_draw_hidden_field('ssl_pin', MODULE_PAYMENT_VIRTUALMERCHANT_PIN) .
zen_draw_hidden_field('ssl_transaction_type', 'CCSALE') .
zen_draw_hidden_field('ssl_show_form', 'FALSE') .

zen_draw_hidden_field('ssl_card_number', $this->cc_card_number) .
zen_draw_hidden_field('ssl_exp_date', $this->cc_expiry_month . substr($this->cc_expiry_year, -2)) .
zen_draw_hidden_field('ssl_cvv2cvc2_indicator', '1') .
zen_draw_hidden_field('ssl_cvv2cvc2', $_POST['virtualmerchant_cc_cvv']) .

zen_draw_hidden_field('ssl_result_format', 'HTML') .
zen_draw_hidden_field('main_page', 'checkout_process') .
zen_draw_hidden_field('ssl_receipt_apprvl_method', 'REDG') .
zen_draw_hidden_field('ssl_receipt_decl_method', 'REDG') .
zen_draw_hidden_field('ssl_receipt_apprvl_get_url', zen_href_link(FILENAME_DEFAULT, '', 'SSL', FALSE)) .
zen_draw_hidden_field('ssl_receipt_decl_get_url', zen_href_link(FILENAME_CHECKOUT_PAYMENT, 'payment_error=' . $this->code . '&virtualmerchant_cc_owner=' . urlencode($_POST['virtualmerchant_cc_owner']) . '&passedvars=coming' , 'SSL', FALSE)) .

//zen_draw_hidden_field('ssl_receipt_link_method', 'REDG') .
//zen_draw_hidden_field('ssl_receipt_link_url', zen_href_link(FILENAME_CHECKOUT_PROCESS, '', 'SSL', false)) .

zen_draw_hidden_field('ssl_amount', number_format($order->info['total'] * $currencies->get_value('USD'), 2, '','')) .
zen_draw_hidden_field('ssl_salestax', number_format($order->info['tax'] * $currencies->get_value('USD'), 2, '','')) .

zen_draw_hidden_field('ssl_customer_code', $_SESSION['customer_id']) .
zen_draw_hidden_field('ssl_do_customer_email', ((MODULE_PAYMENT_VIRTUALMERCHANT_EMAIL_CUSTOMER == 'True') ? 'TRUE': 'FALSE')) .
zen_draw_hidden_field('ssl_first_name', $order->billing['firstname']) .
zen_draw_hidden_field('ssl_last_name', $order->billing['lastname']) .
zen_draw_hidden_field('ssl_avs_address', $order->billing['street_address']) .
zen_draw_hidden_field('ssl_city', $order->billing['city']) .
zen_draw_hidden_field('ssl_state', $order->billing['state']) .
zen_draw_hidden_field('ssl_avs_zip', $order->billing['postcode']) .
zen_draw_hidden_field('ssl_country', $order->billing['country']['title']) .
zen_draw_hidden_field('ssl_phone', $order->customer['telephone']) .
zen_draw_hidden_field('ssl_email', $order->customer['email_address']) .
zen_draw_hidden_field('ssl_ship_to_first_name', $order->delivery['firstname']) .
zen_draw_hidden_field('ssl_ship_to_last_name', $order->delivery['lastname']) .
zen_draw_hidden_field('ssl_ship_to_address1', $order->delivery['street_address']) .
zen_draw_hidden_field('ssl_ship_to_city', $order->delivery['city']) .
zen_draw_hidden_field('ssl_ship_to_state', $order->delivery['state']) .
zen_draw_hidden_field('ssl_ship_to_zip', $order->delivery['postcode']) .
zen_draw_hidden_field('ssl_ship_to_country', $order->delivery['country']['title']) .
zen_draw_hidden_field('x_Customer_IP', $_SERVER['REMOTE_ADDR']);
if (MODULE_PAYMENT_VIRTUALMERCHANT_TESTMODE == 'True') $process_button_string .= zen_draw_hidden_field('ssl_test_mode', 'TRUE');

Any ideas on this one? :-)

Michael

[rtw819]

They say it has been tested with Zen 1.3.7 and found to work. I tried installing it but had a few warning messages in my admin payment modules section. It said "failed to open stream: no such file or directory in admin/modules.php on line 174.

Did you also upload the language file (and all the other associated files from the ZIP)? :)

Specifically - /catalog/includes/languages/english/modules/payment/viaklix.php

All files need to be uploaded for the module to function. The error indication you mentioned seems to think the language file is missing. I assume your Zen language is set to 'engligh', yes?

That new ViaKlix2 Enhanced Payment Module that Dr. Byte referred to looks to be pretty extensive. It looks like it can do a lot more things than the old ViaKlix mods. Is there any way that this one can be modified to connect to Virtual Merchant? Or, could some of the code be used to fix the problems with the VM mod?

Based on the fact that I just learned NOVA has the Virtual Merchant product and that it will be replacing viaKLIX (anybody know dates or more specifics on this?), it looks like it should be a fairly easy conversion from Klix to VM. I tried logging in with our Klix credentials, and of course they didn't work, so we don't have a valid method to test the VM stuff yet.

Otherwise, I'll happily work on setting up the module to see if we can get it to work with VM as well.

[toboldlygo]

Hi rtw819,
Yes, I did upload all the files in the download. Maybe I did something wrong. I will have to try deleting it then uploading again. I just wanted to see what it looked like and how it worked.

I changed the URL to direct to the demo Virtual Merchant site that Patch set up. I also used the demo account info he gave. I was able to connect and the sale did go through without errors. I did get the payment success page after the transaction. So that is encouraging. I don't know enough about it to fully test it with VM, but it looks promising.

Any help you could give would be greatly appreciated rtw. If your mod can be changed to work with VM, that would great.

[noisebug]

I found an error in the code ThePatch gave me.

SSL_RESULT is actually being returned as NULL. This is why none of the error handling is working, and the transaction is a success every time.

The way ThePatch told me, the demo account is setup to decline referrals, so anyone using the demo page should be getting declined. However, if the transaction is going through, this probably means that the SSL_RESULT bug is also happening in the Advanced VIAKLIX mod.

I'm not sure if this is a Virtual Merchant issue or a code issue, will look deeper into it later today when I get back from work.

[rtw819]

Hey ThePatch,

I'm working on porting my existing ViaKLIX module for Virtual Merchant, and I'm in the testing phase.

I am trying to use your demo account info, and coming up with an invalid HTTP referrer error message. Did they have you set up a referrer in your configs for the demo account? I might be missing something else, but it looks like I'm getting closer.

errorCode=4003
errorName=HTTP Referrer Invalid
errorMessage=HTTP POST transactions are not allowed for this HTTP Referrer.

Thanks!

[rtw819]

Well, it appears to be the default behavior of the demo site, blocking based on referrer, and after re-reading noisebug's post, that is apparently what should be expected. I guess that's a good thing -- means something is working!

So, I switched to the production URL (still in TEST mode) and it complains about an invalid PIN number with the test account stuff. Soo, I do believe I might have a somewhat functional VM module at this point, based on those initial but promising results?

Is there anyone following this thread that has an active Virtual Merchant account currently that would be able/willing to test this first round of beta VM code? (and hopefully willing to send me the debug logs/email to review and check the output?)

I need to get some validation with some positive test results, some actual successful transactions, so that we can confirm things are working and will work as expected.

Thanks!

[ehdesign]

RTW -
I had both those errors appear when I created a simple e-commerce for a client. I called Merchant Services and they did something that made both the errors go away.

As I was only a "hired gun" for them, I couldn't log into the actual VM account. But, those errors are a good sign.

I do have a working account and might be able to test for you. I'll have to contact my client since it really isn't mine.

I will reply further on Monday.

[ThePatch]

Hey ThePatch,

I'm working on porting my existing ViaKLIX module for Virtual Merchant, and I'm in the testing phase.

I am trying to use your demo account info, and coming up with an invalid HTTP referrer error message. Did they have you set up a referrer in your configs for the demo account? I might be missing something else, but it looks like I'm getting closer.

errorCode=4003
errorName=HTTP Referrer Invalid
errorMessage=HTTP POST transactions are not allowed for this HTTP Referrer.

Thanks!

I'm sorry I've been so out of touch.

You've actually hit the nail on the head. No, it is not required to use Auth referrers but it was the only logic error I knew I could control. The problem is this:

Making a module to handle ssl_result messages was easy enough. The problem is with VM you may get NO ssl_result at all and instead get errorCode just like you did. The reason for this is a 'logic' error as opposed to a response error. In previous posts I've stated an example of say the last name of your client is 17 characters long; well VM only allows 15 (and it can't be changed) so this would not generate an ssl_result message but an errorCode.

If someone can figure out how to make it behave to where it shows a success ONLY if it gets an SSL_result=0 and all other responses kick back to the decline page then we're set. I had the ssl_result worked out, just couldn't figure out the errorCode peice. I'm going to be available all day today as I'm not going into the "office" today so I hope to help as much as possible. RTW819 if you could send me your modded code I can check it against some things I've changed to see if we don't have something working between the two of us.

[ThePatch]

Well, it appears to be the default behavior of the demo site, blocking based on referrer, and after re-reading noisebug's post, that is apparently what should be expected. I guess that's a good thing -- means something is working!

So, I switched to the production URL (still in TEST mode) and it complains about an invalid PIN number with the test account stuff. Soo, I do believe I might have a somewhat functional VM module at this point, based on those initial but promising results?

Is there anyone following this thread that has an active Virtual Merchant account currently that would be able/willing to test this first round of beta VM code? (and hopefully willing to send me the debug logs/email to review and check the output?)

I need to get some validation with some positive test results, some actual successful transactions, so that we can confirm things are working and will work as expected.

Thanks!

I can do this for you, just sent you a PM

[noisebug]

I'm sorry I've been so out of touch.

You've actually hit the nail on the head. No, it is not required to use Auth referrers but it was the only logic error I knew I could control. The problem is this:

Making a module to handle ssl_result messages was easy enough. The problem is with VM you may get NO ssl_result at all and instead get errorCode just like you did. The reason for this is a 'logic' error as opposed to a response error. In previous posts I've stated an example of say the last name of your client is 17 characters long; well VM only allows 15 (and it can't be changed) so this would not generate an ssl_result message but an errorCode.

If someone can figure out how to make it behave to where it shows a success ONLY if it gets an SSL_result=0 and all other responses kick back to the decline page then we're set. I had the ssl_result worked out, just couldn't figure out the errorCode peice. I'm going to be available all day today as I'm not going into the "office" today so I hope to help as much as possible. RTW819 if you could send me your modded code I can check it against some things I've changed to see if we don't have something working between the two of us.

Seems simple enough.

if ( SSL_RESULT != 0)
{
 //Send back to checkout page.
}

return 0; //Success

If you do it that way, it will trap all errors, including SSL_RESULT being null. This fix seems way too easy though, am I missing something?