Jump to content

paid with paypal no order in bo

ScooterShop

By ScooterShop
in PayPal

 Share

Recommended Posts

Guest

Guest

Posted
Posted

Just had this email from PayPal

Please check your server that handles PayPal Instant Payment Notifications (IPN). Instant Payment Notifications sent to the following URL(s) are failing:

 

http://www.graphskill.co.uk/modules/paypal/ipn.php

http://www.u-bolts-r-us.co.uk/modules/paypal/ipn.php

http://www.shackles-r-us.co.uk/modules/paypal/ipn.php

 

If you do not recognize this URL, you may be using a service provider that is using IPN on your behalf. Please contact your service provider with the above information. If this problem continues, IPNs may be disabled for your account.

 

Thank you for your prompt attention to this issue.

 

 

No ideas what it means except the guess that they have issues at the moment as we have not changed anything

Link to comment
Share on other sites
Guest

Guest

Posted
Posted

Linked to this on their blog perhaps?

logo.jpg Live Site Status Update Notification: We are experiencing a system issue which may be affecting PayPal Developer site. Please see the details below. 

Developers may encounter the following error when accessing the ‘Applications’ tab in the Developer site:
We’re sorry, but something went wrong. Please try again. 

Our technical teams have been engaged and are actively troubleshooting the issue. 


Sent Oct 14, 2014 08:40 AM BST by FJE Start time: Oct 14, 2014 07:16 AM BST At this time, there is no alternative work-around.

 

Questions? Please contact PayPal Merchant Technical Services by filing a ticket; refer to PP-LIVE-5775 Live Site Status blog | Contact PayPal Merchant Technical Services | Subscribe| Unsubscribe

 

 
Link to comment
Share on other sites
ScooterShop Newbie

ScooterShop

Posted
  • Author
Posted
For what we pay commissions should have a service of gold. Instead we nenache not properly informed about what's happening !!! 

Phoning: no there is no problem, everything works properly, and have no complaints !!!! 

it may be the fear that culminates in waal street !!! and do not want to know about the problems? lol

  • Like 1
Link to comment
Share on other sites
karbon74 Newbie

karbon74

Posted
Posted (edited)

Hello everyone same probleme since yesterday.

In Apache logs i see these errors :

PHP message: PHP Notice:  Trying to get property of non-object in /XXXXXX/modules/paypal/ipn.php on line 86
PHP message: PHP Notice:  Trying to get property of non-object in /XXXXXX/modules/paypal/ipn.php on line 88
PHP message: PHP Notice:  Trying to get property of non-object in XXXXXX/modules/paypal/ipn.php on line 89
PHP message: PHP Notice:  Trying to get property of non-object in /XXXXXX/modules/paypal/ipn.php on line 90
PHP message: PHP Fatal error:  Call to a member function getSummaryDetails() on a non-object in /XXXXXX/modules/paypal/ipn.php on line 156

I think the probleme is at line 79-84 :
 

$id_order = (int)PayPalOrder::getIdOrderByTransactionId($txn_id);
		
if ($id_order != 0)
	Context::getContext()->cart = new Cart((int)$id_order);
elseif (isset($custom['id_cart']))
	Context::getContext()->cart = new Cart((int)$custom['id_cart']);

The Context::getContext()->cart is empty

Edited by karbon74 (see edit history)
Link to comment
Share on other sites
odenmc Newbie

odenmc

Posted
Posted

 

prestashop what he is doing? . 
then I do not understand why it should be a problem prestashop. if I have not touched anything. How interaggisce prestashop on my server ??? that causes this error ?? 
confused!

 

I have not touched anything, so no sense. Looks like Paypal is trying to avoid blame.

Link to comment
Share on other sites
Guest

Guest

Posted
Posted

If you can see the payment in PayPal, then have a look in your Prestashop back office at abandoned carts. You will be able to match up the orders with the payment. Then in the abandoned cart you can click to create the order

 

A nuisance, but at least we can keep working

Link to comment
Share on other sites
ScooterShop Newbie

ScooterShop

Posted
  • Author
Posted

If you can see the payment in PayPal, then have a look in your Prestashop back office at abandoned carts. You will be able to match up the orders with the payment. Then in the abandoned cart you can click to create the order

 

A nuisance, but at least we can keep working

 

since yesterday I do so. :)

Link to comment
Share on other sites
kdn77s13 Newbie

kdn77s13

Posted
Posted

I got Paypal on the phone this morning and they said that the problem is coming from Prestashop (for Paypal Integral Evolution users). You can use Paypal Integral in the mean time until they fix the problem. I will let you know if any update.

Link to comment
Share on other sites
alerax Rookie

alerax

Posted
Posted

If you can see the payment in PayPal, then have a look in your Prestashop back office at abandoned carts. You will be able to match up the orders with the payment. Then in the abandoned cart you can click to create the order

 

A nuisance, but at least we can keep working

 

Not always, some i found but it looks that there are some orders payed and no chart for these....

Link to comment
Share on other sites
Luca S. Newbie

Luca S.

Posted
Posted (edited)

Hey Guys! 

Same problem here!

 

Last order received correctly and registered in our BO is yesterday at this time: 13/10/2014 11:15:40 (Italy timezone)

 

After this time we started to get only payments and no one registered order into the BO, all the day long. We didn't applied any mods to PS, neither new module installation or server updates that maybe could have caused this error.

 

Today still receiving payments but no one of our orders has been registered into backoffice.

 

I've also contacted Paypal support and they told me that on Paypal-side everything it's ok. But i dont think so!

 

How could be happened if we didn't do nothing? Mystery...

Edited by Luca S. (see edit history)
Link to comment
Share on other sites
Nothingbuttea Newbie

Nothingbuttea

Posted
Posted

I am getting the same problem too. Paypal have also told me it is a server/database issue. I've checked the server (and had someone else check it) and have made no changes.

 

What is paypal integral/integral evolution?

 

I am using paypal pro?

 

Does switching the module so that the payment page goes direct to paypal site rather than in the iframe make a difference?

Link to comment
Share on other sites
jruspante Newbie

jruspante

Posted
Posted

I am getting the same problem too. Paypal have also told me it is a server/database issue. I've checked the server (and had someone else check it) and have made no changes.

 

What is paypal integral/integral evolution?

 

I am using paypal pro?

 

Does switching the module so that the payment page goes direct to paypal site rather than in the iframe make a difference?

We use PayPal PRO, too. We have now switched to PayPal (NOT PRO) and it begins to work.  The problem seems to be in PayPal Pro only

Link to comment
Share on other sites
OllyL Newbie

OllyL

Posted
Posted

Hi all,

 

Just to say that we're also experiencing this. Problem began at approx 10:00am GMT on 13/10/2014 and is affecting the Paypal Payments Pro Hosted configuration of the paypal 3.7.2 payments module. The Express Checkout configuration is still working okay.

 

Payments are correctly processed through paypal and the callback url is registering 200 OK at PayPal's end but clearly there is an issue in the ipn.php script and orders are not being created in the backend.

 

I've been on the phone with PayPal for an hour this morning and they claim that the problem is with Prestashop although there have been zero changes to our configuration so I find that hard to believe. Either way, if someone finds a solution please let me know.

 

Regards,

 

Olly Lennox

Link to comment
Share on other sites
Guest

Guest

Posted
Posted

 

Hi,

 

Same problem in 2 webs, this say Paypal to me after of persist, It is translated from Spanish sorry if you do not understand all that well:

 

In general (99% of cases) the problem of an http 500 error means or script that manages the IPN does not recognize the information you are sending. Checking account information, variables that your car and sends IPN that we send, I see that the origin is in the variable "custom". 
 
 

But nothing has changed in Prestashop. So PayPal must have changed something for this to be an issue

Link to comment
Share on other sites
ScooterShop Newbie

ScooterShop

Posted
  • Author
Posted

From Paypal ....

 

Gentile Umberto,

Grazie per le informazioni inviate.

Ti devo informare che siamo consapevoli di questo problema e stiamo lavorando per risolverlo.

I nostri tecnici informatici sono all'opera per risolvere quanto prima.

Non ho il dettaglio aggiornato di quando questo problema verrà risolto, tuttavia ho inserito l'ID del tuo ticket nella lista degli account affetti da tale problema. Riceverai ulteriori aggiornamenti non appena riceveremo maggiori informazioni dai nostri ingegneri.

Non esitare a contattarci prima se dovessi avere dubbi, domande o altri tipi di problemi.

Grazie per il tuo tempo e la tua pazienza.

Cordiali Saluti,
An******
PayPal MTS

Link to comment
Share on other sites
alerax Rookie

alerax

Posted
Posted

My Italian is a bit ropey but I guess this means that they are acknowledging the problem is at their end?

 

Yes,

also i have spoked with them now...... he said now they know the problem is from paypal side because many are calling, they are working on it, maybe have to update paypal module in prestashop.

Link to comment
Share on other sites
bellini13 Newbie

bellini13

Posted
Posted (edited)

I was helping a client the other day and we couldn't figure out why Paypal was no longer sending the IPN to their store.  When we looked in the Paypal profile, we noticed that IPN was turned off.  This is a typical setting, and it is not required to be turned on for the IPN to be sent.

 

When we turned IPN on we could see in the IPN history that the IPNs were in a 'disable' state.  And Paypal would not send the IPN unless we enabled IPN.  This is not how IPN's are designed to work, according to the Paypal developer documentation.

 

So we left IPN enabled, assuming that Paypal had changed something recently.  And based on this thread, I believe it is now confirmed.

 

Again, this is not standard and I suspect Paypal will conclude that they recently changed something which broke this functionality.  So once that happens, you can and should disable IPN in your profile to avoid having 2 IPN's sent for each payment.

Edited by bellini13 (see edit history)
  • Like 1
Link to comment
Share on other sites
Guest

Guest

Posted
Posted (edited)

I was helping a client the other day and we couldn't figure out why Paypal was no longer sending the IPN to their store.  When we looked in the Paypal profile, we noticed that IPN was turned off.  This is a typical setting, and it is not required to be turned on for the IPN to be sent.

 

When we turned IPN on we could see in the IPN history that the IPNs were in a 'disable' state.  And Paypal would not send the IPN unless we enabled IPN.  This is not how IPN's are designed to work, according to the Paypal developer documentation.

 

So we left IPN enabled, assuming that Paypal had changed something recently.  And based on this thread, I believe it is now confirmed.

 

Again, this is not standard and I suspect Paypal will conclude that they recently changed something which broke this functionality.  So once that happens, you can and should disable IPN in your profile to avoid having 2 IPN's sent for each payment.

Any clues on what the notification URL would be?

 

post-246958-0-27973200-1413286905_thumb.jpg

Edited by Guest (see edit history)
Link to comment
Share on other sites
bellini13 Newbie

bellini13

Posted
Posted (edited)

guys, you should actually read my post.  It states what to use and why...  Do NOT put a link to the paypal module in the Notify URL, you will end up with duplicate orders, because you will receive 2 IPNs

 

It is just a hack to get Paypal to send the IPN to the URL the Paypal module tells it to.  So when doing this, you will receive 2 IPNs

1) The real IPN will go to the module, based on what the module tells it to use.  Each module is different and the final URL will depend on several things (PS version, module version, friendly url etc...)

 

2) A fake IPN will go to your main domain and is effectively ignored.

 

The key here is to get Paypal to send you the IPN by enabling IPN in your paypal profile.  Again, this is not normally required, but because Paypal have made some update, it appears to now be required.

 

For those of you that have contacted Paypal support, and they actually acknowledged the issue, please provide an update

Edited by bellini13 (see edit history)
Link to comment
Share on other sites
OllyL Newbie

OllyL

Posted
Posted

Also, from Paypal:

 

Once the IPN is sent, and we get 200OK, it means the server received it, so we don't retry anymore. Prestashop is the one that is not creating the orders. Today I got a ticket on an IPN issue in which they were not passing the "custom" parameter in the URL.

I checked the parameters that our IPNs server is sending to yours, and I figured out the following:


mc_gross=-7.50 &invoice=3_1413276939 &protection_eligibility=Ineligible &payer_id=RVLTYL
UVXT4BQ &address_street=16 Pete Close &payment_date=03:33:25 Oct 14, 2014 PDT &paymen
t_status=Refunded &charset=windows-1252 &address_zip=DE20 2DG &first_name=Olly &mc_f
ee=-0.08 &address_country_code=GB &address_name=Olly Lennox ¬ify_version=3.8 &rea
son_code=refund &custom= &[email protected] &address_country=United Kingd
om &address_city=Derby &verify_sign=AGK4KeaxA8sCyr3YNVdsNgpMiP2AAINXxCBe0PDABRsLNFiBAsDe47V4
&[email protected] &parent_txn_id=2VP07943558145213 &txn_id=08R79754FD223
0249 &payment_type=instant &last_name=Lennox &address_state=XX &receiver_email=shop@hotmail.co.uk &payment_fee= &receiver_id=2DCFMMRXS987W &item_name= &mc_currency
=GBP &item_number= &residence_country=GB &receipt_id=4179-9903-8001-8263 &handling_a
mount=0.00 &transaction_subject= &payment_gross= &shipping=3.00 &ipn_track_id=49604a

 

(OL: I have changed some of the details to post this in the forum)

As you see the custom parameter is empty. May be prestashop is using that parameter to build your orders.
This was post as a ticket to our development team, so they are working on that to fix it asap.
I'm sure prestashop builds the order based on information from that parameter.

Tell Prestashop about this issue. It should be solved soon, but they should also handle this too, at least by returning an error.

Regards

PayPal MTS

Link to comment
Share on other sites
Broceliande Newbie

Broceliande

Posted
Posted (edited)

Hi folks,

 

It really seems that paypal added some restrictions either on the field length, or its type.

So for a customer i made this to make it work : 

 

 

in paypal.php i made the smarty assign a bit diffrent around line 524 , with no fields name nor json_encode.

only the cart_id and the shasign , just split by a double "|"

'custom' => $cart->id."||".sha1(serialize($cart->nbProducts())),

Then i modified ipn.php to rebuild them as they are used anywhere else in the code.

 

arround line 248 my whole code look like this : 

if (Tools::getIsset('custom'))
{
$custget = explode("||",Tools::getValue('custom'));
$custom = array('id_cart'=>$custget[0],'hash'=>$custget[1]);
$ipn = new PayPalIPN();
$ipn->confirmOrder($custom);
}

i had to modify around line 159 this way as well : 

		$custget = explode("||",Tools::getValue('custom'));
		$custom = array('id_cart'=>$custget[0],'hash'=>$custget[1]);

I dont find this workaround really pretty , at least it works and isn't that worst than the existing code...

Edited by Broceliande (see edit history)
  • Like 5
Link to comment
Share on other sites
alaciga Newbie

alaciga

Posted
Posted

Hello all,

 

Switching to Integral from Integral Evolution does work.

 

However, following is a copy (French) of the tech support after my inquiry: 

 

Merci d'avoir contacté le Support Technique pour Commerçants de PayPal.

 

Avant toute chose, il est important de comprendre que, même si le module utilisé s'appelle "module PayPal", puisque basé sur notre technologie, il est entièrement développé et customisé par l'équipe de Prestashop ce qui nous empêche d'en connaître le fonctionnement exacte et ainsi de pouvoir effectuer un support dessus.

 

Le problème rencontré vient en parti de chez nous :

- Lors du paiement PayPal Intégral Evolution nous "ignorons" la valeur de la variable "custom" envoyée par votre site à la page de paiement PayPal.

- Du coup, au moment de l'IPN, nous envoyons "custom=" sans aucune valeur à votre script ce qui le fait planter.

 

Nous poursuivons les recherches et je reviens vers vous dès que j'ai plus d'informations.

 

 

Pierre, waiting for this issue to be solved  B)

Link to comment
Share on other sites
afshop Rookie

afshop

Posted
Posted

Hi folks,

 

It really seems that paypal added some restrictions either on the field length, or its type.

So for a customer i made this to make it work : 

 

 

in paypal.php i made the smarty assign a bit diffrent around line 524 , with no fields name nor json_encode.

only the cart_id and the shasign , just split by a double "|"

'custom' => $cart->id."||".sha1(serialize($cart->nbProducts())),

Then i modified ipn.php to rebuild them as they are used anywhere else in the code.

 

arround line 248 my whole code look like this : 

if (Tools::getIsset('custom'))
{
$custget = explode("||",Tools::getValue('custom'));
$custom = array('id_cart'=>$custget[0],'hash'=>$custget[1]);
$ipn = new PayPalIPN();
$ipn->confirmOrder($custom);
}

i had to modify around line 159 this way as well : 

		$custget = explode("||",Tools::getValue('custom'));
		$custom = array('id_cart'=>$custget[0],'hash'=>$custget[1]);

I dont find this workaround really pretty , at least it works and isn't that worst than the existing code...

 

Great!! Your solution Works!!!

Thanks

Link to comment
Share on other sites
Broceliande Newbie

Broceliande

Posted
Posted

Hi everyone,

 

Yesterday, PayPal modified their API and they now send invalid data on IPNs. Xavier wrote a post about this bug here: http://bit.ly/ZY304B.

 

Have a great day!

 

Hi, thanks for the info , but Xavier also tells

"Do not modify anything in the software, the issue isn't in PrestaShop's code."

 

 

And as well : 

 

 

 

PayPal modified their API and they now send invalid data on IPNs

 

What's real in these is that paypal indeed modified something in some post handling.

It doesn't send invalid data but no data for a variable the module uses to identify the cart to validate and get a signature.

 

Technically , it is possible to keep HSS working without loosing the cart_id nor the signature, just by changing the way to send this needed variable and make it smaller and cleaner, so that paypal send it back to ipn...the workaround i described doesn't alter the module's security at all. The same variables are visible in the form in both native  modified code.

 

I can't quite understand why you remind Xavier's post right now , while number of customers do want to keep HSS on :s .

What's wrong if there a way , to share it?

Link to comment
Share on other sites
Luca S. Newbie

Luca S.

Posted
Posted

Hi folks,

 

It really seems that paypal added some restrictions either on the field length, or its type.

So for a customer i made this to make it work : 

 

 

in paypal.php i made the smarty assign a bit diffrent around line 524 , with no fields name nor json_encode.

only the cart_id and the shasign , just split by a double "|"

'custom' => $cart->id."||".sha1(serialize($cart->nbProducts())),

Then i modified ipn.php to rebuild them as they are used anywhere else in the code.

 

arround line 248 my whole code look like this : 

if (Tools::getIsset('custom'))
{
$custget = explode("||",Tools::getValue('custom'));
$custom = array('id_cart'=>$custget[0],'hash'=>$custget[1]);
$ipn = new PayPalIPN();
$ipn->confirmOrder($custom);
}

i had to modify around line 159 this way as well : 

		$custget = explode("||",Tools::getValue('custom'));
		$custom = array('id_cart'=>$custget[0],'hash'=>$custget[1]);

I dont find this workaround really pretty , at least it works and isn't that worst than the existing code...

 

It works!!!

Link to comment
Share on other sites
Luca S. Newbie

Luca S.

Posted
Posted (edited)

Hello guys,

i received this mail from Paypal Merchant Support, here their reply about that bug (it was written in Italian, i translated with Google)

 

 

Hi, 

 
I have to inform you that we have had other reports of this problem and are working to resolve it. 
 
We have identified the cause and our technicians are working to resolve as soon as possible. 
 
I have not updated the details of when this issue will be resolved, however, I entered the ID of your ticket in the list of accounts affected by this problem. You will receive further updates as soon as we receive more information from our engineers. 
 
Do not hesitate to contact us first if I have doubts, questions or other types of problems. 
 
Thank you for your time and your patience. 
 
Best regards, 
Antonio 
PayPal MTS
Edited by Luca S. (see edit history)
Link to comment
Share on other sites
Eolia Grand Master

Eolia

Posted
Posted
Once again the community is faster than Team.

But ... If a solution (temporary that does not prevent the code from running)  is provided, forthwith, the same Team, warns you.

 

Broceliande is a recognized and competent coder on this forum, I find it appalling the  Xavier's response.

Link to comment
Share on other sites
OllyL Newbie

OllyL

Posted
Posted

Personally with the clients we have I don't like to do too much modification of the core code files so if we can resolve this problem at PayPal's end or inside the PayPal module then it is preferable for me.

 

We've already suffered enough downtime because of this issue and no disprect to anyone in the community and i really appreciate the work you're doing but personally I don't want to risk more downtime by performing a custom hack which goes on to break something further on down the line in a later patch .

Link to comment
Share on other sites
Eolia Grand Master

Eolia

Posted
Posted

Personally with the clients we have I don't like to do too much modification of the core code files so if we can resolve this problem at PayPal's end or inside the PayPal module then it is preferable for me.

 

We've already suffered enough downtime because of this issue and no disprect to anyone in the community and i really appreciate the work you're doing but personally I don't want to risk more downtime by performing a custom hack which goes on to break something further on down the line in a later patch .

Yes ! no sale is better, is not it?
 
You can make a backup before changing 3 lines in the module.
 
The proposed solution allows you to avoid losing your orders, nothing else
 
Have a nice week !
  • Like 2
Link to comment
Share on other sites
Broceliande Newbie

Broceliande

Posted
Posted

Personally with the clients we have I don't like to do too much modification of the core code files so if we can resolve this problem at PayPal's end or inside the PayPal module then it is preferable for me.

 

We've already suffered enough downtime because of this issue and no disprect to anyone in the community and i really appreciate the work you're doing but personally I don't want to risk more downtime by performing a custom hack which goes on to break something further on down the line in a later patch .

 

Well this is up to you indeed, and up to your customers... 

Mine (some of mine at least... using HSS) didn't want to loose the payment guarantee , so i had to find a solution for them.

The code i gave wich you call "hack", will still work after the announced "rollback" Xavier talks about. 

I did not post it there to hear why some or some others won't use it , but only for those who need it and do want it.

 

Do i have to tell more ?

  • Like 3
Link to comment
Share on other sites
Luca S. Newbie

Luca S.

Posted
Posted

Personally with the clients we have I don't like to do too much modification of the core code files so if we can resolve this problem at PayPal's end or inside the PayPal module then it is preferable for me.

 

We've already suffered enough downtime because of this issue and no disprect to anyone in the community and i really appreciate the work you're doing but personally I don't want to risk more downtime by performing a custom hack which goes on to break something further on down the line in a later patch .

 

you may be able to create the order manually, just selecting the customer and check the presence of a "carts" of the same amount of the payment on Paypal. We solved in this way, furthermore, you can adopt the fix of the guy thas has posted a temporary solution for the paypal module.

Link to comment
Share on other sites
The2smokers Newbie

The2smokers

Posted
Posted

Dear all,
There are many hours that we have business impact. But not exhaustive answers arrive from Paypal. They don't tell when the problem will be resolved.
I think the service that are providing is not adequate to our business impact. I suggest to all to open support request and require, as already I made, with h24 activity and update every 4 hours. The union of us could speed up the solution.

This is the link to require support.

 

https://ppmts-it.custhelp.com/app/ask/session/L3RpbWUvMTQxMzI3MjE3OC9zaWQvQVJDdGpRNG0%3D

Link to comment
Share on other sites
Broceliande Newbie

Broceliande

Posted
Posted

Dear all,

There are many hours that we have business impact. But not exhaustive answers arrive from Paypal. They don't tell when the problem will be resolved.

I think the service that are providing is not adequate to our business impact. I suggest to all to open support request and require, as already I made, with h24 activity and update every 4 hours. The union of us could speed up the solution.

This is the link to require support.

 

https://ppmts-it.custhelp.com/app/ask/session/L3RpbWUvMTQxMzI3MjE3OC9zaWQvQVJDdGpRNG0%3D

 

Hmm ... Not sure that flooding Paypal tech support will speed up things or help.

 

What if you had a technical problem on your website or logistic or so ?

Would you be able to answer all you customers if they start such flood ?

I do think you just would stop answering any call or mail as any human would , and start focus on the trouble you have in order to solve it and please your customers again.

 

Plus , if you have a look in previous posts in this topic you'll see that Paypal already tried to answered publically to this unwanted behaviour.

You may also could consider that the Prestashop module could also have been updated to work with new paypal restrictions. In this case one click in your modules tab (in BO) to upgrade the module and keep working as usual would have been possible.

 

I won't blame the module's developers cause they made the module following technical specifications given by paypal.

However i wonder who has to follow who's directives in this case.

 

Paypal is used by a lot of different e-commerce softwares. I'd like to hear about other plateforms : do they encountered the same issue?  

This would help to make us an objective opinion : Who should react first ?  Paypal , Prestashop , the module's maintainer agency ?

 

IMHO every of them should have reacted as fast as possible.

It was possible to make paypal HSS work on Prestashop as soon as this morning by a very few changes in the module itself, with no use to rollback those changes after Paypal's own rollback, cause the ipn failure is only due to a too long variable sent to paypal and then ignored (indeed this is new, since it wasn't rejected b4).

It is possible to send the same data we need to paypal an get it back in ipn without reinvent the weel. I posted a sample of it myself.

There are other ways, but in anyway, that was easy to do it, quickly and safely... (it took me at least 3 times less than answering to those posts in this topic ;) )

  • Like 1
Link to comment
Share on other sites
OllyL Newbie

OllyL

Posted
Posted

For those who don't know, the Express Checkout functionality is still working correctly and we switched our shop over to this earlier today once the problems were reported. Sorry, I mentioned this is in a previous post but I guess this thread has grown so long now that it got lost.

 

For those who are affected, I would recommend using the Express Checkout until the problems are fixed no code changes are necessary and it still means customers can use the store.

 

Cheers,

Link to comment
Share on other sites
Antonino - Uebix.com Newbie

Antonino - Uebix.com

Posted
Posted (edited)

After my investigations the problem is related to the "custom" field that the module send to paypal.

 

 

The field "custom" is a pass-through field that paypal send back to the caller, but when paypal call ipn.php after payment the "custom" is empty so the paypal module is unable to complete and create order from cart.

 

The official post say to change anything and wait paypal because is a paypal problem:

 

http://www.prestashop.com/forums/topic/369290-important-bug-with-paypal-int%C3%A9gral-evolution-no-order-in-bo/

Edited by Uebix.com (see edit history)
Link to comment
Share on other sites
Xavier du Tertre Newbie

Xavier du Tertre

Posted
Posted

Hi,

 

Thank you to the Community for working together on this issue. Thank you Broceliande for offering a fix to the PayPal module. We can't possibly condone the use of that fix (regardless of how well it works) but we do appreciate the effort and your reactivity :)

 

Why don't we condone this fix? Multiple reasons, among which:

 

- PayPal took action to fix their mistake and requested that the process be followed. When a partner like PayPal takes action to fix something, you don't overstep their decision. We trust PayPal and they confirmed the date for the rollback.

 

- Broceliande is a highly proficient developer on PrestaShop. Out of the thousands of store owners affected by the PayPal bug, you won't find 10 people who can code better than Broceliande. And probably less than 1% of all these store owners know how to use Broceliande's fix for their PayPal module.

 

- Merging Broceliande's fix in the PayPal module and release a new version of the module today? Yesterday? Even the most minor releases need large scale testing, releasing a new version for the module to tens of thousands of merchants without extended tests would be reckless.

 

All in all, your vision of the situation as developers of the Community is understandable (and your action praiseworthy), but you must not forget that PrestaShop is now used by 200,000 online stores and that this type of process doesn't just involve yourself, it does tens of thousands of businesses.

 

Thank you.

  • Like 1
Link to comment
Share on other sites
Eolia Grand Master

Eolia

Posted
Posted
A little humility? 

Prestashop often (especially lately) posted updates to correct them one week later, given the feedback from the community...

Is this a good test method to debug ? 

 

Prior to scare everybody, look at the code change. 

Today the custom variable returns nothing. 

The code changes (minimal) allows a non-empty return of this variable, this is rather positive, right?

 

Have a nice day :)

  • Like 1
Link to comment
Share on other sites
Broceliande Newbie

Broceliande

Posted
Posted

 

-  Even the most minor releases need large scale testing, releasing a new version for the module to tens of thousands of merchants without extended tests would be reckless.

 

Hi Xavier,

 

I'm sure you know that i don't ignore that at all and really care about it.

Indeed large scale testing is needed before any release.

Also you know we (community, contributors) would be the first to blame hasardous releases :D ...

 

First of all i'd like to tell (again) that i did post this fix for thone (only) who were really waiting for an immediate solution.

3 of my own customers just could not not wait till thursday and use standard mode instead.

For this reason i had to find them a way to keep HSS working.

(Some customers are more exposed to fraud than others...dependind on what they sale...)

 

I didn't expect once this fix would be merged in github, especially 'as it' (i mentioned i didn't find its code really pretty. i don't find the native prettier one on the concerned part however).

I just posted it because someone on irc asked me to do so, and cause if some of my customers couldn't wait using the temporary solution given, this can be the case of many others so. Notice that i didn't joined any patched archive or php files to my post, so that only aware service providers can use it if needed.

 

But if we had to technically speak about the side effects this (temp) fix could have,

(maybe you can ask to this module's devs to have a look it), the very few changes i made are small enough to ensure they are safe without a very long battery of tests, and would keep working even after Paypal's rollback. 

This could have been a good opportunity to see why, for example, we are serializing an integer in actual code ($cart->nbProducts()...) and maybe choose to enforce security in the same way (eg : base the hash on something else than the cart's products count).

 

That's why IMHO , i think it was worth to have a look at the module especially now that it temporary stopped to work with HSS, even if we can trust Paypal will effectively do this rollback.

 

The strangest here, Xavier,  is that my initial post caused such polemics, though it only was a fix suggested for those exactly who were already shouting and blaming both Prestashop and Paypal...

Quite strange as well, a simple contribution caused such a debate while in final , the only thing Prestashop users were thinking about  and asking for was a working module (with HSS on) , and not have to wait 3 days for it.

 

My own comments or opinion about the "public" post you made about this issue is another topic.

First it's essential to keep communicating with the community, even more in the present case : yes you communicated.

 

There were and still are some points we don't and never agree on . (we = prestashop and i )

It always been and always will. (wouldn't be a real community otherwise, would it? ;) ) 

Here, what i don't agree in your post is only that we are told the module isn't responsible in anyway and that we just have to be patient and wait for Paypal action.

You may understand what i meant if you look around & see if other softwares were affected by this issue.

I couldn't find myself such reportings on major e-commerce softwares.

So i do think that we can't tell the module , even if it worked before and will work again in a few dozens of hours, that the module itself is absolutely not involved. Is this a negative though ? I don't think so. I always call myself into question. 

 

In any case, whatever anyone can tell or think about me, each time something similar happens in future, in case in think i have something wich may help some members, i'll act the very same way. 

 

Best Regards

  • Like 2
Link to comment
Share on other sites
OllyL Newbie

OllyL

Posted
Posted

Hi There,

 

if you're referring to me then I don't have any problems whatsoever with custom code fixes and as you point out, for some users who absolutely must have this functionality the only solution right now is potentially a custom fix like this.

 

For other users like me it's a question of risk - both now and in the future - and whether we want to risk a custom code fix which may fix one problem but could potentially cause side effects at some point in the future. It's not a comment on your coding ability or your knowledge of the platform, it's just a reality for any large application which has numerous parties developing for it. For us there is less risk if we only push code from known channels (such as Prestashop or PayPal) rather than pushing code from elsewhere which could lead to unforeseen bugs or complications.

 

One of the reasons we use PrestaShop is because there is a passionate, active community and support is readily available from people like yourself and so without you, many people like me would not be using this platform. I think this whole "debate" has grown out of thin air and there is no disagreement, just different users who choose to approach their system management in different ways.

 

Cheers,

 

Olly

Link to comment
Share on other sites
bellini13 Newbie

bellini13

Posted
Posted

I have to assume that Paypal made these changes for a reason, and I also have to assume at some point Paypal will be looking to release their changes again.

 

So while we agree it is not a good practice to rush out a change of the module, a change in the module may be needed after all. 

 

 

Has anyone from Prestashop discussed with Paypal the intention of their API/SDK updates and what changes may be required as a result?

Link to comment
Share on other sites
Broceliande Newbie

Broceliande

Posted
Posted (edited)

Hi There,

 

if you're referring to me then I don't have any problems whatsoever with custom code fixes and as you point out, for some users who absolutely must have this functionality the only solution right now is potentially a custom fix like this.

 

For other users like me it's a question of risk - both now and in the future - and whether we want to risk a custom code fix which may fix one problem but could potentially cause side effects at some point in the future. It's not a comment on your coding ability or your knowledge of the platform, it's just a reality for any large application which has numerous parties developing for it. For us there is less risk if we only push code from known channels (such as Prestashop or PayPal) rather than pushing code from elsewhere which could lead to unforeseen bugs or complications.

 

One of the reasons we use PrestaShop is because there is a passionate, active community and support is readily available from people like yourself and so without you, many people like me would not be using this platform. I think this whole "debate" has grown out of thin air and there is no disagreement, just different users who choose to approach their system management in different ways.

 

Cheers,

 

Olly

 

I agree with you on some points, not all though... but it has been discussed already. If you ask me, indeed you were the very first to answer to my post and had a negative approach. I did not get frustrated though but felt i had to give you my opinion. This is what i did.

What followed was not motived by this post so don't think you were aimed. Didn't i told you you were free to use this patch or not ?

No i wasn't referring to you , rather to some tweets wich stayed only some tweets and weren't reported there.

Maybe you'll find next fix from community usefull . I don't mind at all, be sure of this.

 

Indeed, this discussion grew out of proportion. @Broceliande: what I'm saying is your fix looks good, I think those who can change the code in their PayPal module should use it, but PrestaShop can't promote it, as in: push it to the whole user base.

 

So again, thank you is all I meant :)

 

Yes Xavier i got your message as it was told. A bit too flattering i'd say huh ;) ?

Well you must have understood i was a bit annoyed with Prestashop's message you had to report us.

What i must say is that only Prestashop has been affected by this issue , indeed due to recent changes in paypal apis.

Those changes don't affect global technical specifications, but only some fields validating rules.

In the present issue, Paypal looks to be ok to roll back those changes, nice.

They seem to do this for Prestashop only you know ...

This made me think the real "wargame" was between Paypal and Prestashop , @ prestashop's users detriment.

Prestashop won , but users lost in some way...

 

Nice to see you keep a dialog between Presta and its community.

 

Remember i also said this was not the first topic growing out of proportion. As well you know it's not the first or last one :) .

 

No use to preach a convinced "guy" (as somebody names me). 

I'd even be able to show you how a real conflict can lead to a consistent collaboration, proof is even there in the french forum. Just ask me in pm if you are interested in nice stories :)

Edited by Broceliande (see edit history)
Link to comment
Share on other sites
Guest

Guest

Posted
Posted

So,it is Thursday the 16th and the problem persists. Did PayPal indicate whether they meant the beginning of the day, or the end of the day? So it could be midnight today for the roll back?

 

Link to comment
Share on other sites
Eolia Grand Master

Eolia

Posted
Posted

So,it is Thursday the 16th and the problem persists. Did PayPal indicate whether they meant the beginning of the day, or the end of the day? So it could be midnight today for the roll back?

 

Mr. Gaillard have no doubt on this point, see here: https://twitter.com/gaillafr/status/522066528892911616

attachicon.gif16-10-2014 10-35-28.jpg

 

Perhaps this shows the issue if not the fix. And why we just need a system that works - and is consistent

 

The image shows an invoice raised this morning. A customer has bought 12 discounted items, and which ever way you calculate it, the figures do not add up

 

Tax is 20%

 

So if the Product total excluding tax is £41.64 then the VAT is 20% of that, £8.328 added together comes to £49.968 > So why is £50.04  showing?

 

Oh I know, product price including VAT is £4.17 *12  = £50.04

 

But surely which ever way you get to it, the figures should be the same?

 

In the summary table it shows total excluding tax = £41.64. but the tax is £8.28 - that is just not right, it should be £8.328

 

So is this "just" rounding issues? that will be sorted in the update? or is it that prestashop is calculating things differently at different times - even on the same invoice

Yes the rounding errors persisted since 4 years already.
1.6.0.10 The new version should fix that ... (Prestashop announced it)
Link to comment
Share on other sites
samyha Newbie

samyha

Posted
Posted
To everyone,

 

The rollback from Paypal's technical team has been made today. I invite you to reset the module.

 

However, we want to warn you that all the orders that had been made won't be recovered by Paypal. A special support will be proposed to merchants to solve this issue. 

 

@Eolia, I answered your tweet :). I got confirmation from some members that everything went back to normal, so please let me know if the bug remains for you :)

 

Have a nice day!

Link to comment
Share on other sites
OllyL Newbie

OllyL

Posted
Posted

Hi Samyha,

 

Will Paypal be releasing a statement about these issues? I've got to report to my clients exactly what happened and why it happened and considering the disruption this has caused to so many business owners I would hope that PayPal will at least be accepting responsibility for these issues.

 

Cheers,

Olly

Link to comment
Share on other sites
Guest

Guest

Posted
Posted

From PayPal

 

We are writing to let you know that an unforeseen issue caused a delivery failure of PayPal’s Instant Payment Notifications to your PrestaShop module for orders received through your PrestaShop web shop from October 13 to October 16, inclusive. 

As a result, these orders will show as ‘pending’ or ‘not completed’ in your PrestaShop administration interface, even if the corresponding PayPal payments have already completed successfully. You will need to reconcile these particular orders and PayPal payments manually. You can do this by downloading your PayPal transaction history to verify that the PayPal payments for these orders have completed successfully.

 

As they know who has the module installed. Perhaps it would have been nice for them to communicate as soon as they new there was an issue

 

Ah well, at least we know

Link to comment
Share on other sites
  • 2 weeks later...
  • 3 weeks later...
ucardblitzer Newbie

ucardblitzer

Posted
Posted

same with me, i tried the code posted here on payment.php and IPN still the same, it does not have any order created in Pretashop but in paypal. Additionally, I have saw log on pretashop .

"PaymentModule::validateOrder - Order Status cannot be loaded". All of the order that I have since I have encountered this issue have the same log entry on our Pretashop . 

 

Anyone have any idea if the error that I have encountered is the same as this issue?  Or possible how to fix it?

 

I am using "paypal EU 3.7.2" and tested w and w/o Exress checkout (Website Payments Standard)

Link to comment
Share on other sites
Eolia Grand Master

Eolia

Posted
Posted (edited)

same with me, i tried the code posted here on payment.php and IPN still the same, it does not have any order created in Pretashop but in paypal. Additionally, I have saw log on pretashop .

"PaymentModule::validateOrder - Order Status cannot be loaded". All of the order that I have since I have encountered this issue have the same log entry on our Pretashop .

 

 

See here: http://www.prestashop.com/forums/topic/380193-paypal-modification-ssl-v3-vers-tls/

 

But the most simple is to delete this line:

 @curl_setopt($ch, CURLOPT_SSLVERSION, 3);  

in the file modules/paypal/api/paypal_connect.php

Edited by Eolia (see edit history)
Link to comment
Share on other sites
ucardblitzer Newbie

ucardblitzer

Posted
Posted (edited)

Thank you for your reply however I have tried that and still the same. I have also upgraded my module to 3.8.0 , what I have notice that during my testing that the confirmation page after the payment is blank , then I check the "Shopping Cart" then I have saw multiple ID with the same Cart ID on the item that I have ordered. Then I tried to delete that shopping cart, then paste the "return page of paypal " and give me an error then it shows this paypal response (I have put XXX on identifiable information):

 
<b>PayPal response:</b>
BILLINGAGREEMENTACCEPTEDSTATUS -> 0
CHECKOUTSTATUS -> PaymentActionCompleted
TIMESTAMP -> 2014-11-21T15:41:51Z
PAYERID -> XXXXXXXXXX
PAYERSTATUS -> unverified
FIRSTNAME ->  XXXXXXXXX
LASTNAME -> XXXXX
COUNTRYCODE -> PH
SHIPTONAME -> Test Prod Tesa
SHIPTOSTREET -> 124
SHIPTOSTREET2 -> waa
SHIPTOCITY -> Makati
SHIPTOZIP -> 1200
SHIPTOCOUNTRYCODE -> PH
SHIPTOPHONENUM -> 121232323232
SHIPTOCOUNTRYNAME -> Philippines
ADDRESSSTATUS -> Unconfirmed
CURRENCYCODE -> USD
AMT -> 0.10
ITEMAMT -> 0.10
SHIPPINGAMT -> 0.00
HANDLINGAMT -> 0.00
TAXAMT -> 0.00
INSURANCEAMT -> 0.00
SHIPDISCAMT -> 0.00
L_NAME0 -> Test Product - Do not Purchase
L_NAME1 -> Philippines Local Shipping (Domestic Only) -- TEST DO NOT USE
L_NUMBER0 -> 21
L_NUMBER1 -> 5
L_QTY0 -> 1
L_QTY1 -> 1
L_TAXAMT0 -> 0.00
L_TAXAMT1 -> 0.00
L_AMT0 -> 0.10
L_AMT1 -> 0.00
L_DESC0 -> ...
L_ITEMWEIGHTVALUE0 -> 0.00000
L_ITEMWEIGHTVALUE1 -> 0.00000
L_ITEMLENGTHVALUE0 -> 0.00000
L_ITEMLENGTHVALUE1 -> 0.00000
L_ITEMWIDTHVALUE0 -> 0.00000
L_ITEMWIDTHVALUE1 -> 0.00000
L_ITEMHEIGHTVALUE0 -> 0.00000
L_ITEMHEIGHTVALUE1 -> 0.00000
PAYMENTREQUEST_0_CURRENCYCODE -> USD
PAYMENTREQUEST_0_AMT -> 0.10
PAYMENTREQUEST_0_ITEMAMT -> 0.10
PAYMENTREQUEST_0_SHIPPINGAMT -> 0.00
PAYMENTREQUEST_0_HANDLINGAMT -> 0.00
PAYMENTREQUEST_0_TAXAMT -> 0.00
PAYMENTREQUEST_0_INSURANCEAMT -> 0.00
PAYMENTREQUEST_0_SHIPDISCAMT -> 0.00
PAYMENTREQUEST_0_TRANSACTIONID -> XXXXXXXXX
PAYMENTREQUEST_0_INSURANCEOPTIONOFFERED -> false
PAYMENTREQUEST_0_SHIPTONAME -> Test Prod Tesa
PAYMENTREQUEST_0_SHIPTOSTREET -> 124
PAYMENTREQUEST_0_SHIPTOSTREET2 -> waa
PAYMENTREQUEST_0_SHIPTOCITY -> Makati
PAYMENTREQUEST_0_SHIPTOZIP -> 1200
PAYMENTREQUEST_0_SHIPTOCOUNTRYCODE -> PH
PAYMENTREQUEST_0_SHIPTOPHONENUM -> 121232323232
PAYMENTREQUEST_0_SHIPTOCOUNTRYNAME -> Philippines
PAYMENTREQUEST_0_ADDRESSSTATUS -> Unconfirmed
PAYMENTREQUEST_0_ADDRESSNORMALIZATIONSTATUS -> None
L_PAYMENTREQUEST_0_NAME0 -> Test Product - Do not Purchase
L_PAYMENTREQUEST_0_NAME1 -> Philippines Local Shipping (Domestic Only) -- TEST DO NOT USE
L_PAYMENTREQUEST_0_NUMBER0 -> 21
L_PAYMENTREQUEST_0_NUMBER1 -> 5
L_PAYMENTREQUEST_0_QTY0 -> 1
L_PAYMENTREQUEST_0_QTY1 -> 1
L_PAYMENTREQUEST_0_TAXAMT0 -> 0.00
L_PAYMENTREQUEST_0_TAXAMT1 -> 0.00
L_PAYMENTREQUEST_0_AMT0 -> 0.10
L_PAYMENTREQUEST_0_AMT1 -> 0.00
L_PAYMENTREQUEST_0_DESC0 -> ...
L_PAYMENTREQUEST_0_ITEMWEIGHTVALUE0 -> 0.00000
L_PAYMENTREQUEST_0_ITEMWEIGHTVALUE1 -> 0.00000
L_PAYMENTREQUEST_0_ITEMLENGTHVALUE0 -> 0.00000
L_PAYMENTREQUEST_0_ITEMLENGTHVALUE1 -> 0.00000
L_PAYMENTREQUEST_0_ITEMWIDTHVALUE0 -> 0.00000
L_PAYMENTREQUEST_0_ITEMWIDTHVALUE1 -> 0.00000
L_PAYMENTREQUEST_0_ITEMHEIGHTVALUE0 -> 0.00000
L_PAYMENTREQUEST_0_ITEMHEIGHTVALUE1 -> 0.00000
PAYMENTREQUESTINFO_0_TRANSACTIONID -> XXXXXXXX
PAYMENTREQUESTINFO_0_ERRORCODE -> 0
Cart changed since the last checkout express, please make a new Paypal checkout payment
Your cart is empty.
Edited by ucardblitzer (see edit history)
Link to comment
Share on other sites
ucardblitzer Newbie

ucardblitzer

Posted
Posted (edited)

I tried to test another set of cart and got this error with debugging enabled on my site:

 
 
Notice: Undefined index: PAYMENTREQUEST_0_SHIPPINGAMT in /home/uccard5/public_html/modules/paypal/paypal_orders.php on line 70

Notice: Undefined variable: payment_type in /home/uccard5/public_html/modules/paypal/express_checkout/payment.php on line 289

Notice: Undefined variable: message in /home/uccard5/public_html/modules/paypal/express_checkout/payment.php on line 289

Fatal error: Call to undefined method Validate::isObject() in /home/uccard5/public_html/classes/PaymentModule.php on line 171
 

 

Then I check the paymenmodule.php it looks like this on line 171.

if (!Validate::isObject($order_status))
{
PrestaShopLogger::addLog('PaymentModule::validateOrder - Order Status cannot be loaded', 3, null, 'Cart', (int)$id_cart, true);
throw new PrestaShopException('Can\'t load Order status');
 
}
 
Then I check the /classes/validate.php to verify the classes unfortunately i could not find in the isObject method.
Edited by ucardblitzer (see edit history)
Link to comment
Share on other sites
bellini13 Newbie

bellini13

Posted
Posted
isObject is not a valid function in the Validate class.
if (!Validate::isObject($order_status))

When I look at the code in PaymentModule, on line 171 it says the following

if (!Validate::isLoadedObject($order_status))

Can you explain what version of Prestashop you are using, and if you have made any changes to these files?

Link to comment
Share on other sites
ucardblitzer Newbie

ucardblitzer

Posted
Posted (edited)

its 1.6.0.9 have re-upload the affected files with the original one. I think I have accidentally modify it when I am troubleshooting that module.

 

Here is the new error that I have encountered upon checkout.

 

Notice: Undefined index: PAYMENTREQUEST_0_SHIPPINGAMT in /home/uccard5/public_html/modules/paypal/paypal_orders.php on line 70

Notice: Undefined variable: payment_type in /home/uccard5/public_html/modules/paypal/express_checkout/payment.php on line 289

Notice: Undefined variable: message in /home/uccard5/public_html/modules/paypal/express_checkout/payment.php on line 289

Fatal error: Uncaught exception 'PrestaShopException' with message 'Can't load Order status' in /home/uccard5/public_html/classes/PaymentModule.php:174 Stack trace: #0 /home/uccard5/public_html/modules/paypal/paypal.php(1361): PaymentModuleCore->validateOrder(32, 0, 0.1, 'PayPal', NULL, Array, 1, false, 'd30b341786dc356...', Object(Shop)) #1 /home/uccard5/public_html/modules/paypal/express_checkout/payment.php(290): PayPal->validateOrder(32, NULL, 0.1, 'PayPal', NULL, Array, 1, false, 'd30b341786dc356...', Object(Shop)) #2 /home/uccard5/public_html/modules/paypal/express_checkout/payment.php(306): validateOrder(Object(Customer), Object(Cart), Object(PaypalExpressCheckout)) #3 {main} thrown in/home/uccard5/public_html/classes/PaymentModule.php on line 174

Edited by ucardblitzer (see edit history)
Link to comment
Share on other sites
bellini13 Newbie

bellini13

Posted
Posted

If you look at the code below, you will see 32, 0.  32 is the Cart ID, and 0 is the Order Status ID.

PaymentModuleCore->validateOrder(32, 0, 0.1, 'PayPal', NULL, Array, 1, false, 'd30b341786dc356...', Object(Shop))

0 is not a valid Order Status ID, which means that the Paypal module could not correctly determine which order status to use.  Which is not surprising because of the 'payment_type' notice you received

Notice: Undefined variable: payment_type in /home/uccard5/public_html/modules/paypal/express_checkout/payment.php on line 289

payment_type would normally contain the order status ID and if the variable is undefined, that means it will default to 0.

 

Now looking at /express_checkout/payment.php I see the following code block. 

if (strcmp($payment_status, 'Completed') === 0)
{
    $payment_type = (int)Configuration::get('PS_OS_PAYMENT');
    $message = $ppec->l('Payment accepted.').'<br />';
}
elseif (strcmp($payment_status, 'Pending') === 0)
{
    $payment_type = (int)Configuration::get('PS_OS_PAYPAL');
    $message = $ppec->l('Pending payment confirmation.').'<br />';
}

This code block says...

If the Paypal payment status is 'Completed', then assign the 'Payment Accepted' order status.

Else If the Paypal payment status is 'Pending', then assign the 'Awaiting Paypal Payment' order status.

 

The question you need to answer is...  what happens if the Paypal payment status is not 'Completed' or 'Pending'?.

 

It would seem the module has a defect. You will need to do 2 things

1) Determine what the value of $payment_status is for your testing, since it likely is not 'Completed' or 'Pending'

2) Once you determine that value, you then need to determine which order status to use, and set $payment_type variable accordingly. 

Link to comment
Share on other sites
ucardblitzer Newbie

ucardblitzer

Posted
Posted (edited)

Thank you for your valuable input, I will try to log the payment status type so that I am able to reveal what the value is.  Anyway,  is the paypal responses below is the one we are looking for ?

 

BILLINGAGREEMENTACCEPTEDSTATUS -> 0

CHECKOUTSTATUS -> PaymentActionCompleted
Edited by ucardblitzer (see edit history)
Link to comment
Share on other sites
ucardblitzer Newbie

ucardblitzer

Posted
Posted (edited)

Paid with paypal and no order / info in BackOffice???

It was happening to me with the new Paypal 3.8, but then I fix it :)

Pretty easy....

 

Well, it will be helpful for us , if you can share on how you fix it.right now,I re-install my site and putting all together and still got the same issue... I am having a hard time to debug the code as my programmer level in PHP is beginner.

Edited by ucardblitzer (see edit history)
Link to comment
Share on other sites
ucardblitzer Newbie

ucardblitzer

Posted
Posted (edited)

I somehow fix it, for some reason the $payment-type value was not properly stored  but due to the knowledge limitation that I have in PHP i only manage to stored it on the end of the else statement, I hope someone can validate the changes it does not affect the overall code . currently the checkout is now working and need to fix the other issue (duplicate shopping cart using the same cart id for the same guest ID): 

I have added the following line in payment.php 

        //added 11/30
        $payment_type = (int)Configuration::get('PS_OS_PAYMENT');
        //added 11/30

refer to the code below:

function validateOrder($customer, $cart, $ppec)
{
	$amount_match = $ppec->rightPaymentProcess();
	$order_total = (float)$cart->getOrderTotal(true, Cart::BOTH);

	// Payment succeed
	if ($ppec->hasSucceedRequest() && !empty($ppec->token) && $amount_match)
	{
		if ((bool)Configuration::get('PAYPAL_CAPTURE'))
		{
			$payment_type = (int)Configuration::get('PS_OS_WS_PAYMENT');
			$payment_status = 'Pending_capture';
			$message = $ppec->l('Pending payment capture.').'<br />';
		}
		else
		{
		
			if (isset($ppec->result['PAYMENTINFO_0_PAYMENTSTATUS']))
				$payment_status = $ppec->result['PAYMENTINFO_0_PAYMENTSTATUS'];

			else
				$payment_status = 'Error';
		
			if (strcmp($payment_status, 'Completed') === 0)
			{
				$payment_type = (int)Configuration::get('PS_OS_PAYMENT');
				$message = $ppec->l('Payment accepted.').'<br />';
			}
			elseif (strcmp($payment_status, 'Pending') === 0)
			{
				$payment_type = (int)Configuration::get('PS_OS_PAYPAL');
				$message = $ppec->l('Pending payment confirmation.').'<br />';
			}
		//added 11/30
		$payment_type = (int)Configuration::get('PS_OS_PAYMENT');
		//added 11/30	
		}

	}

	// Payment error
	else
	{
		//Check if error is 10486, if it is redirect user to paypal
		if ($ppec->result['L_ERRORCODE0'] == 10486)
			$ppec->redirectToAPI();

		$payment_status = $ppec->result['PAYMENTINFO_0_PAYMENTSTATUS'];
		$payment_type = (int)Configuration::get('PS_OS_ERROR');

		if ($amount_match)
			$message = implode('<br />', $ppec->logs).'<br />';
		else
			$message = $ppec->l('Price paid on paypal is not the same that on PrestaShop.').'<br />';
	}
	$transaction = PayPalOrder::getTransactionDetails($ppec, $payment_status);
	$ppec->context->cookie->id_cart = $cart->id;

	$ppec->validateOrder((int)$cart->id, $payment_type, $order_total, $ppec->displayName, $message, $transaction,
		(int)$cart->id_currency, false, $customer->secure_key, $ppec->context->shop);
}
Edited by ucardblitzer (see edit history)
Link to comment
Share on other sites
Diabloflash Newbie

Diabloflash

Posted
Posted (edited)

LOL Try this!!! Works with the New Paypal 3.8

 

Step 1: Login to Paypal

Step 2: Go to Click Profile - Under my My selling Tools - and Update the instant payment notifications.

 

-------------------------------------------------------------------------------------------------------------------

Step 3:

Current settings Notification URL

http://www.YOUWEBSITE.com/modules/paypal/validation.php"

Message delivery Enabled

 

SHOULD BE: --------- NOTE THAT THE "USA" IS ADDED!!!!

Current settings Notification URL

http://www.YOUWEBSITE.com/modules/paypalusa/validation.php"

Message delivery Enabled

 

-------------------------------------------------------------------------------------------------------------------

Step 4: Test to see if its working :)  -  ( Do a full real check out )

Step 5: Thank me if this worked for you, It worked for me :)

Edited by Diabloflash (see edit history)
Link to comment
Share on other sites
bellini13 Newbie

bellini13

Posted
Posted

@ucardblitzer: I would be careful with your approach.  the code you added ignores the payment status from Paypal and just assumes that the payment was completed successfully.  A paypal payment status can have multiple values.

 

The module is defective since it only considers 'Completed' and 'Pending', and does nothing if it is some other value.  So your code hack does get around that problem, but it may assume to much, by assuming that everything worked.

 

What I would have suggested is to confirm what the value "payment_status" was, since for you it was not 'completed' or 'pending', so what was the value?  I would confirm what the value is, and then add an additional elseif condition for that value and assign the appropriate order status

            if (strcmp($payment_status, 'Completed') === 0)
            {
                $payment_type = (int)Configuration::get('PS_OS_PAYMENT');
                $message = $ppec->l('Payment accepted.').'<br />';
            }
            elseif (strcmp($payment_status, 'Pending') === 0)
            {
                $payment_type = (int)Configuration::get('PS_OS_PAYPAL');
                $message = $ppec->l('Pending payment confirmation.').'<br />';
            }
            // add your elseif condition here...
           
Link to comment
Share on other sites
ucardblitzer Newbie

ucardblitzer

Posted
Posted (edited)

 

@ucardblitzer: I would be careful with your approach.  the code you added ignores the payment status from Paypal and just assumes that the payment was completed successfully.  A paypal payment status can have multiple values.

 

The module is defective since it only considers 'Completed' and 'Pending', and does nothing if it is some other value.  So your code hack does get around that problem, but it may assume to much, by assuming that everything worked.

 

What I would have suggested is to confirm what the value "payment_status" was, since for you it was not 'completed' or 'pending', so what was the value?  I would confirm what the value is, and then add an additional elseif condition for that value and assign the appropriate order status

            if (strcmp($payment_status, 'Completed') === 0)
            {
                $payment_type = (int)Configuration::get('PS_OS_PAYMENT');
                $message = $ppec->l('Payment accepted.').'<br />';
            }
            elseif (strcmp($payment_status, 'Pending') === 0)
            {
                $payment_type = (int)Configuration::get('PS_OS_PAYPAL');
                $message = $ppec->l('Pending payment confirmation.').'<br />';
            }
            // add your elseif condition here...
           

Thank you for your input,, now i  fix it.. I have found the value which was "Completed_Funds_Held" and I added the following line:

			elseif (strcmp($payment_status, 'Completed_Funds_Held') === 0)
			{
				$payment_type = (int)Configuration::get('PS_OS_PAYPAL');
				$message = $ppec->l('Pending payment confirmation.').'<br />';
			}
Edited by ucardblitzer (see edit history)
Link to comment
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
 Share
Go to topic listing
×
×
  • Create New...