close ad
Databridge V2 with MySQLi support IS Now Available!
open ad
View Menu

Technical Support Forums

Free, outstanding support from WebAssist and your colleagues

rating

eCart not writing back to database for a significant number of orders, despite successful payment at PayPal

Thread began 3/03/2020 7:06 am by Nathon Jones Web Design | Last modified 8/27/2020 2:32 pm by Ray Borduin | 344 views | 26 replies |

Nathon Jones Web Design

eCart not writing back to database for a significant number of orders, despite successful payment at PayPal

For some reason, a significant number of orders are not writing to database despite successful payment, but the problem is that there is no apparent pattern to it, although I strongly suspect that there will be.

1) If payment at PayPal is successful, we've established that this is updated on either the confirm.php or pp_confirm.php page. Why would some orders be writing successfully to database, and others not?
We've investigated the following already...
i) Type of payment - PayPal Account or Guest Checkout - both are affected.
ii) New orders or returning orders - both are affected.

2) Does a user have to have a Website Payments Pro account in order for eCart integration to work? Our client has a Business account, and we have API credentials set up for that..

When an order doesn't write back to database, following successful payment, it's also not redirecting the customer to checkout_success.php, which we know because an e-mail should be generated at that stage, but isn't.

What I'm not clear on is how it's possible for an order to be successfully processed by PayPal but the Store Summary in Database to not work.

Hope you can help. FTP details provided below.
Thank you.
NJ

Sign in to reply to this post

Nathon Jones Web Design

FTP below. Thank you.
NJ

Sign in to reply to this post

Ray BorduinWebAssist

This is probably because you allow people to access your site from:
sportsmedicalcertificates.com

and from:
www.sportsmedicalcertificates.com

But your url that returns from paypal uses one or the other, so it might switch mid-process.

The best solution is to add an .htaccess file that forces one or the other, then make sure your confirm.php page has the correct one specified for the paypal return url to be consistent.

See:
https://stackoverflow.com/questions/4916222/htaccess-how-to-force-www-in-a-generic-way

or:
https://www.inmotionhosting.com/support/website/force-www-htaccess/

Sign in to reply to this post
Did this help? Tips are appreciated...

Nathon Jones Web Design

Where is the URL that returns from PayPal set/configured, and if it’s set/configured then why does it use one or the other?

I’m going to have to drive back in to the office as I need to resolve this today as it’s causing all sorts of problems

I’m not clear why eCart allows this to happen in the first place, if it’s so destructive to the payment process.

I’ve no idea what the information in those links you’ve provided means as I’ve no knowledge of htaccess files.

I also really don’t understand why, if the URL is set/configured in confirm.php already, one assumes it must be, why PayPal or eCart is overriding that and just doing what it wants.

I appreciate the advice and guidance, as ever, thank you Ray.

Regards
NJ

Sign in to reply to this post

Ray BorduinWebAssist

The setting is on lines 273-277 of confirm.php. You have:

$WA_PP_ECO_Set_params[0][$nextIndex] = "ReturnURL";
$WA_PP_ECO_Set_params[1][$nextIndex] = "https://www.sportsmedicalcertificates.com/pp_confirm.php";
$nextIndex = count($WA_PP_ECO_Set_params[0]);
$WA_PP_ECO_Set_params[0][$nextIndex] = "CancelURL";
$WA_PP_ECO_Set_params[1][$nextIndex] = "https://www.sportsmedicalcertificates.com/checkout_failure.php?ppcancel=1";


You don't have to go back to the office.... I updated your .htaccess file for you using the FTP information you provided. I updated it to:

RewriteEngine On

RewriteCond %{HTTPS} off [OR]
RewriteCond %{HTTP_HOST} !^www\. [NC]
RewriteCond %{HTTP_HOST} ^(.*)$ [NC]
RewriteRule (.*) https://www.%1/$1 [R=301,L]



This will ensure that everyone that visits your site will see the https:// version and will use www. in front of the domain. That matches the return url setting in your confirm.php page so that should fix the issue.

Sign in to reply to this post
Did this help? Tips are appreciated...

Nathon Jones Web Design

Well, that is absolutely decent of you Ray, thank you. I will arrange a payment /tip when I’m in the office tomorrow.

So I’m clear on this, are you saying that people who have accessed the site using https://sportsmedicalcertificates.com will have experienced problems because https://www... was specified in confirm.php?

I know that the client has https://sportsmedicalcertificates.com specified as the domain in their general account settings in PayPal.

I know you’ve edited the htaccess file to check this and force the www. but should I ask the client to update that and might that have been/be the cause of this issue?

Are confirm.php and pp_confirm.php both used in the process?

You advised that I add some additional code to pp_confirm.php to ensure that PayPal doesn’t accept/process payments twice, which it had been doing. I assume it’s safe to leave that code where it is?

Really appreciate the support.
Thank you.
NJ

Sign in to reply to this post

Ray BorduinWebAssist

No need to update anything else. Yes, if the user started at https://sportsmedicalcertificates.com, then when they returned from paypal it would go to https://www.sportsmedicalcertificates.com and they would be in a new session, so the cart would be cleared.

It doesn't have anything to do with paypal settings, and not other pages need to be updated since that is the only one that sends people to paypal's site and specifies a return url.

I would add that htaccess file to any site you have paypal express checkout on. Really SEO gurus suggest using one or the other consistently anyway so your site doesn't get treated like two sites by google and decrease the ratings of both since traffic will be divided between the two.

Sign in to reply to this post
Did this help? Tips are appreciated...

Nathon Jones Web Design

This morning we've had another order on the site that hasn't written to database so I fear the solution recommended above isn't the cause, although I do believe that it's still sensible to have this fix.

What else could be causing this?

PayPal Merchant Technical Support have confirmed that IPN notifications are on, and working, and are recommending that we speak to the cart application developers.

If the database isn't being updated, despite successful payment at PayPal, it does suggest an issue with either confirm.php or pp_confirm.php does it not? Customers have said, albeit it has been vague, that "the page said that the payment had not gone through" which we're having to assume is our checkout_failure.php page but why is it directing to that page if the payment has been successful?

In a lot of cases, customers have then run through the process again only to discover that they've been charged twice.

We just can't get eCart to work on this website, and it's now very seriously affecting the client's business.

I'd really appreciate your help with this. Thank you.
Regards
NJ

Sign in to reply to this post

Ray BorduinWebAssist

Are you talking about the SMCorders table that isn't being written into?

In order to debug this we are going to have to figure out how to debug it. That means reproducing the problem. I can probably update the pp_confirm page and log any access to the page so that when another one fails we can at least reproduce it.

What is the field size you are using for the SMCorderPAYPALRESP column? Maybe it is running into a size limit?

Sign in to reply to this post
Did this help? Tips are appreciated...

Nathon Jones Web Design

Yes, it's the SMCorders table.

I have run umpteen tests on this - including many live purchases - and I simply can't replicate it, yet it's happening on a daily basis for a lot of other people, but not for all. I, therefore, think that trying to reproduce the problem is going to be tricky so perhaps logging access is a good idea in terms of being able to pinpoint where it's going wrong?

SMCorderPAYPALRESP is a TEXT field so there should be no issues with data size for that field. I've included an example, privately below, of what is written to that field for successful transactions., fyi.

If you are able to add something to pp_confirm.php that can log access, I can let you know when a transaction fails again and we can take it from there.

Thank you Ray.
NJ

Sign in to reply to this post
loading

Build websites with a little help from your friends

Your friends over here at WebAssist! These Dreamweaver extensions will assist you in building unlimited, custom websites.

Build websites from already-built web applications

These out-of-the-box solutions provide you proven, tested applications that can be up and running now.  Build a store, a gallery, or a web-based email solution.

Want your website pre-built and hosted?

Close Windowclose

Rate your experience or provide feedback on this page

Account or customer service questions?
Please user our contact form.

Need technical support?
Please visit support to ask a question

Content

rating

Layout

rating

Ease of use

rating

security code refresh image

We do not respond to comments submitted from this page directly, but we do read and analyze any feedback and will use it to help make your experience better in the future.

Close Windowclose

We were unable to retrieve the attached file

Close Windowclose

Attach and remove files

add attachmentAdd attachment
Close Windowclose

Enter the URL you would like to link to in your post

Close Windowclose

This is how you use right click RTF editing

Enable right click RTF editing option allows you to add html markup into your tutorial such as images, bulleted lists, files and more...

-- click to close --

Uploading file...