Jump to content
  • Checkout
  • Login
  • Get in touch

osCommerce

The e-commerce.

Urgent Help Needed with ePDQ Payments


rickhudson

Recommended Posts

I've put together a shopping cart site and am trying to use the Barclaycard ePDQ payment module to process credit card payments.

 

The problem I have is that some users, having paid in the ePDQ system, do not press continue in order to return to the shop, so that the order can be processed through the system and entered into the database.

 

As a result of this, some clients have paid but their orders do not appear in the database.

 

I would appreciate suggestions from anyone who has experience of setting up ePDQ for osCommerce into how they got it to work with the ePDQ CPI.

 

Barclaycard are adamant that by processing the POST transactions their part is complete and that users should not need to click "Continue". My problem is that I can't see that posting to any of the other scripts will result in a "Success" and still enable me to stop "Declined" transactions from going through the shop.

 

Any help would be much appreciated!

 

Richard

Link to comment
Share on other sites

  • 2 weeks later...
  • Replies 388
  • Created
  • Last Reply

Top Posters In This Topic

  • 1 month later...

I'm using the 'recover carts' contrib to check what they bought. I'll get the email from epdq but if they don't hit continue the cart doesn't show that anything has been sold. Recover carts shows what they last had in their trolley when they left

 

Hope that helps

 

stubbsy

Link to comment
Share on other sites

Hi Guys,

 

I've just worked out that I've got this problem too. The order should be added to the database before the user gets redirected to the ePDQ site.

 

I am going to rewrite the module to make it work. it should be done by tomorrow afternoon. Stay tuned!!

 

Cheers

 

Tim

Link to comment
Share on other sites

After searching the osCommerce documentation i found this link:

 

http://www.oscommerce.info/kb/osCommerce/Common_Problems/208

 

Which means that it isn't going to work without a new module until MS3 (whenever that'll be). I'm going to try and use some of the PayPal_IPN contribution to create a new module that'll store the info before it gets redirected.

 

hope this helps.

 

Tim

Link to comment
Share on other sites

I am going to rewrite the module to make it work. it should be done by tomorrow afternoon. Stay tuned!!

 

Cheers

 

Tim

 

Tim

 

Any luck with this? I've been on to Barclaycard/ePDQ today and they say it should be possible to capture what they send back at the point the payment is processed successfully (as other shop solutions do it) and use this to trigger oscommerce to mark the order as ready for despatch instead of waiting for the continue. Its still a bit beyond me as I've only just started with osc but it would be good to hear how you got on.

 

ChrisJ

Link to comment
Share on other sites

I'm looking into the same issue.

 

cpi/complete.php stores a temporal entry in epdq_tramsactions table but should also do what epdq_success.php currently does. And that is making sure the order ends up in the osC orders table.

 

If they don't click 'Continue' they will never get to the epdq_success.php so the order WILL NOT go into the back-end orders of osC. Yes, Barclays is right in saying [page 17 - CPI Mandatory Requirements] they report back regardless of the customer clicking the continue button but this contrib simply doesn't handle it correctly.

 

CPI does NOT require this action, it has done it's job and passe dit onto to cpi/complete.php. The contrib DOES require the continue button to be clicked because of the code in epdq_success.php.

 

No I've identified the culprit, I shall try and put epdq_success code into the complete.php script to make it truly continue-button-independant.

 

BTW found what I think is a typo in complete.php on line 101. It says $$link where it should be a single $.

 

Will keep you posted.

Johan a.k.a. T0PS3O elsewhere.

 

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

Link to comment
Share on other sites

No I've identified the culprit, I shall try and put epdq_success code into the complete.php script to make it truly continue-button-independant.

 

 

Thanks for the update. I think Tim is working on this still too. Maybe a PM would help prevent any duplication. I'm still too new to osc to take a look myself but I'm getting there, slowly....

 

 

Chris

Link to comment
Share on other sites

I was about to ring him but see he is on the forum now. Will try and get him involved.

 

I don't thin k we need that PayPal code though. We simply need to invoke the code from checkout_success.php when the ePDQ posts back to complete.php.

 

Will dig a bit further... I'd like to crack this nut before the end of today.

Edited by JoeMcManus

Johan a.k.a. T0PS3O elsewhere.

 

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

Link to comment
Share on other sites

I'm looking into the same issue.

 

No I've identified the culprit, I shall try and put epdq_success code into the complete.php script to make it truly continue-button-independant.

 

Will keep you posted.

 

As Chris said I am loking at this. I am finding that the system is a little weak on this area. It processes the paymen before any order details are stored permenantly in the system. This makes transactions really quite unsafe.

 

Before the customer gets diverted in to the ePDQ page, osc needs to insert the data into the database, so that the 'epdq/complete.php' script can update it.

 

Check out the paypal_IPN contrib, if you are in a rush and you need to get something working. It should point you in the right direction and give you some working code that you can alter.

 

Hope this helps

 

Tim

Link to comment
Share on other sites

But if you store it beforehand and the customer aborts altogether, then you have redundant database entries sitting there.

 

Wouldn't it be best practice to store the lot the very second when ePDQ tells complete.php that the transaction is complete? Or declined.

 

If succesfull, it will add it to the orders table and do exactly what checkout_process.php now does. If declined it should keep it in the epdq_transactions table. When declined, the customer will be more inclined to click continue to find out what's wrong. epdq_success will find out it was declined from the epdq_transactions table and forward them to the shopping cart for a possible second attempt, also displaying a clue to what went wrong.

 

This way the only ever redundant database entries will be in the epdq_transactions table. Orders table will stay tidy and fille donly with successful orders.

Johan a.k.a. T0PS3O elsewhere.

 

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

Link to comment
Share on other sites

But if you store it beforehand and the customer aborts altogether, then you have redundant database entries sitting there.

 

Wouldn't it be best practice to store the lot the very second when ePDQ tells complete.php that the transaction is complete? Or declined.

 

 

It would be great if you could do that, but I don't think order information is passed to ePDQ, just the total cost. And when ePDQ posts to complete.php it is in a new session. So the basket/order details don't exist to add into the database.

 

I think that it is better to add the order into the database, and set the status to something like 'unprocessed', then update it if epdq says so. Then set up a cronjob to clear the old unprocessed orders from the DB every couple of days.

 

does that make sense?

 

Tim

Link to comment
Share on other sites

Updating the status and cleaning it up with a cron job makes perfect sense.

 

The thing I overlooked is that when ePDQ POSTs the transaction status, it's not in a browser so not all the required osC variables can be accessed even when the ePDQ POST does send back a lot of stuff.

 

See page 18 - CPI Mandatory Requiremtns. Also see in complete.php what is being sent back.

 

transactionstatus

total

clientid

oid (!!) - (Overlooked by myself: cannot be referenced yet because not in DB only in session/cookie variables, not accessible by complete.php/ePDQ.)

chargetype

datetime

ecistatus

 

It's clear to me now how complete.php can't utilize the session variables.

 

I'll have a look at the PayPal thing to see at what stage they make the temp_order table and how. When the oid is in there, the rest is easy. Like you say, complete sets it from pre_epdq_stage to success or declined.

 

Cron can delete all pre-POST abandoned orders. Faile dorders could be followed up in an attempt to convert, then deleted later if necessary.

 

Thanks for making me see the light, only a week into my osCommerce carreer; plenty left to learn!

Edited by JoeMcManus

Johan a.k.a. T0PS3O elsewhere.

 

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

Link to comment
Share on other sites

Wuahoo it works!

 

Bit of a dive in the deep end, tried with just copying the confirmation code from PayPal_IPN, bit of tweaking of the ePDQ.php and complete.php and work lovely now.

 

ePDQ.php now stores the order in the orders table prior to sailing off to the CPI on Barclays servers. It stores it with a new order_status which I hardcoded (the status_id) in there and named it 'Awaiting Payment' (in the admin-localization).

 

Customer enters their stuff on the Barclays page. Once it shows 'Susses' on the last page (before hitting the continue button' Barclays POSTs back to complete.php which takes the transaction status and updates the order status from 'Awaiting Payment' to 'Payment Received'. If it's declined, it will remain 'Awaiting Payment' so you can follow up and still have all details.

 

ePDQ_succes still does the same. Deletes successful entries from the epdq_transactions table and forward to the success page if successful or cart if unsuccessful.

 

TODO:

1) Make it tidy and use system config variables instead of hardcoding it in (like db queries).

2) Status History is not being updated/entered yet.

3) Not sure what happens on transaction declined and the customer is being redirected to cart and then fills it all out again. It will probably create another new order.

 

That's it for now. Will make it available after the weekend, got a busy schedule ahead!

Edited by JoeMcManus

Johan a.k.a. T0PS3O elsewhere.

 

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

Link to comment
Share on other sites

Will do asap.

 

You'll probably find a handful of lines that could be a bit better.

 

This sounds great. You've probably already thought of this but :

 

if youhave multiple customers paying at the same time how does the complete.php work out which "temporary" order to move to OSC completed orders table from the data posted back from epdq. Is there some code passed to epdq which uniquely identifies the order "on hold"?

 

Does the script make sure that the post from epdq is actually from epdq and not from another web site? If you place an order and go to pay but then force a POST to the shops complete.php from another site with the payment success details what stops the shops complete.php script accepting this bogus post data? If I understand correctly it is in a new session rather than the existing session already set up.

(I may be well of mark on this one but having talked to the technical guys at epdq this was one area I was still woolly on despite their efforts to educate me).

 

Is there a timeout on the amount of time between leaving to go the epdq site and the return post coming back after which the temporary order can't be transferred to the completed orders.

 

I don't think its a big deal clearing out the "payment failed" orders. If 10% of orders fail (which I think is a high estimate) and you get 100 orders per day thats still a very small amount of extra records by the end of the month. It would be better to be able to identify the customer from the "uncompleted" order and their basket contents and to display all their orders to see if they had a newer order that was successful and if not to contact them if you can complete the order on the phone and to ask how to make theier shopping experience better. It might be good to be able to email "[email protected]" with the details after the "time out" so that you have the option of following it up whilst the order is still fresh in their mind.

 

"Hello this is Mike from myoscshop customer services. Our records show you might have experienced a problem shopping on our site. We apolgise for any inconvenience this has caused you. Would you still like to place the order? I can take the details over the phone if you wish? For security you may wish to call us back on the telephone number on our website. Just ask for Mike when you get through."

 

...is much more likely to create a returning customer than no action at all or a call at the end of the month. Of course you can decide whether to call them or not based on wether they have placed a subsequent successful order.

 

Did you say that if it returns unsuccessful complete.php will display "You seem to have had a problem" and return them to the shop with their cart still containing their order items so that they can try again?

 

Looking forward to hearing from you again.

 

"I'nt open source brillyunt."

 

Chris

Link to comment
Share on other sites

This sounds great. 

 

Any news on this Joe? Not meaning to push but it would be nice to be able to tell my client when they might expect it to be available. I've found people are often quite willing to wait if they know how long they have to wait but don't like being in the dark even if its for less time.

Hope you've managed to get this sorted. You will be making alot of people happy!

 

Looking forward to hearing from you

 

Chris

Link to comment
Share on other sites

Chris,

 

Thanks for the ideas.

 

I'm beta testing it now and have found some things I need to sus out but the basic functionality works just fine.

 

As with everything it obviously takes longer than expected / hoped for.

 

I want this shop proper live by the end of Tuesday next week. By then the people staying over at my place are gone again as well so will be back to 'normal' 9am - 10pm working hours after the weekend. In the days after that I will post the code up for use/review.

 

Without making promises, I estimate to be back here a week from today.

 

I'm subscribed to this thread so will receive e-mail notification which is read promptly.

 

J

Johan a.k.a. T0PS3O elsewhere.

 

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

Link to comment
Share on other sites

By then the people staying over at my place are gone again as well so will be back to 'normal' 9am - 10pm working hours after the weekend.

What are you doing beofre 9am? Why can't you get up a bit earlier !!! ;) and fancy finishing at 10pm! Whoever heard of that! <_<

 

 

Without making promises, I estimate to be back here a week from today.

 

Joe

 

Thanks for all your efforts on this. I've got another meeting next friday (hopefully) with a client that is a lead from the client wanting the epdq and they want a shop site too! Foretunately its the same products so that makes populating it easier, hopefully they will want the same payment arrangements. Though they have indicated they may want to customers to be able to pay "on account".

 

Looks like I need to do a search.

 

Anyway good luck

 

Speak to you next week.

 

Chris

Link to comment
Share on other sites

getting desperate here also good at asp but not very good at php

can anybody please help with the EPDQ contrib :(

 

as above posts oscommerce does not recognise the oid when you finish the payment through epdq anybody out there any good at php ???

Link to comment
Share on other sites

  • 2 weeks later...

Go fetch the code here:

 

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

 

I hope it works out alright for you people.

 

Let me know what you think, it's mainly a learning experience for me especially it being my first OsC contrib even within 5 weeks of working with the software.

 

Johan a.k.a. JoeMcManus

 

PS B*ll*cks! Just noticed the version was already up to 1.2!

 

I'm sure you'll find some bugs, then we'll rename it Version 2...

Edited by JoeMcManus

Johan a.k.a. T0PS3O elsewhere.

 

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

Link to comment
Share on other sites

Go fetch the code here:

 

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

 

I hope it works out alright for you people.

 

Let me know what you think, it's mainly a learning experience for me especially it being my first OsC contrib even within 5 weeks of working with the software.

 

Johan a.k.a. JoeMcManus

 

PS B*ll*cks! Just noticed the version was already up to 1.2!

 

I'm sure you'll find some bugs, then we'll rename it Version 2...

 

Joe

Thanks for this. Just a few points you might not be aware of:

1) There is a cpi folder in the contribution zip file with 3 files in it: .htaccess, .htpasswd2 and complete.php

These contain user names and passwords (encrypted) and a domain name (buy a mattress) and this may or may not cause you a security problem.

2) The instructions don't detail anywhere whether this folder is required or not, and if it is it doesn't say what to do with the complete.php file.

 

3) Files listed in the instructions are

epdq_success.php

lang\epdq_success.php

ePDQ.php

lang\ePDQ.php

 

but not all these files/ folders exist in the latest contribution file!

 

epdq_success.php is there

 

lang\epdq_success.php is not there nor is the folder lang

ePDQ.php and lang\ePDQ.php are not there but catalog\includes\languages\english\modules\payment\ePDQ.php and catalog\includes\modules\payment\ePDQ.php are.

 

Any pointers appreciated.

 

ChrisJ

Edited by cjohnson_uk
Link to comment
Share on other sites

Joe

Thanks for this.  Just a few points you might not be aware of:

1) There is a cpi folder in the contribution zip file with 3 files in it: .htaccess, .htpasswd2 and complete.php

These contain user names and passwords (encrypted) and a domain name (buy a  mattress) and this may or may not cause you a security problem.

2) The instructions don't detail anywhere whether this folder is required or not, and if it is it doesn't say what to do with the complete.php file.

 

3) Files listed in the instructions are

epdq_success.php   

lang\epdq_success.php

ePDQ.php           

lang\ePDQ.php       

 

but not all these files/ folders exist in the latest contribution file!

 

epdq_success.php    is there

 

lang\epdq_success.php  is not there nor is the folder lang

ePDQ.php  and  lang\ePDQ.php        are not there but catalog\includes\languages\english\modules\payment\ePDQ.php and catalog\includes\modules\payment\ePDQ.php are.

 

Any pointers appreciated.

 

ChrisJ

 

 

Chris,

 

Thanks, in my excitement I must have overlooked those. I indeed forgot about the language files.

 

That CPI folder wasn't meant to have those specific details either, I'll change them for security on our end and upload a new compilation with the correct files.

 

Should be there in a minute.

 

Johan

Johan a.k.a. T0PS3O elsewhere.

 

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

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Unfortunately, your content contains terms that we do not allow. Please edit your content to remove the highlighted words below.
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...