Paypal IPN orders not being relayed to cart or emailed to owner or buyer

No, the patch will not recover old transactions.
To release "stuck" transactions you'd need to use the PayPal Sessions Viewer contrib in the downloads section.

DrByte, thanks for info/link/prompt response..
:thumbsup:

PayPal is making me crazy. :wacko:

I'm trying to understand whether eCheck payments are available through the "Don't have a PayPal account" option. When I test the IPN, there is no eCheck payment method in PayPal's dropdown on the second page. But on the first page, within the Don't-have-a-PayPal-account fieldset, there is an eCheck logo graphic and text that reads "Use your credit card or bank account (where available)."

I called PayPal support, and the rep told me eCheck is NEVER available via the Don't-have-a-PayPal-account option. She wouldn't tell me why the fieldset on the first page indicates otherwise.

I think she's full of crap, though what she said would explain why -- when I choose Don't-have-a-PayPal-account -- the only payment methods offered are credit cards.

I followed up with an email to PayPal customer support -- maybe they can explain it. Meanwhile, does anyone here understand this?

An eCheck is in essence an electronic request to process a debit against your bank account with all the same benefits/features as a regular check (ie: ability for stop-payment, service charges, etc).

As such, an eCheck can never be funded from a Credit Card.

Further, an eCheck requires that you supply your banking information. I believe that PayPal requires that your bank account be "verified" before it will offer eCheck services for you. If that's the case, you'll need to have an active PayPal account in order to use eChecks.

If your frustration is with the fact that an eCheck logo is displayed along with CC logos, keep in mind that you still have to posess the ability to pay via a given CC before you can use it. For example, while the Visa and Mastercard and Amex logos are displayed, you still have to actually have a Visa or MC or Amex account etc before you can use it to pay with. As such, the display of the echeck symbol isn't really that far off... gads now I sound like I'm defending them.

By the way, you've taken this discussion thread way off topic. ;)

Thank you, DrByte. I'm starting to get the picture. :P

And for the record, I have nothing against PayPal -- in fact, I make a point of implementing PayPal IPN in every store whose owners permit.

My frustration is not with the fact that eCheck is displayed with credit card logos. My frustration is with the fact that eCheck is misrepresented as a payment method one can use in the absence of a PayPal account.

Picture the customer who has no PayPal account, sees the eCheck logo in the "Don't have a PayPal account" fieldset, and chooses that route. As soon as the next page loads and eCheck is nowhere to be found, it's probably time to shop elsewhere.> DrByte:

If your frustration is with the fact that an eCheck logo is displayed along with CC logos, keep in mind that you still have to posess the ability to pay via a given CC before you can use it. For example, while the Visa and Mastercard and Amex logos are displayed, you still have to actually have a Visa or MC or Amex account etc before you can use it to pay with. As such, the display of the echeck symbol isn't really that far off... gads now I sound like I'm defending them.

By the way, you've taken this discussion thread way off topic. ;)

Oh yeah -- sorry 'bout that! :blush: > DrByte:

By the way, you've taken this discussion thread way off topic. ;)

Okay -- after installing yesterday morning's PayPal IPN patch, I just performed an eCheck test (logging into my PayPal account, thank-you-very-much). The checkout_success page notes the order number as 1 (I know that's not right) and nothing new in Admin/Customers/Orders.

Did I miss something? :dontgetit > rstamets:

I quadruple checked and ran a test order through the Paypal IPN. (it was a live transaction)

Customer receives email transaction confirmation from Paypal
Merchant receives email payment confirmation from Paypal
Customer is redirected back to the zc confirmation page

Everything works fine except nothing shows up in any of the order or paypal tables in the database, yet no errors are being thrown during the query.

Help...!

What's in your PayPal log files?

In Customers/PayPal IPN, there's nothing new. Do you want to see the PayPal session info?> DrByte:

What's in your PayPal log files?

No. Sorry -- I can't remember which of the hundreds of posts I've recorded those instructions in.
Turn on Debug Logging in Admin->modules->payment->PayPal IPN
Then make your /includes/modules/payment/paypal/logs folder writable
Then do a test transaction.

I PM'd the session log. As for the log in modules/payment/PayPal/logs, the entire contents:> Mar 05 2007 17:52 -- IPN PROCESSING INITIATED.

*** Originating IP: 216.113.188.202That's all of it.> DrByte:

No. Sorry -- I can't remember which of the hundreds of posts I've recorded those instructions in.
Turn on Debug Logging in Admin->modules->payment->PayPal IPN
Then make your /includes/modules/payment/paypal/logs folder writable
Then do a test transaction.

Your SEO urls mod was throwing an error in html_output.php on line 22 because in v1.3.7 the ipn_application_top doesn't load all the initSystem overrides that the main core does.

Restoring the original html_output file allows IPN notices to work.
Of course, that breaks your SEO url support. :shocking:

The stuck orders mod works very well - thanks!

BUT... if a customer proceeds through checkout and gets to the PayPal payment page (on PayPal's site), AND THEN decides to abandon everything, the "stuck order" is still on my database, but the customer has gone away and perhaps does not intend to return.

Am I right in thinking that a "stuck order" ought to FIRST be matched up somehow with successful PayPal payments?

In other words, check to see if the customer's payment went through to your paypal account FIRST - if it did, (and the record's stuck) only THEN move the order to the database?

You don't want to be moving stuck orders to the dbase if the customer vanished at the paypal stage.

... and then if we've got "stuck orders" in the list that (in reality) are orders that were ABANDONED at the paypal website level - how do we "delete" or "cancel" these, so that they stop showing on the list.

Could a button - "Cancel -- session abandoned at PayPal stage" - be put into the code (button that appears underneath the "Move to Orders database" button) ?

As we all know, PayPal has a mind of its own sometimes and we too have had situations where the automatic re-direct to our shop (after payment), has not "worked" - resulting in "stuck orders".

I modified checkout_confirmation.php (in Languages->English>) to alert customers to the need to return to our site, once they'd finished up at paypal. If the auto-redirect works, they get back anyway... If not, we've told them they should do so! See the screen capture, below...

I really appreciate your looking at this and isolating the problem with eCheck orders not showing up. You rock, DrByte!

I have submitted a bug report on the SEO-URLs bug tracker so Dreamscape can seek a fix in the SEO-URLs mod.

I just now put the modified html_output file back in place, as the absence of modification prevents customers from logging in while SEO-URLs is running. I'm about to test to learn whether the modification in html_output impairs regular PayPal orders, or just eCheck orders.

Again, THANK YOU!

Sean> DrByte:

Your SEO urls mod was throwing an error in html_output.php on line 22 because in v1.3.7 the ipn_application_top doesn't load all the initSystem overrides that the main core does.

Restoring the original html_output file allows IPN notices to work.
Of course, that breaks your SEO url support. :shocking:

DrByte:

Your SEO urls mod was throwing an error in html_output.php on line 22 because in v1.3.7 the ipn_application_top doesn't load all the initSystem overrides that the main core does.

To be precise, it doesn't load any of the auto_loaders or init_includes.

How silly of me to assume that a core Zen Cart script would implement a core Zen Cart feature. :wacko:

Regardless, Josh, the html_output patch you just posted on the bug tracker works like a charm. With the amended modification, I ran two successful tests just now -- one via instant payment, and one via eCheck.

Many thanks to you and to DrByte for your excellent work, the net result of which is a highly effective e-commerce solution.

Kudos!
Sean> dreamscape:

To be precise, it doesn't load any of the auto_loaders or init_includes.

How silly of me to assume that a core Zen Cart script would implement a core Zen Cart feature. :wacko:

dreamscape:

To be precise, it doesn't load any of the auto_loaders or init_includes.

How silly of me to assume that a core Zen Cart script would implement a core Zen Cart feature. :wacko:

The code to rework the ipn subsystem to use the initSystem infrastructure has been "in progress" for a couple weeks now and may be included in the next release if it passes testing in time.

schoolboy:

Could a button - "Cancel -- session abandoned at PayPal stage" - be put into the code (button that appears underneath the "Move to Orders database" button) ?

Anyone willing to comment on this??? See topic above...

For whatever it's worth, I thought the same thing when I looked at my "stuck PayPal orders" records. This mod is useful, but would be even more useful if it could filter out records in which there was no payment.

Alternately (or perhaps additionally), I'd like to see the report clearly identify records with existing orders. These records are listed, but one can't really see at first glance which records already have orders in the database (versus which records do not).> schoolboy:

Anyone willing to comment on this??? See topic above...