Need help with Virtual Merchant module

The code is now sent, my apologies for the delay.

I didn't see all the other responses . . . it's good to see this project gaining attention. First, let me point out what I know so far.

VM and ViaKLIX are very similar but they are not the same. There are a few minor code changes as far as where the data should be posted to. One of the biggest differences between the two is that VM now has logic error handling. For example:

With ViaKlix if you make an error and key in the wrong Pin during the setup phase and you were to run a transaction the process would die at viaKLIX with no redirection possible

With VM if you make the same mistake you can have the error code redirected back to whatever URL you are so inclined to use.

 The problem is this though.  With the logic error handling of VM it doesn't return an ssl_result message, instead it returns an errorcode= message.  My goal was to have ZenCart look for ssl_result=0 (which means approved transaction) and if it got said message it would continue on.  If it did not then it would kick back to the previous page and state there was a problem with the transaction.  I thought this would be an easy 'if\then' statement but apparently I was wrong.

As far as being able to run transactions, I have a demo account setup:

Account ID: 000007
User ID: website
Pin: 937215

As this is a demo you'll have to post your transactions to:

https://demo.myvirtualmerchant.com/VirtualMerchantDemo/process.do

In the version I'm working on the option in the set up of being set to 'demo' or 'production' . . . Demo or Test mode would send you to the above URL while production would send you to the live location of:

https://www.myvirtualmerchant.com/VirtualMerchant/process.do

If we can get a working VM module then I can mod it backwards to a working ViaKLIX module. Yes they are going to eventually move everyone over to VM (1-2 years down the road) but I figure best to have it and not need it than vice versa.

If anyone has code that they think will work I've got a site I can test their code on. Just let me know.

toboldlygo:

Hi noisebug,
Did you use the ViaKlix mod that I posted in this thread to make your changes? I noticed that you changed the URL to go to VM instead of ViaKlix. Is that the only change you did?

Yes, I was using the MOD you posted. There we're other minor changes. Some of the variables had to be changed, but really that was it. Since I was starting from scratch I wanted to see what happens.

Thank you for the information ThePatch, as well as the code you had sent. I will look at this and get back to you all asap.

Patch, how do you test for an invalid credit card? The demo bypasses the CC check, and works for me every time when I use "41111..." for CC info.

I have a few ideas for the error checking but I can't test them.

Hi guys. I'm writing my own module for this, and just came across this thread. After reading through the other module posted a few messages above, I'm confused about a few things.

I don't want to post the whole module's code, but I have a few questions about why some of the things are done the way they are in the other module.

1. What is the correct way to do the CVV checking? I've heard ssl_cvvcvc2 and ssl_cvvcvc2_indicator, and ssl_cvv2. The developers guide says to use 'ssl_cvv2' as the indicator (ie present), and ssl_cvv2cvc2 as the number. The other module uses 'ssl_cvv2' as the indicator and 'ssl_cvv2cvc2_indicator' as the number? Something change? Also, shouldn't this ALWAYS be 'present' by design (unless your not collecting them)?

2. ssl_result_format is HTML by default. Is this just being extra careful in passing it?

3. What is the hidden field 'main_page' for? Couldn't you just change the redirect to 'FILENAME_CHECKOUT_PROCESS' instead of 'FILENAME_DEFAULT'? In the below example I have the modified code I am using after looking over the other module, and my own original code commented out below it. Can someone explain the reasoning for using the separate apprvl and decl addresses? This is probably just my ignorance on how Zen Cart handles them, but please enlighten...

    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 . '&viaklix_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)) .
   

4. I BELIEVE the before_process method is executed when VirtualMerchant returns something back to Zen Cart, correct? So is this module not doing any error checking? Or is THAT why there is a different decl_get_url? Doesn't virtual merchant do some funky error checking where it can return an 'ssl_result' of 0, but still fail a CVV or AVS check or something like that? I thought I read something about that in the developers guide... Ah yes, a failed AVS check will NOT result in a declined transaction... Not sure if this is something we might add in there to check for?

5. Shouldn't ssl_transaction_type be 'CCSALE', not 'SALE'?

I'd like to test my current module with the demo account posted above. Would that be ok? I'd be happy to provide my code, I'm jsut not sure how the best way to do that would be here as I'm new...

Michael

Your answers:
1.) what you should pass is:
ssl_cvv2cvc2_indicator with a value of '1'
ssl_cvv2cvc2 with a value of (cvv2 data)
You should always pass this, period.

2.) I'm thinking this should be AsCii, not sure though

3.) The idea behind this would be that your approvals would be sent to one page while declines to another. I don't know that this really applies to ZenCart though.

4.) I don't know that I would have Zen do anything with the AVS result. What I WOULD do is set up the business rules function in VM to auto-pend the transaction to allow the client to review the transaction before shipping the product out. Just my 2 cents

5.) Yes, trantype needs to be ccsale

By all means feel free to use the demo information

So what's the verdict on ViaKlix working with Zen Cart? Does it work dependably or no? I've scanned the hundreds of postings and still not sure what the answer is. I have a customer who uses ViaKlix and is thinking of upgrading to Zen Cart however my first impression is to simply have them change to Pay Pals merchant system or Authorize.net.

Is this not necessary?

Thanks in advance!

MH

internetoutfitter:

So what's the verdict on ViaKlix working with Zen Cart? Does it work dependably or no? I've scanned the hundreds of postings and still not sure what the answer is. I have a customer who uses ViaKlix and is thinking of upgrading to Zen Carthttp://www.zen-cart.com/index.php?main_page=product_contrib_info&products_id=806

DrByte:

http://www.zen-cart.com/index.php?main_page=product_contrib_info&products_id=806

Now if you can only wave that magic wand for Virtual Merchant, everyone is happy!

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?

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.

It sure would be nice if this would work for VM.

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/VirtualMerchantDemo/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

toboldlygo:

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?

toboldlygo:

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.

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.

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.

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!

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!

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.

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!

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.

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!

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

ThePatch:

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?