Protx VSP Direct v2.0.0

We have installed the add customers from admin addon and use the COD payment module, obviously changing the text within it, as a telephone payment option. It means we can process telephone orders through the site and use telephone payment as the payment option.
It also means customers have a site login to use and a discount coupon burning a hole in their pocket which is never a bad thing!
If you then install the master password addon you will be able to access accounts for your customers by email address and have their address details to hand when they ring.

Hope it helps.

Thanks for that ceegeeaar; that would work up until the payment part.
Their are staff who place orders but don't have access to the Protx VSPAdmin to place payments.

I'm just looking into how I can change the data that is sent to Protx. from the payment module.

conor:

Erm, your accounts people should really be taking the order information from the Zen Cart orders database, rather than the payment gateway's transaction database. Protx's records are more about the card processing records, which is really just the security information and total balance. The cart details are actually a nicety which Protx provides to make the VSP admin more functional and intuitive... most other payment gateways don't provide this information at all.

Are you saying that your accounts people interact solely with your VSP admin and not your actual store?

No, once the order is received and we have established we can fulfil it, it get's entered into our main business system and from that point on that is our main record of the sale. Some orders don't make it that far, as we may not be able to fulfil them for a number of reasons, credit score, dodgy addresses etc, so we don't even use the Zen Order database really either. Our problem is that as it currently stands, the flow of information goes from Customer > Zen > Protx > Bank > Accounts > Taxman and it is a problem when as a business we reach the annual VAT threshold before 11am every day of the year so we need to be absolutely certain that there are no "holes" in the system which could draw suspicions.

conor:

The line you will want to change is line 1128 of /includes/modules/payment/protx_direct.php:

$cart_string .= ":Shipping:1:" . $shipping_formatted . ":----:" . $shipping_formatted . ":" . $shipping_formatted;

>  
> ```php
$cart_string .= ":Shipping:1:4.21:0.74:4.95:4.95"
```It should be pretty obvious what's being done above so I don't think I need to explain it, but if any of the values need changed, obviously just adjust them as required!
>  
> As I've said though, this isn't a standard or recommended way to use the system, but if it's what you want then it's what you want! :)
>  
> Please also remember that you'll have to manually apply this change each time you update the Protx Direct module (although no upgrades are planned for the near future as there are currently no known issues! :) ).
 
This will do for us, as mentioned above we need to lock down any little matters like this. Thanks. I'll try to remember this each time there is a change, but if in a year's time, I am wondering what as gone wrong with my installation, you'll know I've forgotten to reapply the changes.

smudge:

I have a Plesk based host which has proven difficult install via Pear. I have installed Crypt_Blowfish manually as per instructions and the Admin show this as OK. With the Crypt directory in place step 3 of 3 checkout_confirmation.php fail with a blank page!

Ahh !!

If you are still with your Plesk based host and are still having problems, then you should be able to get this working. I had trouble earlier in the year, but once you realise that Plesk is effectively a platform for running your own hosting business and that a lot of the settings which you have been changing are set on a per domain basis instead of where you would usually change them, it becomes clear.

You need to have a look at your conf directory under your vhost directory. vhost.conf and vhost_ssl.conf are they key to getting this working and where you will need to make your changes.

YorkshirePetShop:

Is it possible to use this module to allow customers to order as normal and have an option to use the moto account, so staff can put orders through the zen cart site as normal, but without getting the 3d secure pages?

Protex have mentioned creating a seperate button for staff to use and change the AccountType parameter from E to M. (as mentioned at the bottom of page 40 in this document: http://www.protx.com/downloads/docs/VSPDirectProtocolandIntegrationGuideline.pdf )

Not sure how that will work, as everyone could just use the staff button to bypass the 3D stuff (unless IP addresses could be used.)
Warren

Warren

We desperately want this function too. As you say, changing the Account Type parameter is probably the easy bit, making sure the public can't change it is the difficult bit.

Could the add customer in admin module be used as a base to add orders too?

We would certainly be willing to pay for this module if anyone is interested in developing it - Conor ;)

Craig

Hi Warren,

YorkshirePetShop:

Is it possible to use this module to allow customers to order as normal and have an option to use the moto account, so staff can put orders through the zen cart site as normal, but without getting the 3d secure pages?

I'm afraid that the only reliable way to have this work would for the module to be able to tell that a staff member was logged in or to require some sort of code to be entered.. If going the "entering a code" route then obviously this should be hidden from customers as much as possible so as not to confuse them.

Either solution however is a custom job so we would have to build the software and bill you directly. If you're interested in proceeding, please contact us using the contact form on the website:

http://dev.ceon.net/contact_us

YorkshirePetShop:

Their are staff who place orders but don't have access to the Protx VSPAdmin to place payments.

I'm just looking into how I can change the data that is sent to Protx. from the payment module.

Can you not just allow them limited VSPAdmin access?

Is it possible to add AccountType into this bit at the end:

$submit_data = array(
    'VPSProtocol' => '2.22',
    'TxType' => $auth_type, // Transaction Type
    'Vendor' => MODULE_PAYMENT_PROTX_DIRECT_VENDOR_NAME, // Vendor Login ID
    'VendorTxCode' => $unique_transaction_id,  // Unique Transaction ID
    'Amount' => $currency_amount,
    'Currency' => $currency_code,
    'Description' => substr(STORE_NAME . ' - Zen Cart Order @ ' . date('Y-m-d H:i:s', time()), 0, 100),
    'CardHolder' => substr($_POST['card_owner'], 0, 50),
    'CardNumber' => $_POST['card_number'],
    'ExpiryDate' => $_POST['card_expires'],
    'CV2' => (isset($_POST['card_cvv']) ? $_POST['card_cvv'] : ''),
    'CardType' => $_POST['card_type'],
    'BillingAddress' => substr($billing_address, 0, 200),
    'BillingPostCode' => substr($billing_postcode, 0, 10),
    'CustomerName' => substr($order->customer['firstname'] . ' ' . $order->customer['lastname'], 0, 100),
    'ContactNumber' => substr($order->customer['telephone'], 0, 20),
    //   'ContactFax' => '',
    'CustomerEmail' => substr($order->customer['email_address'], 0, 255),
    //   'GiftAidPayment' => '',
    'ApplyAVSCV2' => $apply_avs_cv2,
    'Apply3DSecure' => $apply_3d_secure,
    'ClientIPAddress' => $_SERVER['REMOTE_ADDR']
    );

but it only puts it in when a certain IP address is entering the order?

So;

if (getenv("REMOTE_ADDR") = 123.123.123.123) { echo 'AccountType' => 'M'; }else 'AccountType' => 'E'; }

Will that work?

Hi Warren,

Please don't post large blocks of code from the module in this forum. I know you don't mean any harm but the code is covered by a commercial license so that it can continue to be supported!

If you have any more code questions please post them to us through our website.

Will that work?

The code you posted would work with some minor adjustments (no echoing! :) ) but would obviously be completely hard coded. Do all of your staff use the same static IP address to access the internet?

If they want to connect from more than one static IP address a method of determining that a staff member is logged in would be advisable. Remember the problem here isn't getting the information to Protx, it's determining who should be able to change what information gets to Protx.

:oops: Sorry Conor :blush: Didn't think.

Hard coding wouldn't be a bad things as the internet connection has a fixed IP address and everyone connects from the same connection.

I'll give it a test and let you know how I get on.

Thanks for help.

p.s. This could be a nice additional feature to this module. From what I can gether I'm not the only one after this functionality. Like CES plus it's been mentioned elsewhere on the web.

Hi,

YorkshirePetShop:

Sorry Conor :blush: Didn't think.

No problem, just wanted to be sure you wouldn't be posting any more. ;)

YorkshirePetShop:

Hard coding wouldn't be a bad things as the internet connection has a fixed IP address and everyone connects from the same connection.

In that case send me your e-mail address (by getting in contact privately) and I'll send you the exact code you can use... you just need to send the information to Protx as part of the submit_data variable, rather than trying to "echo" it.

YorkshirePetShop:

This could be a nice additional feature to this module. From what I can gether I'm not the only one after this functionality. Like CES plus it's been mentioned elsewhere on the web.

Anytime someone suggests a feature that might be beneficial for all or many users of the module my first thought is to make it available to all as an upgrade. However, the modifications you are talking about would more than likely involve modifying core Zen Cart files (to track Staff membership), so the benefits of making it available are outweighed by the additional steps the module would require to install. (I don't know of anyone else who has all staff members using a single IP address to use the internet so a simple "Staff IP addresses" configuration option isn't an option!).

It's just too specific a feature to add using Zen Cart's current module system.

Thanks for thinking of others though! :)

Good work you two.

Warren, I look forward to hearing how you get on.

Craig

Hello,

i'm having a problem with protx on our cart and after searching google for an answer i still cannot underatnd if there is a problem with the protx module config or with protx system itself, :cry: so i' appreciate any help i could get.

This is the error that comes up, but not on all the transactions, i'd say on 1 out of 2 probably at present. It has smth do do with 3D authentications of certain cards and i hope someone will be able to shed some light on the subject. Many thanks.

Your card could not be authorised! Please correct any details below and
try again or contact us for further assistance.
(2007 : Please redirect your customer to the ACSURL, passing the MD and
PaReq.)

Hi Alex,

Are you using version 2.x of the module?

If so, you'll need to upgrade to 3.2.2 to be able to accept 3D-Secure enabled cards!

If not, please contact me privately via the contact form on the website with details about the versions of the module and Zen Cart you are using.

Hi Conor,
many thanks for your help, i'll upgrade the module tomorrow.... On another subject (which hopefully won't be relevant after upgrade), we have received the order today, which registered with zen cart, however no payment went to protx (not even failed transaction, nothing is recorded in the VPS admin) - protx support confirmed that. Protx is our only payment option.
The order looks different from other orders in the admin though, it has

Invoice No. 20
Date Purchased: Wednesday 12 September, 2007
Payment Method: Credit/Debit Card (Secured by Protx)

But no info on the credit card details at all. (which are normally displayed in a grey box just below it. I'm using zen cart 1.3.7 and free protx module (the one released just before the upgraded for new PREAUTH rules). Any thoughts how this could have happend? i've tryed to replicate it bit other orders go just fine.
Many thanks, Alex

Hi Alex,

Alex_X2007:

On another subject (which hopefully won't be relevant after upgrade), we have received the order today, which registered with zen cart, however no payment went to protx

Now that's just bizarre. I've never heard of something like that occurring with the module! I can't see how the order could be created without any of the Protx details being recorded... if the module doesn't get a response from Protx to let it know that the transaction was processed by them then it redirects back to the payment page with an error message.

The only circumstance under which the order could be created without any transaction being registered in your VSP admin is if Protx has had some sort of failure and returned a Status of "OK" even though things weren't "OK"!

I'm glad to hear it hasn't happened since but it's a worrying thing to have happened at all due to the fact that the above is the **only **thing that could have happened!

:lookaroun

Alex_X2007:

Hi Conor,
we have received the order today, which registered with zen cart, however no payment went to protx (not even failed transaction, nothing is recorded in the VPS admin) - protx support confirmed that. Protx is our only payment option.

we had a simular thing happen
we had 2 order a bit like this

except the payment method show up on 1 of them as paypal ( we dont have the paypal mod enabled) and the other order came up as nochex ( we dont even have a nochex account) only real difference is when we checked our vsp account there was a transaction for both orders but both transactions we failed

Hi,

modchipfitters.co.uk:

except the payment method show up on 1 of them as paypal ( we dont have the paypal mod enabled) and the other order came up as nochex ( we dont even have a nochex account) only real difference is when we checked our vsp account there was a transaction for both orders but both transactions we failed

That doesn't sound good but I have no idea how it could happen! It must be a problem with your actual Zen Cart site as there is absolutely no way that the Protx module can gain information about other payment methods... it is completely independent of the other payment methods which may be used on your site!

I'm afraid I don't know what to suggest! :(

Hi,

I have quite a serious issue which is costing us a lot of money. I am sorry if this has been mentioned before but I have not had a chance to go through all the forums.
I have protx installed and seems to work well. However EVERY aol customer fails. I have spoken to PROTX and they have said its not an issue their end as they would know about it. So it much be my end.
He did suggest that it could be how AOL details are being stored in our shopping cart, but ive checked them and they seem ok.

Unfortunately I don't have an AOL system to check all of this on, so am very much depending on you guys. (no pressure :smile:)

Shop: http://www.gorgeousshop.co.uk

Thanks
Nick

Hi,

nickster4321:

However EVERY aol customer fails.

When you say "every AOL customer fails" do you mean that they don't receive their order confirmation e-mail?

That's the only thing that I can imagine is happening.

If this is happening to you then your server or domain is being blocked by AOL's overzealous SPAM prevention and you will need to adjust your server's mail sending to compensate.

If you use the Apache webserver, the easiest way to do this is to add the following line to the VirtualHost configuration for your gorgeousshop.co.uk domain:

php_admin_value sendmail_path "/usr/sbin/sendmail -t -i -f [URL="mailto:[email protected]"][email protected][/URL]

Obviously the address above should exist on your server.

If you do this then AOL's servers can verify that your domain exists and that e-mail from your shop is coming from gorgeousshop.co.uk.

After restarting your server (to let Apache reload the configuration), mail from Zen Cart to AOL users will start to work once more.

If that's not the problem then I'm afraid I've no idea how to help you as the module has absolutely nothing to do with e-mail!