Need help with Virtual Merchant module

Todd,

Thanks for checking the AMEX problem out! Don't know a test card number for AMEX. We have been trying real cards.

-Matt

matt123:

Todd,
We have been trying real cards.

I don't own one of that particular variety of card, personally. However, i did find a test number! You can use 34 followed by all ones (that's 13 ones needed since AM EX cards are 15-digits in length). The CVV2 is 4 digits.

I was able to run a successful test transaction with the new beta VM module code I'm putting together. We'll have some additional confirmation soon. Not sure if it works on the production side, since we aren't taking them yet.

Thanks!

:clap: If you want someone else to bug test. Just let me know.

Things are looking pretty good for a 1.4 Release with some useful enhancements in the very near future.

Drop me a PM with your email address and a quick note if you are interested in Beta testing the Virtual Merchant module over the next few days. Will want to have some pretty quick turn-around of the evaluation of the new version so that I can get a release out soon. Hoping to do so within a week.

Thanks!

For those who were having problems with their shop's server reporting that they have lost contact with the MySQL database for a particular email address they indicated as the shop's email, the solution is to do the following:

Go to the Admin panel and under the Configurations --> Email Options, make sure you fill in all the fields related to your SMTP server and your email password, even if you think you do not need it. Specifically GoDaddy requires this authentication when an email is sent through the proxy, or when it is under SSL. Once every field related to the SMTP is filled in properly, you will then not be disconnected from the MySQL server.

Those persons who stated that this error was due to the hosting provider being useless (and stating that they were quite expert as well) should refrain from stating such things and rather attempt to find a solution for the benefit of all of us.

If you are then having cURL problems, look in this forum to find out how to properly configure your proxy server, and make sure you indicate this in Configuration --> My Store and in the payment module proxy server field.

robc:

For those who were having problems with their shop's server reporting that they have lost contact with the MySQL database for a particular email address they indicated as the shop's email, the solution is to do the following:

Go to the Admin panel and under the Configurations --> Email Options, make sure you fill in all the fields related to your SMTP server and your email password, even if you think you do not need it. Specifically GoDaddy requires this authentication when an email is sent through the proxy, or when it is under SSL. Once every field related to the SMTP is filled in properly, you will then not be disconnected from the MySQL server.

Robc -- good find! Thanks for sharing. I've added your solution to the VM module FAQ.

ARG - so this module will not work in CAD dollars? I have a client desperate to make this work and her primary currency is CAD.

Please advise so that I can update her?

Thank you.
Jennie

mommydesigns:

ARG - so this module will not work in CAD dollars? I have a client desperate to make this work and her primary currency is CAD.

Please advise so that I can update her?

Thank you.
Jennie

Hi Jennie,

We've been working on it! :) I've got a couple of folks beta testing right now. If you're interested in beta testing the VM Module with Canadian support, PM me and drop me a note.

Having some problems with the VM test account this evening, so it's being a little difficult at the moment.

We should have something production worthy soon. Still need testers.

Thanks!

Todd

Hello Canadian Virtual Merchant Users -

Attached is an INTERIM FIX for the Canadian ONLY VM Users.

This is a tested drop-in replacement for Version 1.2 of my VM Payment Gateway module.

Save a copy of the current /catalog/includes/modules/payment/virtualmerchant.php file, and replace it with the one attached to this message. (You'll need to rename the file included to the original name.)

Words of warning: You MUST have CAD installed on your cart as the default currency, else people will check out for FREE if the cart is set to use USD (or split currency) with this CAD-only VM module code. Your Elavon Virtual Merchant account must also only be setup for CAD to use this interim version of the code.

Let me know if there are any questions.

In the mean time, we are still working the last few bugs and finalizing testing of the 1.4 release of the module with lots of useful fixes.

Hope it helps,

Todd

Er.... getting errors with that CAD module now. :(

Virtual Merchant - Credit Card Processing Error: RC=(1)
Customer Error Message: 

payment_error=virtualmerchant&errormessage=INVLD+TERM+ID+1&virtualmerchant_cc_owner=Jennie+Maynard&virtualmerchant_cc_expires_month=01&virtualmerchant_cc_expires_year=09&virtualmerchant_cvv_indicator=1

Check today's logs for more details.  This transaction was either declined
or had an error preventing it from being processed.

Jennie

Hi Jennie,

Per the Virtual Merchant documentation this tends to indicate:

INVLD TERM ID 1 ==> Invalid Merchant Number

Were you able to validate the account info (Merchant Number/User ID/User PIN) with VM/Elavon Support?

Hope this helps,

Todd

I have a question. I've copied all 3 files to their respective directories and installed the module in the zen cart admin. I configured the data etc. When I tested it, it doesn't show up as a payment method in the check out page. Can you guys give me an idea of why it's not showing up? If my cURL is not set up properly, will this prevent the payment method to show up in the shopping cart? Payment zone is set to none, so it's not blocking me from choosing that option. Maybe I forgot a step? Anyone encountered this before?

Any help will be appreciated! Thanks!

Hi Jaypee,

Here are a few things to check...

Which module are you using? VM / Klix? and which version? which Zen version?

Do you have multiple Payment modules? What does your sort order look like? I've seen problems if multiple modules have the same sort order value.

Do you have a credit card type(s) enabled?

    <https://www.zen-cart.com/tutorials/index.php?article=152>

Set up your cart to accept cards--

• Enable the cards you with to accept in Zen Cart under the Admin Control
  Panel: Admin->Configuration->Credit Cards

Check on those, and let us know?

You are correct -- improperly setup cURL would not / should not keep the module from showing up as a payment option... Not quite sure what else might be going on.

Thanks, I got it to show up. You were right about the credit card types, forgot to enable those. And the reason why my VM module was not showing up was because the enabled modules were defined in a variable/hard coded in the script. not sure if that is how it should be, but I added the virtualmerchant.php module in there and it showed up.

It looks like it's working properly but now the client wants the DCC option enabled. He wants the clients charged in Euros and I think wants it displayed in Euros in his myvirtualmerchant account as well. Is that possible? I contacted their techsupport and they said it's possible to force a transaction to go through the DCC by adding dccoption in your form fields and assigning the value = 'Y'.

And how do we match the credit card payments (in myvirtualmerchant.com) to the order details in Zen Cart? How do we know which payment goes to which order?

jaypee:

Thanks, I got it to show up. You were right about the credit card types, forgot to enable those. And the reason why my VM module was not showing up was because the enabled modules were defined in a variable/hard coded in the script. not sure if that is how it should be, but I added the virtualmerchant.php module in there and it showed up.

It looks like it's working properly but now the client wants the DCC option enabled. He wants the clients charged in Euros and I think wants it displayed in Euros in his myvirtualmerchant account as well. Is that possible? I contacted their techsupport and they said it's possible to force a transaction to go through the DCC by adding dccoption in your form fields and assigning the value = 'Y'.

And how do we match the credit card payments (in myvirtualmerchant.com) to the order details in Zen Cart? How do we know which payment goes to which order?

Adding these fields would be easy enough . . . we'd have to do some testing on the module. I don't think sending a value of Y is wise . . . what happens when it's CAD, EUR, their DCC only works with certain currency types . . . what if someone has a USD card? A person could live in Europe and have a USD issued card. I've seen more than one person living in Canada that have a US card. Not letting the card holder make that call sounds precarious.

This will take some time . . . I'm not sure that Zen will allow a 'pop-up' in the midst of the transaction.

jaypee:

Thanks, I got it to show up. You were right about the credit card types, forgot to enable those. And the reason why my VM module was not showing up was because the enabled modules were defined in a variable/hard coded in the script. not sure if that is how it should be, but I added the virtualmerchant.php module in there and it showed up.

Hi Jaypee, which file did you have to edit for the "enabled modules"? This is not a normal situation, and I'm curious what had to be changed to make it work? Normally, a standard Zen Cart installation will see the module and allow you to use it, so this to me seems like a peculiar situation. Please elaborate?

jaypee:

It looks like it's working properly but now the client wants the DCC option enabled. He wants the clients charged in Euros and I think wants it displayed in Euros in his myvirtualmerchant account as well. Is that possible? I contacted their techsupport and they said it's possible to force a transaction to go through the DCC by adding dccoption in your form fields and assigning the value = 'Y'.

Sorry, the DCC option is not currently supported with the Virtual Merchant enhanced payment gateway module. There is not an easy way to extend the Zen/VM Payment Module interface to use the Elavon Virtual Merchant DCC service. Never is a strong word, but it is very unlikely that direct DCC integration will be achievable. However, that does not mean there won't be another work around. I've only just recently begun working on extending the VMEPG (Virtual Merchant Enhanced Payment Gateway) module for US/Canadian currency support.

I was not aware Elavon was accepting payments in Euros? Does your client have an Elavon VM account that is Euro-based? Until now I had heard US Dollars and Canadian Dollars were the only account currencies available. If this is the case, and Euro-based (end currency) accounts are available, I will need to re-work some things in the module to support the Euros. Unfortunately, Elavon sales/support wasn't available to answer my questions when I called tonight.

IF the client has a cart that ONLY supports Euros (all products are priced in Euros), and wants to charge the customer's cards in Euros, that should not be a problem -- that is an easy solution. On the other side, for multiple currency situations, any currency conversion can potentially be done through the Zen cart at checkout as it is submitted to for authorization/capture. (Example: Person loads up a cart in USDollars priced merchandise, checks out and based on the Zen cart's currency conversion rates, the card will be charged in the appropriate Euro funds -- since the merchant account is Euro-only. The same would apply if the merchant account was US$-based, and the Zen products were all priced in Euros - the conversion at checkout would convert to USD for the VM funds capture.) Sorry if this was confusing. Wasn't meant to be, but it can be.

Multi-currency support for the module is still in beta testing at this point as version 1.4 (pending release). It is supporting USD and CAD, and only one or the other as far as the end-game currency (VM account). As it is today, from what I understand, a merchant must have multiple accounts set up (multiple web-id and/or pin's) for capturing in multiple currencies. Support for multiple VM ID/Pins will not be included in the 1.4 release, which I had already hoped to have made available by now. Still getting final feedback and hoping to wrap up the last of the beta testing soon.

Any additional information and/or specifics on your client's situation would be extremely helpful. You can feel free to PM or e-mail me if you would rather.

jaypee:

And how do we match the credit card payments (in myvirtualmerchant.com) to the order details in Zen Cart? How do we know which payment goes to which order?

The order number and order details should be shown in the VM online information for transactions. In new version 1.4, the database will also be updated with the approval code and transaction ID to assist in tracking payments.

Hope this helps some,

Todd

Just a word on how DCC works . . . this is what's on their site:

Dynamic Currency Conversion (DCC)

 DCC converts international Visa and MasterCard credit card purchases into the cardholder’s home currency at the point of sale. Elavon rebates a portion of the conversion fee to your business and manages the entire conversion process—from direct treasury exchange rates and transaction processing, to back-end reconciliation, settlement, funding, and support.

and a pdf

Now, here's the practical look . . .

An account with Elavon is setup (Elavon is the company that develops Virtual Merchant) and the merchant will be funded in USD.

So let's look at the old way of things, well . . . really it's the way it things go now for most of the world. A US based merchant sells a widget for 1.00; an individual living in Germany purchases the widget for 1.00 USD. When the transaction hits the VM gateway the Bin range on the card (the first six digits) identifies the card issuing bank. If that bank is found to be a Euro bank the customer will be prompted to process via DCC or not.

If they say Yes, then the current exchange rate is displayed and the customer is made aware that their account will be hit for say .50 (depending on the exchange rate) as opposed to the 1.00. This way the customer knows what they are being charged exactly. The merchant is still funded 1.00 USD and the card holder is charged .50 EUR (FYI, supported currencies are CAD, YEN, AUD, EUR, and GBP)

If they answer No, then the merchant is funded 1.00 USD (just like before) and they are charged 1.00 USD; BUT because their account is built on EUR the conversion will still take place but at a later time (after the merchant closes the batch) and the entire conversion process will occur on the back end of the card holders bank.

You guys think I've been down this road before? :D

ThePatch:

Just a word on how DCC works . . . this is what's on their site:

Dynamic Currency Conversion (DCC)

 DCC converts international Visa and MasterCard credit card purchases into the cardholder’s home currency at the point of sale.

Hi Samuel, thanks for the link and the info/refresher on DCC. I had done the research and examined the options a couple of weeks ago with regards to DCC and while looking at our multi-currency support options going forward into the new VM enhanced payment gateway module version.

It seems like (from my research) that the Elavon/VM implementation (DCC prompting mechanism) will be a major hassle to tie into Zen's payment infrastructure -- a fight I'm not willing to take on at this point, so I've side stepped the DCC issue/option and I'm looking for other alternative solutions, of which I believe I have found something workable and we are testing now with USD/CAD from a Zen conversion perspective, sidestepping the need for/use of DCC in this case.

ThePatch:

(FYI, supported currencies are CAD, YEN, AUD, EUR, and GBP)

Do you know if these are what DCC supports, or if they are the choices/options for the native Elavon / VM Merchant Services Accounts being provided (as the merchant's currency or currencies of choice)? That is the big question. I've been searching all over the Elavon/VM web pages and support for more detailed on account setup with regards to multiple currency support and all I found was the same DCC document link you posted and what's in the Developer's guide. Is there more I've missed elsewhere?

ThePatch:

You guys think I've been down this road before? :D

I don't doubt it. Your insight is (as always) truly appreciated.

The currencies listed are the ones that work with DCC

When it comes to the work you're doing with CAD . . . are you referring to merchants set up to be funded in CAD?

rtw819:

Hi Jaypee, which file did you have to edit for the "enabled modules"? This is not a normal situation, and I'm curious what had to be changed to make it work? Normally, a standard Zen Cart installation will see the module and allow you to use it, so this to me seems like a peculiar situation. Please elaborate?

I edited the file /includes/classes/payment.php

In the function payment, it has a line there

define('MODULE_PAYMENT_INSTALLED', 'module1.php;module2.php;etc...');

and I just added ;virtualmerchant.php and it appeared. I don't think this is how it's supposed to work though, but I didn't install that site so I'm just working on someone else's code I guess?

I found a work-around for the DCC. I updated the form that displays the cc number, cvs, etc, and added a field like

"Charge in US Dollars? <yes><no>"

From how I understand the DCC, if VM detects your card has another currency, it will ask you if you will be charged in your home currency (dccoption=Y) or in US Dollars (dccoption=N).

So the new field I added has a 'reverse' value.

"Charge in US Dollars?" <yes> (dccoption=N), <no> (dccoption=Y)

I also updated the function that saves the posted values to sessions, and made sure the dccoption is saved in the session as well.

Now, onto submitting it through curl. If a card can be charged in a different currency, VM will return a different set of response (different from normal that is), but what you just need is the 'id' field, because this is an ID of your current session. So I added something there to see if the response from VM has the field 'id' or not. Sort of like "if (strlen($response['id']) > 0)". If it does, I send it back using a new curl post string and I include the customer's dccoption as well. (this is the "pop-up phase" of the transaction). I basically copy and pasted your code for sending curl using PHPcurl or non-php curl lol. After this, its response is its usual response after processing a card.

If it does not have the 'id' response, then I skip that whole step and assume the transaction is completed.

It's far from being elegant but hey, it worked. ;D

PS: I also edited a few lines about sending email messages to admin. Everytime I saw this:

if ($this->admin_mail) zen_mail(STORE_NAME, STORE_OWNER_EMAIL_ADDRESS, MODULE_PAYMENT_VIRTUALMERCHANT_TEXT_CC_PROCERR, $email_message, STORE_OWNER, STORE_OWNER_EMAIL_ADDRESS);

I changed it to

if ($this->admin_mail) zen_mail(STORE_NAME, STORE_OWNER_EMAIL_ADDRESS, MODULE_PAYMENT_VIRTUALMERCHANT_TEXT_CC_PROCERR, $email_message, STORE_OWNER, STORE_OWNER_EMAIL_ADDRESS, array('EMAIL_MESSAGE_HTML' => nl2br($email_message)));

The last part is for email messages that are HTML-based.