Jump to content
Supertex

PayPal Payment Status: Completed vs. Pending - same store order status

Recommended Posts

With PayPal, I think we're missing a step with regard to the store's order status.  The store is assigning "new order" status to orders that PayPal has not yet approved.

 

To be clear - this has nothing to do with the osCommerce order status level of "Pending", but rather a PAYPAL status of 'pending.'

 

I see it under order comments, and there are entries for both order completion by the customer, and for arrival of the IPN.  In most cases this says "Complete," but in some cases shows up as "Pending" (those that show up as "under review" in the PayPal website's account summary, for example). This is later updated via IPN when the payment actually goes through.

 

This has occurred more and more often as business picks up.  Here's a screenshot of exactly what I'm talking about:

 

post-292008-0-56087300-1446069709_thumb.jpg

 

Note the times - payment submitted (customer didnt return to the store, but IPN handled completing the order) at 17:39 on the 21'st...but Payment Status is "Pending."  I read that as payment submitted but not yet approved.  My site applies 

 

Then the next day, the 22nd at 4:36 am, payment approval notification arrives, and Payment Status now shows "Completed."

 

The problem comes in when you have a list of orders in the admin that all appear to be paid orders per the status the store assigns, but one or more of them are apparently hanging in limbo.

 

Is there something that I've missed, that details a way to apply a different status to such orders?

Share this post


Link to post
Share on other sites

Looking at includes/modules/payment/paypal_standard.php, I find this around line 1200:

            $pptx_params = array('txn_id' => $details['TRANSACTIONID'],
                                 'invoice' => $details['INVNUM'],
                                 'custom' => $details['CUSTOM'],
                                 'payment_status' => $details['PAYMENTSTATUS'],
                                 'payer_status' => $details['PAYERSTATUS'],
                                 'mc_gross' => $details['AMT'],
                                 'mc_currency' => $details['CURRENCYCODE'],
                                 'pending_reason' => $details['PENDINGREASON'],
                                 'reason_code' => $details['REASONCODE'],
                                 'address_status' => $details['ADDRESSSTATUS'],
                                 'payment_type' => $details['PAYMENTTYPE']);

is it feasible to make use of $details['PAYMENTSTATUS']... maybe as a global, and then use it as a switch here:

  function before_process() {

      global $order_id, $order, $languages_id, $currencies, $order_totals, $customer_id, $sendto, $billto, $payment;

      $new_order_status = DEFAULT_ORDERS_STATUS_ID;

      if ( OSCOM_APP_PAYPAL_PS_ORDER_STATUS_ID > 0) {
        $new_order_status = OSCOM_APP_PAYPAL_PS_ORDER_STATUS_ID;
      }

      tep_db_query("update " . TABLE_ORDERS . " set orders_status = '" . (int)$new_order_status . "', last_modified = now() where orders_id = '" . (int)$order_id . "'");

      $sql_data_array = array('orders_id' => $order_id,
                              'orders_status_id' => (int)$new_order_status,
                              'date_added' => 'now()',
                              'customer_notified' => (SEND_EMAILS == 'true') ? '1' : '0',
                              'comments' => $order->info['comments']);

      tep_db_perform(TABLE_ORDERS_STATUS_HISTORY, $sql_data_array);

To set only "Completed" (and "Refunded") to OSCOM_APP_PAYPAL_PS_ORDER_STATUS_ID, else set it to the store's 'default' order status?  I'm making the assumption that since standard_ipn.php requires paypal_standard.php, that when the 'completed' IPN lands, the same switch will still apply, and then correctly set the order to OSCOM_APP_PAYPAL_PS_ORDER_STATUS_ID.

 

Way over my head here.

 

@@Bob Terveuren  you saved my bacon with PayPal a few times before.  Would be interested to have your take on this.

Edited by Supertex

Share this post


Link to post
Share on other sites

@@Supertex

 

Shawn I'm seeing duplicates too but I think it is because I'm getting updates from the Payment Data Transfer (PDT) that the APP recommends being set up and then an IPN update..in one of the threads I read Gergely suggested that the correct payment status to use is Preparing [PayPal Standard].  I don't know if that will solve your problem but it might be worth a try.  I use it and don't see your issue but I do have the minor issue noted above.   In say all this I assume you are using the PayPal APP.

 

Dan

Share this post


Link to post
Share on other sites

Hi Dan, and thanks for the reply. 

 

My Problem isn't with the naming of the store's order status levels, or duplicity, but rather that the Paypal app only allows 2 store status levels for an order. As it is now, chances are high, that I've shipped a few orders with nothing more than a virtual "I.O.U."

 

1) Preparing - Customer has chosen shipping methods and PayPal as a payment method, and is sitting on the checkout_confirmation...perhaps they just wanted to determine the final cost for a cart.

2) Processing - Customer has submitted payment and either returned from PayPal or the IPN has come back. ("OK to ship")

 

My issue is that PayPal may or may not have approved the transaction, yet at our store...there is no indication either way.  Both payments that are on hold (as in the case of an e-check), and fully completed payments have the same store order status.  The only way to tell is open the order up and inspect the comments.  While it sounds trivial (if not just plain lazy on my part), when processing 30-50 orders on a Monday...things like that are easily overlooked. Not to mention, the order will slide down the list as new orders come in, making it more difficult to find it and check to see if it's status has been updated.  

 

Just seems like allowing the following conditions would be a big improvement:

 

1)Preparing - same as above

2)Pending - awaiting an update to completed payment status via IPN

3)Processing - O.K. to ship

 

Of course, for most transactions, it would just go straight from 1 -> 3.  But for those few occurrences where the payment is for whatever reason, on hold, it would help prevent shipping out an order that is unpaid.

Share this post


Link to post
Share on other sites

@@Supertex

 

Shawn...in my case I get Preparing [PayPal Standard] until it is paid for and following that it is updated to Pending.  All I can say is try Gergely's suggestion and see what you get. 

 

Dan

Share this post


Link to post
Share on other sites

Right...my 'processing' (which I've named Payment Completed) is the same as your 'pending'.  It's not the verbage that is my concern here.  It's that regardless of which status you assign for "NEW_ORDERS_STATUS" (in your case, "Pending")  the site does not distinguish between what PayPal says IS or IS NOT approved payments.   

 

Here is the most recent example of what I'm talking about:

 

post-292008-0-15957100-1446219608_thumb.jpg

 

I just happened to notice that this order was not actually paid, and set it to a different status manually, to prevent it from being inadvertently shipped before it had actually been paid.

 

The app does not check for this.  It only has 2 assignable statuses - one for pre-payment submission, and one for post-payment submission.  But submission doesn't mean the payment is actually approved.  So we need to be able to assign an intermediate.  Of course assuming it would be desirable for more than just myself, to be able to tell an order is unpaid by looking at the orders list, instead of going into each order and checking each payment.

 

Everything we need to do it is already there.  Paypal sends several discrete variables (one being payment status) that the app combines into a string for entry in the comment.  I'm just not confident enough in my coding to do it.  I've mentioned this to HPDL, but I haven't seen any activity from him since July.

 

If I'm being dense, smack me...I can handle criticism.  But I don't think folks realize what I'm saying here.

 

 

 

 

Share this post


Link to post
Share on other sites

I queried PayPal on something similar to this years ago, but cannot remember exactly what they said. It was something to do with volume of traffic on their site and delays. Usual stuff.

 

On my site when an order is completed by PayPal and the customer returns to the website, or PayPal IPN steps in, I get three rows of information from PayPal, sometimes only two.

 

The first is something to do with the customer getting through to PayPal before any other action is taken and PayPal have received the information from the store. On my store this gets the status called Preparing [PayPal Standard]. I continue to get this status until the order is paid for. If a customer does not complete the transaction it stays at this status level. The order is unpaid and no stock has been deducted.

 

I then get another status update that generally says something that the order has been placed and is called Order Placed. I cannot remember what it was originally.

 

Then finally once the transaction is complete and the customer returns to the store, or PayPal ipn completes the order I get another order status, but in the info box it mentions PayPal IPN Verified [Completed (Verified; £###.##)]. This means that the transaction has been successful and stock levels have been decreased. Sometimes this comes through, but the green tick is missing which means that the order was completed and paid for, but the customer did not return to the store and stock levels will need to be manually deducted.

 

They can come through in any order apparently, but the important one is the last one, that generally generated a green tick in one of the other boxes.I was told by PayPal to not trust the websites generated info, and to always check in my PayPal account to see what has been paid for, and what hasn't. I cannot remember what PayPal standard module it is, but as it works, and is easy to understand I have never updated it. You can also check what has been paid for and what hasn't from the transaction emails sent by PayPal.

 

I always check my PayPal pages before sending any products out to customers, even if they but through other channels.


REMEMBER BACKUP, BACKUP AND BACKUP

Get the latest Responsive osCommerce CE (community edition) here

It's very easy to over complicate what are simple things in life

Share this post


Link to post
Share on other sites

@@Supertex

 

Shawn...maybe I'm reading to much into Gergelys post here.

 

http://forums.oscommerce.com/topic/398887-paypal-app-for-oscommerce-online-merchant/?p=1733586

 

I guess what I was wondering is if you've caused the problem by not using the Preparing [PayPal Standard] status?  I use it and don't see any messages until it is paid.  Maybe I'm just lucky..I don't know.

 

See also Garys post here..

 

http://forums.oscommerce.com/topic/397899-mobile-devices-paypal-standard-buyer-being-returned-to-shopping-cart-after-purchase/?p=1735174

 

Perhaps you're trying to fix a problem that doesn't exist if the module is set up properly.

 

Dan

Share this post


Link to post
Share on other sites

Hi Steve,

 

I have chosen to hide all orders with the "preparing" status (I've renamed this to "Temp" status).  It actually occurs when the customer selects paypal as the payment option, and clicks to continue on to checkout_confirmation.  So that status occurs before the customer ever even leaves your site.  I -believe- it's unique to paypal orders, and its purpose is to establish an order number that can be compared to what is returned from paypal.  I know that this status does not occur with authorize.net, money order, wire transfer, etc.

 

Your "Order Placed" is the same as my "Payment Completed" (originally, I believe this was "Processing").  Indeed, this means the customer actually went to paypal, and submitted a payment.

 

From here, IF the customer returns, and they do so before the IPN lands, you should see an 'internal status' of PayPal [Transactions]  with the info string from PayPal.  At this point, stock is decremented, the customer's cart is cleared, and the order status gets changed to your "Order Placed."  OR if the customer does not return to your store, then the exact same thing occurs, but is initiated instead when the IPN lands.  In this case, you will see "source: IPN" at the end of the info string. Incidentally, I've also had both the customer return and the IPN hit at the exact same moment, and BOTH ran the order completion process, ending up with a double stock decrement...but that's a discussion for another time.

 

The green tick just indicates whether or not the customer was emailed concerning the status change, which of course depends in part (I think) on whether or not the new status is visible to the customer, as set in Localization->Orders Status -> "Show the order to the customer at this order status level"

 

 

 

I was told by PayPal to not trust the websites generated info, and to always check in my PayPal account to see what has been paid for, and what hasn't. I cannot remember what PayPal standard module it is, but as it works, and is easy to understand I have never updated it. You can also check what has been paid for and what hasn't from the transaction emails sent by PayPal.

 

This is my point.  The site cannot be trusted to show us if payment actually went through.  It can only show us that a customer requested that paypal submit payment to us.

 

However, it could...and I'd venture to say it 'easily' could, as the information needed to act as the switch is sent on EVERY communication from paypal, including IPNs.

 

If someone can tell me how to extract the content of 'payment_status' => $details['PAYMENTSTATUS'], from its containing array, I believe it would be a simple matter to use it in a switch that determines whether to apply your "Order Placed" status, or a new intermediate status - one that says payment was submitted, but is under review...on hold...whatever.  The benefit being that it would be visible in the orders list, and be distinguishable from orders where we've got full approval on the payment.  It could also be made visible to the customer, so they understand why their order isn't being shipped.

 

I agree that one solution is to monitor email and/or paypal account.  However, it's not uncommon on a Monday, to come into the shop and have 50 orders that I have to pack and ship by 3pm.  When you combine this with phone calls, email support, etc., etc., it makes for a hectic day that can easily result in missing the fact that one of the orders (lets hope it's not a $1k order) was lingering unapproved in paypal, and was mistakenly shipped out.

 

What I'm suggesting avoids this scenario entirely, because as soon as you would see "OK to ship" in your paypal account, an IPN is dispatched (sometimes days later, as in the order in my last post) and lands on the site containing the go code - "Order Status: Complete" ...which would then change the store order status from the (new) intermediate status to "Order Placed"...which you would see in the order list.

Share this post


Link to post
Share on other sites

@@Dan Cole

 

I actually do use preparing.  I just hid it from the orders list and individual orders, because I had so many orders that were never completed, it became an annoyance...I have lots of window shoppers.

 

I'll read both of the threads you've listed carefully.  

 

I may end up with egg on my face, but hell, it wouldn't be the first time, and if it solves a the problem, I'd be happy enough not to care.  

 

However, I don't think that's the case here.  I think this is something that people are missing, and 14Steve14's alluded to the same thing in the statement about checking paypal and emails as the final word in payment completion.

Share this post


Link to post
Share on other sites

@@Supertex

 

Shawn...this relates more to my issue (duplicate notifications) than to yours but it explains the difference between the PDT and IPN notification methods used by PayPal. 

 

https://developer.paypal.com/docs/classic/ipn/integration-guide/IPNPDTAnAlternativetoIPN/

 

Looks like there is only one notification sent when using PDT and multiple notices when using IPN.  I'm getting notices from both so that explains my duplicate issue.  I'm thinking I should turn off the PDT notices since they seem to be less reliable than the IPN method and probably most suited to those using digital downloads.   What are you using in that respect...I assume you have both set?

 

Dan

Share this post


Link to post
Share on other sites

I will go back and check.  In that second thread that you linked...the one you mentioned Gary in, actually details my useage of PDT pretty closely.  Bob had found a PDT fix for mobile devices, prior to the release of the paypal app.  HPDL had me turn it off to test things when he released the app...then figured out that there was a GET vs. POST issue and determined to update the app to fix it...which he eventually did.  Currently, I do have a PDT Identity Token in place in the app, and I'll double check on whether or not I have PDT turned on in PayPal, but I -think- I do have it on.  I do not, however, have any duplicate notices - save for when the customer returns and then the IPN lands.

 

Could you post an image of what you're seeing?  ...not that I can be of much help, but if I can, I will.

Share this post


Link to post
Share on other sites

Could you post an image of what you're seeing?  ...not that I can be of much help, but if I can, I will.

 

@@Supertex  Here you go Shawn....I'm really not looking for help I just need to decide if I should get rid of the PDT notice.  I only set it up because of the recommendation in the APP manual.  It seems that is most suited sites selling digital downloads that need quick responses from Paypal.  Not sure why it's a general recommendation within the APP documentation but since it is I'm just wanting to research it a bit more before I nix it.  I also seem to recall seeing a PayPal notice about upcoming changes to their IPN system which I want to refresh my memory on before I go ahead and step in something I shouldn't.  In any case here is what I see when I get a PayPal order.

 

post-182953-0-29942200-1446261238_thumb.jpg

 

Dan

Edited by Dan Cole

Share this post


Link to post
Share on other sites

That's the same thing I usually see.  First one is the customer return, and the second is the IPN.  

 

Occasionally, if the customer does not return, all I will see is the IPN.  I won't pretend to know anything about PDT.  However, it seems like I had to enable that around the time I installed the app, due to issues with mobile devices, so I'll make the assumption that it had been off up until then (I could be wrong...slept since then).  But in most cases, my orders have always had both entries. 

 

I guess I should look over the documentation too.

Share this post


Link to post
Share on other sites

Without PDT setup the mobile device return goes on shopping_cart.php without cart delete.


:blink:
osCommerce based shop owner with minimal design and focused on background works. When the less is more.
Email managment with tracking pixel, package managment for shipping, stock management, warehouse managment with bar code reader, parcel shops management on 3000 pickup points without local store.

Share this post


Link to post
Share on other sites

@@Gergely

 

Without PDT setup the mobile device return goes on shopping_cart.php without cart delete.

 

Thanks Gergely....you saved me from stepping in it.  Just out of curiosity is there some reason the mobile device is returned to a different URL?

 

Dan

Share this post


Link to post
Share on other sites

API comunication ensure the safety data transfer on mobile devices with PDT. If comunication is false then oscommerce is runing bad way.

Edited by Gergely

:blink:
osCommerce based shop owner with minimal design and focused on background works. When the less is more.
Email managment with tracking pixel, package managment for shipping, stock management, warehouse managment with bar code reader, parcel shops management on 3000 pickup points without local store.

Share this post


Link to post
Share on other sites

@@Gergely

 

API comunication ensure the safety data transfer on mobile devices with PDT. If comunication is false then oscommerce is runing bad way.

 

I'm not sure why we'd be concerned with data transfer issues on a mobile device when communicating back to the shop via PDT but I acknowledge that you know a lot more about this then I and will simply take your advice and leave the PDT settings in place.  Thanks Gergely.

 

Dan

Share this post


Link to post
Share on other sites

I know this is an old thread, but I don't have as much experience with Paypal.  Do you have IPN and PDT enabled?  I was having failed transactions sometimes and now I'm getting duplicate transactions with duplicate payments.  Should I enable PDT too?  I'm using Paypla Standard.


I'm not really a dog.

Share this post


Link to post
Share on other sites

John I use Paypal standard and have both IPN and PDT enabled?  I'm no expert on configuring Paypal but I've been using it like that for years without issue.

Dan

Share this post


Link to post
Share on other sites

Thanks Dan, I'll try it that way and see if it solves it.  My customer base likes using Paypal, but it's been problematic at times for me.


I'm not really a dog.

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

×