Jump to content
Sign in to follow this  
perfectpassion

Protx Direct v2.22

Recommended Posts

JohnR - the reason we don't support "forks" of osC is that they are highly modified version of osc and we can't test contributions on all of them - they often need to be rewritten to work with each individual cart package.

 

Blagger - I can't replicate the error you are getting but as I said earlier something must be clearing the credit card number from its variable before the protx module can process it for the confirmation page. Do you have any contributions installed that modify the checkout process at all?

 

You can try changing the line:

'field' => substr($this->cc_card_number, 0, 4) . str_repeat('X', (strlen($this->cc_card_number) - 8)) . substr($this->cc_card_number, -4)),

with:

'field' => $this->cc_card_number),

 

Then see if the card number is appearing correctly on the ocnfirmation page. Note this code change is not for production purposes as it will cause the full cc number to be displayed at confirmation/email/invoice/database etc.

 

HTH,

Tom

Share this post


Link to post
Share on other sites

My problem has been fixed, it was nothing to do with your protx contrib (or should i say Rhea's?), i have been messing about with checkout_process over the last week and completly forgot about it. I have now amended it and all is working for fine.

 

Sorry for wasting some more forum space!

 

 

JohnR - the reason we don't support "forks" of osC is that they are highly modified version of osc and we can't test contributions on all of them - they often need to be rewritten to work with each individual cart package.

 

Blagger - I can't replicate the error you are getting but as I said earlier something must be clearing the credit card number from its variable before the protx module can process it for the confirmation page. Do you have any contributions installed that modify the checkout process at all?

 

You can try changing the line:

'field' => substr($this->cc_card_number, 0, 4) . str_repeat('X', (strlen($this->cc_card_number) - 8)) . substr($this->cc_card_number, -4)),

with:

'field' => $this->cc_card_number),

 

Then see if the card number is appearing correctly on the ocnfirmation page. Note this code change is not for production purposes as it will cause the full cc number to be displayed at confirmation/email/invoice/database etc.

 

HTH,

Tom

Share this post


Link to post
Share on other sites
With the protx direct module all the processing is invisible to the user. After confirming the details the customer should be returned to an order success page or back to the checkout payment page with an error message as applicable.

 

The debug message looks fine except there's no return info from the protx server - presumably becuase the vendor account isn't up yet.

 

HTH,

Tom

 

Hi,

 

I've just moved my site & shop to a new server, and have tried some test transactions, but it no longer gets back to the checkout success page - just a blank screen... Can't understand what the problem could be as it was working fine prior to this... Can't think what might have changed.

 

Any help gratefully received, as this is going to cause big problems - the shop has been live for some time...

 

Paul.

Share this post


Link to post
Share on other sites

Did you change the ip address in your Protx account?

 

Vger

Share this post


Link to post
Share on other sites
Did you change the ip address in your Protx account?

 

Vger

 

Hi Vger,

 

I'm not sure if you're replying to me, but I'm using VSP Form and have never had to set up a list of IP addresses.

 

Paul

Share this post


Link to post
Share on other sites

This is the support thread for the AIM contribution :D

 

Vger

Share this post


Link to post
Share on other sites

Thanks to you lot i have got this working without a glitch now.

 

I just have more one request.

 

What would I have to do to get an email sent to me every time an order is made. This just saves me time refreshing the admin/orders.php to see if an order has been made.

 

I used to have the paypal ipn contrib installed and I am so used to getting the email.

 

Thanks

Share this post


Link to post
Share on other sites

The margins on some the items I am selling are very low (less than 4% in some cases) and for this reason I would like to be able to apply surcharges for certain types of card.

 

At the moment I am using Protx Form, but would like to start using Protx Direct as presumably there is scope to modify this module to allow this - ideally an extra menu from the admin screen where either flat rate or percentage surcharges could be applied for different card types.

 

Can anyone help with this?

 

Paul.

Share this post


Link to post
Share on other sites
The margins on some the items I am selling are very low (less than 4% in some cases) and for this reason I would like to be able to apply surcharges for certain types of card.

 

At the moment I am using Protx Form, but would like to start using Protx Direct as presumably there is scope to modify this module to allow this - ideally an extra menu from the admin screen where either flat rate or percentage surcharges could be applied for different card types.

 

Can anyone help with this?

 

Paul.

 

It would be even better to be able to apply credit card surcharges to certain items only, but clearly this will be quite complicated as a separate order total for items to which the surcharges apply would have to be passed to the payment module...

Share this post


Link to post
Share on other sites

I don't think that changing from protx form to direct would make it any easier (or more difficult) in doing what you suggest, but I personally think the direct method is better if you can use it as the customer never needs to leave your site and it seems more professional.

 

There is a surcharge contribution:

 

http://www.oscommerce.com/community/contributions,251/page,3

 

HTH,

Tom

Share this post


Link to post
Share on other sites
I don't think that changing from protx form to direct would make it any easier (or more difficult) in doing what you suggest, but I personally think the direct method is better if you can use it as the customer never needs to leave your site and it seems more professional.

 

There is a surcharge contribution:

 

http://www.oscommerce.com/community/contributions,251/page,3

 

HTH,

Tom

 

Thanks Tom.

 

With Protx Form the customer would have to select the type of card they are using before they are directed to Protx when they could in theory use another type of card i.e. select debit card in the online store (no charge) and pay with a credit card when they get to Protx (instead of paying the surcharge)

 

Would agree Protx Direct is a better method, and I think ultimately I will be switching to it regardless of whether I can get the surcharge system working they way I'd like it to...

 

For my store there are items where the margin is so low that the fees charged on certain credit cards (e.g. commercial credit cards) swallow up almost all the profit. I'd like to be able to set whether a credit card surcharge is applied on any given item as for the great majority of items I wouldn't have to do it...

 

All the best,

 

Paul.

Share this post


Link to post
Share on other sites
Right, its 4am and I've got it working with the CCGV (CCGV5_15_a2.zip) I've done a few different things, rearanged the order of the "order total" modules in admin, moved the order of some code in payment_proccess.php and some other stuff I've forgoten. So I cant be sure what the problem was.

 

One of those days today when nothing works at first! lol Goodnight and great new Protx module.

 

Any chance of letting us know what you did to fix this, please?

 

Thanks,

 

Tim

Share this post


Link to post
Share on other sites

With Protx you pay a set monthly fee up to a certain limit of transactions in that month. Provided you are within that limit it doesn't matter whether the transactions are for low or high margin items.

 

Vger

Thanks Tom.

 

With Protx Form the customer would have to select the type of card they are using before they are directed to Protx when they could in theory use another type of card i.e. select debit card in the online store (no charge) and pay with a credit card when they get to Protx (instead of paying the surcharge)

 

Would agree Protx Direct is a better method, and I think ultimately I will be switching to it regardless of whether I can get the surcharge system working they way I'd like it to...

 

For my store there are items where the margin is so low that the fees charged on certain credit cards (e.g. commercial credit cards) swallow up almost all the profit. I'd like to be able to set whether a credit card surcharge is applied on any given item as for the great majority of items I wouldn't have to do it...

 

All the best,

 

Paul.

Share this post


Link to post
Share on other sites
With Protx you pay a set monthly fee up to a certain limit of transactions in that month. Provided you are within that limit it doesn't matter whether the transactions are for low or high margin items.

 

Vger

 

 

That is true but that only covers the cost of the payment gateway - you then have your merchant fees for each transaction on top of that so the margin does matter.

 

Tom

Share this post


Link to post
Share on other sites
Right, its 4am and I've got it working with the CCGV (CCGV5_15_a2.zip) I've done a few different things, rearanged the order of the "order total" modules in admin, moved the order of some code in payment_proccess.php and some other stuff I've forgoten. So I cant be sure what the problem was.

 

One of those days today when nothing works at first! lol Goodnight and great new Protx module.

 

To get CCGV working with Protx, I moved $order_total_modules->update_credit_account($i) before $payment_modules->before_process() in checkout_process.php, as follows:

 

$order_total_modules->update_credit_account($i);//ICW ADDED FOR CREDIT CLASS SYSTEM

if(MODULE_PAYMENT_PROTX_DIRECT_STATUS) {

$payment_modules->before_process();

}

 

This appears to have fixed the problem.

 

Tim

http://www.solent-consultancy.com

Share this post


Link to post
Share on other sites
To get CCGV working with Protx, I moved $order_total_modules->update_credit_account($i) before $payment_modules->before_process() in checkout_process.php, as follows:

 

Yes, that works also with Authorize Net AIM, however it causes problems if you use any other payment method on your site - basically the checkout_payment.php page throws an error and nothing works.

 

Vger

Share this post


Link to post
Share on other sites

Hi Tom,

We've had various fraud issues lately with a git in Venezuela. Anyway, I emailed ProTX support about it, asking why when 3rd man had listed the transactions as High Risk, they still let them continue.

 

The reply I got was this...

 

We do offer you the means of stopping these transactions but our system will not trap them if you implement fraud prevention rules on your account. I have attached two documents which I recommend that you read through. The banks will not check the customer name supplied in the transaction but Third Man will provide a risk level based on the information supplied by the customer. If a transaction is found to be fraudulent then the vendor is liable which is why you need to take advantage of these tools.

 

Can you fathom out what they are on about?! esp in the first part?! IE what "tools" are they on about!? and how can I use them with ProTX Direct module?

 

Stew

Share this post


Link to post
Share on other sites

What they appear to be saying is this - if you have rules set up in your Protx account which override Third Man then Third Man will not stop the transaction going through e.g. If you have CVV set up to accept a transaction where the name does not match the address and/or zip code then don't expect Third Man to stop the transaction.

 

Vger

Share this post


Link to post
Share on other sites

That's right - the 3rd man only provides information to the vendor (only accessible through the admin area) - it is not applied to permit or deny any transaction.

 

The AVS/CVV rules that you can set up with Protx are the "tools" to help provide fraud - they check that the person knows the 3 digits security code on the signature strip and that the billing address provided matches the card holders address (numerics only i.e. house number and postcode) - I highly recommend setting these up (one caveat is that the AVS rules can cause most international transactions to be automatically refused).

 

Personally I would suggest in future using PRotx in Deferred / Pre-Auth mode. That way Protx will check the card for authorization from the bank and apply the 3rd man. You can then look at the results in protx admin area before releasing payment & shipping the order after making a judgment as to if it could be fraudulant.

 

Tom.

Share this post


Link to post
Share on other sites

Pre-Auth mode is the only mode available with some payment systems - with good reason.

 

Vger

Share this post


Link to post
Share on other sites

If a transaction is processed as PRE-AUTH then all that happens is an authorisation for the specified amount is obtained (i.e. the details are checked that they are valid and that the CC company will authorise the transaction) and the details stored for later. You then later have to do a REPEAT transaction (via Protx admin) to actually get the payment, specifying the amount you wish to take. PRE_AUTH is the type of transaction the is done by hotels when checking in - they swipe the card to check it is valid but as they don't know what the final bill is they do the transaction again when you checkout.

 

A DEFERRED transaction checks and authorises the card but leaves a 'shadow' on the cardholders account (for around 10 days). In this case you need to RELEASE the transaction to actually charge the card and get the money. Although the shadow only lasts a few days you can still release the payment later than this but are no longer guaranteed that the funds will still be available.

 

It is recommended that unless goods are dispatched immediately retailers use PRE_AUTH / DEFERRED and repeat/release the money when goods are actually dispatched.

 

More information is available from protx here: http://www.protx.co.uk/smallbusiness/03_payment.asp

 

The ability to release/repeat/refund etc is on my to-do list from the module!

 

HTH,

Tom

Share this post


Link to post
Share on other sites

Cheers fella,

The reason I ask is, whilst I "admin" the e-commerce site, I don't run it, and the people that do are a little "slow" about such things, basically "bone idle" so I don't want to have to tell them, er guys you've got another step.

 

As of now however they will be delay shipment for 14 days to ensure payment isn't fraudulent.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this  

×