Details
-
Type: Bug
-
Status: Done/Fixed
-
Priority: Major
-
Resolution: Fixed/Completed
-
Affects Version/s: 4.3.7
-
Fix Version/s: 4.4.0
-
Component/s: CiviContribute
-
Labels:
Description
One of our customers received this notice from Elavon:
"Thank you for being a loyal Elavon customer and VirtualMerchant user. We value your business and want to take this opportunity to notify you of security enhancements that will require code changes by your system administrator or developer by October 2013. If changes are not made, VirtualMerchant will reject transactions and you will not be able to process payments.
Step 1 – Update your code to transmit the User ID that is required in addition to the Merchant ID & PIN for all integrated transactions.
Step 2 – Ensure that all integrated transactions uniquely include the following:
VirtualMerchant ID (VID) = ssl_merchant_id
VirtualMerchant User Id = ssl_user_id
VirtualMerchant PIN = ssl_pin
Step 3 – If you are sending the Merchant Administrator User ID (MA User ID) in the user ID field, it will need to be changed as VirtualMerchant will no longer accept MA User ID.
To avoid any interruptions in processing, please consult with your systems administrator to ensure that these coding changes are made in advance of the October 11, 2013 date in order to avoid any interruption."
The new part is that VirtualMerchant User Id = ssl_user_id has to be sent with each request. First I checked to see if we already do this but I have found that the existing integration doesn't send ssl_user_id to the processor. I going to be working on a patch this morning unless anyone else has already looked into this?
Also we found in the past that the Elavon processor would have issues processing so-called "commercial cards" unless two more fields were added to the request: ssl_customer_code and ssl_salestax. ssl_customer_code seems to be the pin number that lets a business track multiple people using one card? Our quick fix based on posts we found relating to other shopping carts using Elavon was to hard code two dummy values into the request.
Perhaps a better solution would be to provide a UI to let the end user enter their customer code but I don't think that many websites support this?
$requestFields['ssl_customer_code'] = '1111';
$requestFields['ssl_salestax'] = 0.0;
Any comments on this approach of hard coding these two values?