Jump to content
Sign in to follow this  
rickhudson

Urgent Help Needed with ePDQ Payments

Recommended Posts

[drumrolls]

 

Quick! Run to the contribution section for the latest and greatest ePDQ contribution:

 

http://www.oscommerce.com/community/contributions,430

 

Do post your feedback if you can - but I have to warn I won't be able to provide the level of support I used to with this. There's enough skills amongst you guys to sort this out between you if it doesn't go according to plan.

 

Enjoy!

 

[/drumrolls]


Johan a.k.a. T0PS3O elsewhere.

 

Contributed Barclay's ePDQ Payment Module though not originally mine. Made it work though...

Share this post


Link to post
Share on other sites

Well I've got the new contribution working on my site very well and its only taken me the morning, it was an upgrade from the last one. Only one major issue at the moment that i'm working on, i'll come on to that in a minute.

 

I've been trying to solve the problem of the digital reciept emails not being sent out all week so this came out at the perfect time for me and stopped me going crazy, digging ever deeper into oscommerces inner workings. I cheered so loudly when the full email arrived with all the order details on there

 

anyway the problem i have is this.

 

- when going through the check out process all seems to be going well

- until you get to the final screen in the the process (checkout_confirmation.php)

- it seems not to make the request to the barclays server for the encrypted epdqdata

- so i thought i was seeing a cached page or something i press f5 and now included in the form is the full epdqdata string

 

and everything works perfectly through out the rest of the process.

 

am going to have a dig into this now, to see if i can see what might be.

 

Any sugestions gratefully accepted, just thought you would like to hear about my progress from what I think is a successful morning.

 

i'm running a standard install of oscommerce, this is the only extra contribution i have installed.

 

 

cheers

 

Matt

Share this post


Link to post
Share on other sites

This is exactly the same problem as I had, on my installation it turned out to be a problem in checkout_payment. The hidden field containing the chosen payment method wasn't being written.

 

I fudged it by manually adding that hidden field since my store only takes payments using the epdq module.

 

I added the line

 

echo tep_draw_hidden_field('payment', 'ePDQ');

 

you can check this by addeding these lines in checkout_confirmation around line 390 where you see

 

if (is_array($payment_modules->modules)) {

 

add these few line to print a diag on screen

 

echo '<pre>';

Print_r($payment_modules);

echo '</pre>';

 

 

 

Well I've got the new contribution working on my site very well and its only taken me the morning, it was an upgrade from the last one. Only one major issue at the moment that i'm working on, i'll come on to that in a minute.

 

I've been trying to solve the problem of the digital reciept emails not being sent out all week so this came out at the perfect time for me and stopped me going crazy, digging ever deeper into oscommerces inner workings. I cheered so loudly when the full email arrived with all the order details on there

 

anyway the problem i have is this.

 

- when going through the check out process all seems to be going well

- until you get to the final screen in the the process (checkout_confirmation.php)

- it seems not to make the request to the barclays server for the encrypted epdqdata

- so i thought i was seeing a cached page or something i press f5 and now included in the form is the full epdqdata string

 

and everything works perfectly through out the rest of the process.

 

am going to have a dig into this now, to see if i can see what might be.

 

Any sugestions gratefully accepted, just thought you would like to hear about my progress from what I think is a successful morning.

 

i'm running a standard install of oscommerce, this is the only extra contribution i have installed.

cheers

 

Matt

Share this post


Link to post
Share on other sites

That's strange because Gary had the same thing.

 

Is ePDQ your only payment module or do you have more?

 

Check checkout_payment.php and try anbd follow its logic. There if statements that handle when there's more than 1 $selection. You will find that if ePDQ is the only one, it should draw a hidden field with its ID set. That's $payment on checkout_confirmation.php and without it it won't load the form data indeed.

 

With Gary's setup, that payment option didn't get forced into that hidden field. Only on a reload which is even more strange.

 

His work around was to hard code it in.

 

I never got this issue (have 3 payment options) so I don't know whether this is a bug with the contrib or in osCommerce altogether. If someone finds the origin then let me know so I can incorporate it.

 

Hopefully that info gets you going.

 

EDIT LOL beaten to it by the man himself...

Edited by JoeMcManus

Johan a.k.a. T0PS3O elsewhere.

 

Contributed Barclay's ePDQ Payment Module though not originally mine. Made it work though...

Share this post


Link to post
Share on other sites

Thanks for the quick reply on this

 

I started off with gary's (excession) hard coded hack with the payment type put in the hidden field but this still didn't work. so I used the de-bug code he gave me, and it seemed to only be partially working. It seems that it has something to do with registering the payment method that has been selected into the

$payment_modules -> selected_module

 

variable

 

this happens at this line

$payment_modules->update_status();

in the checkout_confirmation.php file. i've followed this command back to payment.php when it is declaired and it looks like someone has doubts about it there too according to the comment. perhaps someone who has more php knowledge than me could read it to work out what is going on.

 

anyway. I think that update_status() is supposed to add the selected module from the checkout_payment page to the selected module variable not sure why is happens only the second time round.

 

manually entered the data into $payment_modules -> selected_module with the following line just before the update_status command is called so that it all reads like the following.

 

 require(DIR_WS_CLASSES . 'payment.php');
 $payment_modules = new payment($payment);

 require(DIR_WS_CLASSES . 'order.php');
 $order = new order;
// matt edit
 $payment_modules->selected_module = 'ePDQ';
//matt edit end 

 $payment_modules->update_status();

 

this of course won't work when you have multiple payment options. but i think that suits me for now as i'm unlikely to need to add other methods.

 

thanks for the help

 

Matt

Share this post


Link to post
Share on other sites

Matt,

 

Thats basically the same solution as I used although I did it in a different place. Just force the selection of the ePDQ module since it's the only ojne used it won't cause a problem.

 

Gary

Share this post


Link to post
Share on other sites

I do have an update_status function in my ePDQ which I use to check that for that billing country I allow ePDQ. Maybe when I deleted that code I did it wrong.

 

In the original stock code, that function doesn't exist. Where I return false in the contrib maybe we should get rid of it altogether or let it return true?

 

Maybe you guys can try that. It obviously is somewhere in that region.


Johan a.k.a. T0PS3O elsewhere.

 

Contributed Barclay's ePDQ Payment Module though not originally mine. Made it work though...

Share this post


Link to post
Share on other sites

I've just looked at implementing this module and lucky me its been recently updated so I have some hope that the code isn't completely out of date and at least someone out there is still using it and can offer advice. I have installed the module via the admin section but I can't see an option to select it the list of payment methods on confirm_payment.php , its enabled in the admin section but its simply not displaying.

 

I am not that experienced at debugging the payment class but it seems that the method selection() isn't returning this module in its array of installed / enabled modules. Has anyone else seen this?


"...you do one little thing, you build a widget in Saskatoon and the next thing you know it's two miles under the desert, the essential component of a death machine..."

Share this post


Link to post
Share on other sites

Rob,

 

Check your configuration table to see it was added properly there.

 

I coded most of it and never installed it from scratch again on a fresh store so other than the usual debugging I can't help much. Look for while loops in the payment functions and classes and echo all the ones they find to see whether it gets close at all.

 

By the way, I spotted a silly mistake in the latest update which I'm finally fixing now so hopefully I'll be able to put a new contrib up today or tomorrow. Problem is that after the customer hits the checkout_confirmation page, and then goes back to change stuff, the order won't get updated.

 

Johan


Johan a.k.a. T0PS3O elsewhere.

 

Contributed Barclay's ePDQ Payment Module though not originally mine. Made it work though...

Share this post


Link to post
Share on other sites

ok I have resolved the problem there,

 

the method selection in the new ePDQ class simply returns false. I have ammended it as per other payment classes and this is looking better now.

 

	function selection() {
	#return false;
	return array('id' => $this->code,
				 'module' => $this->title);
}


"...you do one little thing, you build a widget in Saskatoon and the next thing you know it's two miles under the desert, the essential component of a death machine..."

Share this post


Link to post
Share on other sites

Thanks, I'll add that to the update.

 

In the selection function I have code that deals with fraud handling. I had to remove that from the contrib - it's too tailored. Looks like I forgot to put back what would have been there originally.

 

Thanks for the digging.


Johan a.k.a. T0PS3O elsewhere.

 

Contributed Barclay's ePDQ Payment Module though not originally mine. Made it work though...

Share this post


Link to post
Share on other sites

One rather worrying thing I have noticed is that every time you select the payment option and proceed to checkout_confirmation.php a new order is created. this is a bit strange because at the order confirmation stage you are still given the option to ammend your cart before finally confirming the order. So if you click back to your cart and come through again you get another order (be it processing) in your orders table. Is this what you were saying was the issue you were investigating or is this behaviour expected?

 

Many thanks and sorry to be a pain.


"...you do one little thing, you build a widget in Saskatoon and the next thing you know it's two miles under the desert, the essential component of a death machine..."

Share this post


Link to post
Share on other sites

Gary,

 

Yes, that might well be the case. If I remember correctly, we looked at that bit of code before but we must have not quite gotten there then. If someone could verify Rob's solution works then I'll defo add it.

 

Rob,

 

It shouldn't do that. It checks to see whether the cart id and temp epdq order id are registered in the session. If it is (like it should when you get back to checkout_confirmation, then it won't insert a new one. See the code where it says if ($insert_order == true)...

 

So maybe you didn't copy the necessary parts from checkout_payment etc.?

 

I'm updating that part of the code as we speak - right now it won;t update when someone changed the address for instance - will be fixed shortly.


Johan a.k.a. T0PS3O elsewhere.

 

Contributed Barclay's ePDQ Payment Module though not originally mine. Made it work though...

Share this post


Link to post
Share on other sites

Thanks I shall go a take a look, just to note. It only adds a new order if the cart has been ammended as far as I can see. e.g. I have 1 black shoe in my cart, then go to confirm (new order created), then alter my cart to have 2 black shoes, to confirm (new order created), then altering back to 1 shoe (new order created). If I click back to the cart and don't make any changes then no new order is created.

 

Something is changing when you update the cart for some reason. Just to confirm and just in case it makes a difference I am using a completely fresh install so that I can break it completely before going near a live shop, so I just copied the contribution files over the default code base.


"...you do one little thing, you build a widget in Saskatoon and the next thing you know it's two miles under the desert, the essential component of a death machine..."

Share this post


Link to post
Share on other sites

That makes more sense...

 

This line

 

if ( ($curr['currency'] != $order->info['currency']) || ($cartID != substr($cart_ePDQ_temp_id, 0, strlen($cartID))) ) {

 

is probably causing that. However, I haven't ever checked whether changing the cart would give it a new cart id.

 

Whilst I;m in there I'll examine the logic of it, that was largely untouched from even back in 2003 so it might well be due some thinking.

 

Could you echo the $cartID in ePDQ.php please and see whether it changes every time you change the basket?


Johan a.k.a. T0PS3O elsewhere.

 

Contributed Barclay's ePDQ Payment Module though not originally mine. Made it work though...

Share this post


Link to post
Share on other sites

Yup, is I check the contents of my session the cart ID changes on the checkout_shipping.php page

 

shopping_cart.php (empty)

 

cartID|s:5:"26992"

cart_ePDQ_temp_id|s:8:"26992-10"

 

shopping_cart.php (1 item)

 

cartID|s:5:"26992"

cart_ePDQ_temp_id|s:8:"26992-10"

 

checkout_shipping.php (1 item)

 

cartID|s:5:"09223";

cart_ePDQ_temp_id|s:8:"26992-10"

 

In theory should both of these ids stay the same during the whole transaction?


"...you do one little thing, you build a widget in Saskatoon and the next thing you know it's two miles under the desert, the essential component of a death machine..."

Share this post


Link to post
Share on other sites

There multiple way of doing this... Don't think there is a 'best' way. It changing on checkout_shipping is surprising to me. I'll check that out.

 

The previous version would delete an order on confirmation and add a fresh one. I didn't like it since it runs up your order numbers pretty fast. That's why it now (was supposed to) update the order instead.

 

Let me have a geeze.


Johan a.k.a. T0PS3O elsewhere.

 

Contributed Barclay's ePDQ Payment Module though not originally mine. Made it work though...

Share this post


Link to post
Share on other sites

cartID is meant to be random on every page.

 

I'm having a hard time understanding how it's referenced against the ID in the database/session though.

 

On one of my shop (which takes loads of orders just fine) the damn $cartID is empty all the time!

 

Will take some digging to 1. understand it and then 2. do something wise with the knowledge.


Johan a.k.a. T0PS3O elsewhere.

 

Contributed Barclay's ePDQ Payment Module though not originally mine. Made it work though...

Share this post


Link to post
Share on other sites

To be honest I am not following how to this pre-ordering order addition to the database thing is working either or how cartID relates to adding the order to the database. Perhaps when an order is added to the database you could set a session variable to say 'active_order: 1' or something. In theory if someone is getting this far in the transaction they are going to complete the order anyway and they are at a stage where their session is unlikely to timeout

 

in ePDQ.php

 

instead of

tep_session_register('cart_ePDQ_temp_id');

$cart_ePDQ_temp_id = $cartID . '-' . $insert_id;

 

something like

tep_session_register('active_ePDQ_order');

$active_ePDQ_order = $insert_id;

 

I think the use of the $cartID is confusing things and as far as I can see at the moment unnecessary. I guess as long as you have the inserted order id to hand you are ok.


"...you do one little thing, you build a widget in Saskatoon and the next thing you know it's two miles under the desert, the essential component of a death machine..."

Share this post


Link to post
Share on other sites

Just re-reading your post, if the one site with the blank cartID everytime is working this equates to what I have just posted, that as long as you have the insert_id you are fine since its irrelevant what the cartID is. What do you think?


"...you do one little thing, you build a widget in Saskatoon and the next thing you know it's two miles under the desert, the essential component of a death machine..."

Share this post


Link to post
Share on other sites

Yes, that's what it says in the comments but since it's not compared to any other value that I can see, how does that hacking prevention work?

 

But yeah, all that might not have to affect this contrib so I'll check it out.

 

BTW just found another little bug...

 

In complete.php the confirmation e-mail doesn't get the order comments since the order class is used and the part that gets it from the DB doesn't fetch the comment, the part that gets it from the session (can't use that in complete) does have the comments.

 

I'll make a workaround.


Johan a.k.a. T0PS3O elsewhere.

 

Contributed Barclay's ePDQ Payment Module though not originally mine. Made it work though...

Share this post


Link to post
Share on other sites

perhaps it's one of the code remnants that was left from some previous release? I must admit, I haven't really looked too deep into the inner workings of it all - too busy with everything else lol

Share this post


Link to post
Share on other sites

I'll see if I can rid of it without breaking things. If we don't understand it, get rid of it :D

 

The logic is fairly simple and it seems like we don't need it.

 

1. They choose ePDQ

2. on checkout_confirmation it gets stored

3. If they change something and go back to checkout_confirmation

4. It needs to Update the order.

 

So all that's required is remembering the order_id that was entered by ePDQ. Whether or not the basket has changed etc. is irrelevant in a way - if they hit checkout_confirmation we can UPDATE regardless - whether or not anything has changed. That way we always have it correct.


Johan a.k.a. T0PS3O elsewhere.

 

Contributed Barclay's ePDQ Payment Module though not originally mine. Made it work though...

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  

×