Paypal und Gast-Checkout wird nicht korrekt beendet / keine Weiterleitung order-confirmation

[DRMasterChief]

Hallo,
ich möchte mein Problem gerne möglichst genau beschreiben, kurz geht es um die Weiterleitung nach einem Gast-Checkout und Zahlung per Paypal.

PS  1.6.1.4 -Version  (aber auch in anderen Versionen das gleiche Problem)

Wenn ein Kunde mit Paypal zahlt und den Gast-Checkout wählt (OnePageCheckout) kann er die Zahlung normal durchlaufen, auch die Bestellung wird angelegt etc.

ABER, und das ist das große Problem,  wird der Kunde nach dem Bezahlen zurück auf die Kundenkonto-Seite geleitet (die es aber bei einem Gast-Checkout nicht gibt):  Es sollte aber wohl so sein, daß der Kunde zurück auf die  OrderConfirmation  geleitet wird  und dort die Bestellung bestätigt sieht  (Kunden erwarten ja genau das,  alles andere führt zu massiven Verwirrungen, nochmaligen Käufen, Zahlungen etc.).

Meine Frage wäre, ob man hier schon irgendwie weitergekommen ist?  Das Problem besteht wohl seit Jahren schon bzw. kann ich viele Beiträge dazu finden, aber keine definitive Lösung.

Auch mit dem EU-Modul von Paypal scheint da keine Lösung vorhanden zu sein  (einige User hatten beschrieben daß das im US-Modul fehlerhaft ist,  aber im EU-Modul funktionieren soll).

Was wäre denn im EU-Modul anders und wie könnte endlich eine funktionierende Lösung gefunden werden?  Ich mag nicht glauben daß bei der Vielzahl der Paypal-User (Händler) das nicht sauber funktionieren mag.

Weitere Voraussetzungen bei mir, da es noch ein Testshop ist:  kein SSL,  Paypal im Sandbox-Modus

Dankeschön, würde mich freuen wenn da was voran geht.  Thomas 

 

Dieses Problem/Fehlverhalten ist in den unten genannten zwei englischen Beiträgen auch recht genau beschrieben:

https://www.prestashop.com/forums/topic/400277-native-paypal-module-not-returning-to-order-confirmation-page-after-payment/

https://www.prestashop.com/forums/topic/419632-paypal-no-order-in-bo-order-history-fix/

 

Edited December 28, 2018 by DRMasterChief (see edit history)

[Tom1967]

Das geht mirt auch dermaßen auf den Geist!
Alle paar Monate wieder können Kunden nicht über PayPal zahlen.
Und bis ich das bemerke sind schon einige Aufträge verloren gegangen!!!

[DRMasterChief]

Zahlen können Sie ja, das geht bei mir problemlos durch.  Auch die Bestellung wird angelegt.   Aber eben der Abschluß "sieht komisch aus" weil keine  Order-Confirmation.tpl  kommt.

Welche Versionen (Shop und Modul) verwendest du denn und was meinst du mit "alle paar Monate"?  Heisst daß nach einem Update vom Modul geht es mal und mal nicht?  Wäre toll wenn wir da mehr Infos dazu sammeln können. 

 

[eleazar]

Läuft denn auch die ältere Paypal-Version mit dem Fix bei dir nicht richtig?

Und im Paypal-Setup hast du den Gast-Checkout auch aktiviert?  --> https://developer.paypal.com/docs/integration/direct/payments/guest-payments/#

 

[DRMasterChief]

Hallo, danke für Deine Antwort.  Die Version von tbr170 bekomme ich nicht zum laufen, da vorher immer ein Update gemacht werden muss.  Kann es damit also leider nicht testen.

Und in der aktuellen Sandbox-Umgebung bei Paypal  (die nicht gerade toll ist)  gibts diesen Punkt leider nicht:   https://developer.paypal.com/docs/integration/direct/payments/guest-payments/# 

Ich weiss nicht was der Unterschied bei den  NVP/SOAP APIs  sein könnte,  aber ggf. müsste ich das mal ausprobieren?  Kann da wer helfen und hat Erfahrung damit? 

So kanns jedenfalls nicht bleiben....  eleazar,  wüsstest du denn welche Datei bzw. Code im Paypal-Modul für die Weiterleitung/für den Aufruf der  order-confirmation  zuständig ist?

Ich habe schon mehrere Versionen von Paypal-Modulen verglichen, aber werde nicht schlau draus.  z.B. sind im  /controllers/front  oftmals ganz unterschiedliche Dateien enthalten oder es fehlen manche je nach Version  (US, EU, tbr170 usw.)

 

[rictools]

Ich würde zunächst einmal prüfen, ob das Problem nur in der Sandbox auftritt oder auch im echten Betrieb ...

[eleazar]

vor 16 Stunden schrieb DRMasterChief:

Und in der aktuellen Sandbox-Umgebung bei Paypal  (die nicht gerade toll ist)  gibts diesen Punkt leider nicht:   https://developer.paypal.com/docs/integration/direct/payments/guest-payments/# 

 

[DRMasterChief]

rictools :  ja müsste ich zur allerletzten Rettung mal testen,  denken könnte ich mir ggf. schon daß da Unterschiede bestehen, wobei ich das im bisherigen Shopsystem noch  nicht hatte,  da war die Sandbox immer 100% identisch zum Live-Modus und man konnte nahtlos umschalten und alles war ok.

Funktioniert das denn bei Euch  (und anderen....)  korrekt mit der Weiterleitung nach der Paypal-Zahlung?  Das wäre ja auch schonmal hilfreich zu wissen. 

 

Ich habe auf dem Testshop derzeit auch kein SSL, da keine Domain drauf liegt,  >> was laut Paypal aber nichts ausmacht !

 

eleazar :  was wolltest du schreiben ?!   Wenn ich eingeloggt bin im Paypal Dashboard für Entwickler gibts diese Einstellung nicht  (da gibts nicht mal "Selling Preferences",  ich denke die Hilfe ist mal wieder uralt und das Dashboard entsprechend neugestaltet worden,  viele Links führen da immer wieder ins Leere etc.).  Habe diesen Link gefunden der deinem wohl entsprechend würde.  https://www.paypal.com/us/webapps/mpp/account-optional   > Seite existiert nicht.

Klasse gemacht von Paypal 

 

Denkst du aber daß diese Einstellung in Paypal zu einer korrekten Weiterleitung shopseitig führen würde?  Kann ich mir kaum vorstellen, aber du bist da wissender als ich ! 

 

Edited December 30, 2018 by DRMasterChief (see edit history)

[Claudiocool]

Öhm..... ich meine, mich dunkel zu erinnern, dass man die Rückleitungs-URL beim Zahlungsanbieter angibt und diese dann nach erfolgter Zahlung aufgerufen wird. denn irgendwoher müssen die ja wissen, wo der Kunde nach der Zahlung hinsoll.

[DRMasterChief]

Jo, bei Paypal in der Sanbox-Umgebung (Account) ist angegeben:

http://meineseite.xyz/modules/paypal/views/templates/front/order-confirmation.tpl

dennoch wird auch bei Guest-Checkouts aufs Kundenkonto geleitet. 

Habe auch dieses hier probiert, ebenso ohne Erfolg:  http://meineseite.xyz/index.php?fc=module&module=paypal&controller=logintoken 

 

Edited December 30, 2018 by DRMasterChief (see edit history)

[DRMasterChief]

in der  paypal/controllers/front/orderconfirmation.php  gibt es

 

                'HOOK_ORDER_CONFIRMATION' => '',
                'HOOK_PAYMENT_RETURN' => $this->module->hookPaymentReturn(['order' => $order]),

muss da ggf. in der oberen Zeile was manuell eingetragen werden? 

 

[Claudiocool]

Du scheinst ein anderes Modul zu nutzen als ich

Ich weigere mich ja beharrlich, das Ding upzudaten, weil damals direkt nach dem Update nichts mehr ging... Das bei mir eingesetzte hat die Version 3.11.5, ich musste seinerzeit lediglich ein paar Kleinigkeiten dran verändern, weil sonst bei Auslandszahlungen dem Kunden der dicke Stinkefinger gezeigt wurde....

    public function initContent()
    {
        if (!$this->context->customer->isLogged(true) || empty($this->context->cart)) {
            Tools::redirect('index.php');
        }

Findet sich eventuell in deiner Oderconfirmation php dieses if, was ich fett gedruckt habe?

[DRMasterChief]

Nein, an der von Dir genannten Stelle habe ich das nicht.

 

"Ähnliches" habe ich nur in der  paypal/classes/PaypalLogin.php  wie folgt:

    public function getAuthorizationCode()
    {
        unset($this->logs);

        $context = \Context::getContext();
        $isLogged = $context->customer->isLogged();

        if ($isLogged) {
            return $this->getRefreshToken();
        }

 

 

Und mach bloß kein Update  :)   Das Forum hier ist voll mit ähnlichen Lösungssuchen (englisch) und nirgends eine brauchbare Antwort oder Lösung dazu.  Ich finde online auch viele Infos und Probleme dazu und auch daß die Modulversionen da total unterschiedlich sein sollen. 

 

[Claudiocool]

Neeee..... ich werde da kein Update machen, das hab ich einmal gemacht und musste dann alles aus den Backups wiederherstellen, weil man nirgends mehr eine wirklich funktionierende Version fand.

Das letzte Problem hat mich Monate beschäftigt, weil aus einigen Ländern keine Bestellungen möglich waren, die mit Paypal bezahlt werden sollten. Die geben da ein Modul raus, das dann nichtmal die eigenen geforderten Variablen übergeben kann... coole Sache eben....

[DRMasterChief]

Ja dem lesen nach kann ich mir das jetzt vorstellen....

Welche Version verwendest du denn aktuell,  wo das noch "recht" gut funktioniert?   Bzw. findet man halt leider keine älteren Versionen mehr irgendwo zum runterladen. 

Mit 2 Programmierern bin ich grade in Kontakt, aber die wollen nicht mal so gerne ran, also auch gegen Geld kaum Lösung in Sicht (!) 

Edited December 31, 2018 by DRMasterChief (see edit history)

[eleazar]

Ich habe diesem vermurksten Modul nie viel abgewinnen können. Und deine Version scheint da sogar ein neuer Tiefpunkt zu sein. Hier mal eine ältere Version, die ich irgendwo im Forum schon mal gepostet habe. Die ist auch schneller als 3.11x.

paypal_3-10-10.zip

Trotzdem sollst du auch hier die von Claudiocool zitierte programmiertechnische Glanzleistung 😊 entfernen:

vor 6 Stunden schrieb Claudiocool:

if (!$this->context->customer->isLogged(true) 

(Es kann natürlich sein, dass es hier Unverträglichkeiten mit PHP 7[.2] gibt. Das habe ich jetzt nicht überprüft.)

[eleazar]

vor 4 Stunden schrieb DRMasterChief:

public function getAuthorizationCode()

Und da ändere bitte bloß nichts. Das hat mit dem Gast-Checkout nichts zu tun.

[DRMasterChief]

eleazar, vielen Dank für deine Tips und das Modul  (das hatte ich noch nicht,  grins - lustiges Modulesammeln.....) 

Habe das von claudiocool genannte entfernt,  Modul läuft aber leider mit und ohne diesem nicht.  Folgender Fehler beim Checkout: 

ERROR OCCURRED:
Setzen Sie sich mit dem Händler in Verbindung:

<b>PayPal response:</b>
->
Making new connection to 'api-3t.sandbox.paypal.com/nvp'
Connect failed with fsockopen method

 

Rein informativ, weils von Dir angesprochen wurde.  habe PHP 7.1.25 

Edited December 31, 2018 by DRMasterChief (see edit history)

[eleazar]

Was den Fehler anbelangt: Das ist die veraltete Paypal-API. Schau mal in die Datei  modules/paypal/api/paypal_connect.php. Da findest du die folgende Zeile:

@curl_setopt($ch, CURLOPT_SSLVERSION, Configuration::get('PAYPAL_VERSION_TLS_CHECKED') == '1.2' ? 6 : 1);

Die solltest du besser auskommentieren. Frage ist natürlich, welche TLS-Version dein Server aktuell unterstützt. Du brauchst auf jeden Fall TLS 1.2. Hier mal ein PHP-Skript für den Check: http://area51.enter-solutions.com/snippets/99

 

[DRMasterChief]

Diese Zeile ist in deinem Modul schon auskommentiert:

 //@curl_setopt($ch, CURLOPT_SSLVERSION, Configuration::get('PAYPAL_VERSION_TLS_CHECKED') == '1.2' ? 6 : 1);

und TLS 1.2  läuft,  das wäre also kein Problem, sollte man meinen.... 

[eleazar]

Hast du es eigentlich mal mit der (üblicherweise fehlerbereinigten) Version von @Gurkcity versucht? https://www.onlineshop-module.de/zahlungsmodul-prestashop-paypal-16.html

[DRMasterChief]

Alles Gute zum neuen Jahr erstmal,  hoffe Ihr seit gut durchgekommen 

Das Modul von Gurkcity habe ich versucht,  mit folgendem Fehler s.u.  Könnte ich daraus aber ggf. was brauchbares ableiten und in ein funktionierendes Modul einbauen, so daß die Weiterleitung nach der Zahlung korrekt ist?   Der "Rest" funktioniert ja bei mir, also Zahlung geht, Auftrag wird angelegt etc.,  nur nach der PP-Zahlung wird aufs Kundenkonto geleitet - was eben alle Gastkunden ziemlich verunsichert. 

 

 

**This is not a valid version [[]]**  
 *at line* **24** *in file* `vendor/vierbergenlars/php-semver/src/vierbergenlars/SemVer/version.php`  
```php  
19.         */
20.        function __construct($version, $padZero=false) {
21.            $version = (string) $version;
22.            $expression = sprintf(parent::$dirty_regexp_mask, parent::$global_single_version);
23.              if(!preg_match($expression, $version, $matches)) {
24. =>             throw new SemVerException('This is not a valid version');
25.        }
26.    
27.            parent::matchesToVersionParts($matches, $this->major, $this->minor, $this->patch, $this->build, $this->prtag, $padZero?0:null);
28.    
29.            if($this->build === '') 
```  
- **vierbergenlars\SemVer\version->__construct** - [line `167` - `vendor/vierbergenlars/php-semver/src/vierbergenlars/SemVer/version.php`]  
 - [1 Arguments]  
```php  
162.         * @param string|version $v2 The second version
163.         * @return boolean 
164.         */
165.        static function gt($v1, $v2) {
166.            $v1 = new version($v1);
167. =>         $v2 = new version($v2);
168.    
169.            $ma1 = $v1->getMajor();
170.            $ma2 = $v2->getMajor();
171.    
172.            if($ma1 < 0 &&$ma2 >= 0)
```  
```Argument [0]  
3.11.4.7
```  
- **vierbergenlars\SemVer\version::gt** - [line `1060` - `classes/module/Module.php`]  
 - [2 Arguments]  
```php  
1055.    
1056.            if (Validate::isLoadedObject($updater) && $modules = $updater->getCachedModulesInfo()) {
1057.                foreach ($modules as $name => $module) {
1058.                    if (isset($modulesNameToCursor[mb_strtolower(strval($name))])) {
1059.                        $moduleFromList = $modulesNameToCursor[mb_strtolower(strval($name))];
1060. =>                     if ($moduleFromList->version && Version::gt($module['version'], $moduleFromList->version)) {
1061.                            $moduleFromList->version_addons = $module['version'];
1062.                            $modulesNameToCursor[mb_strtolower(strval($name))] = $moduleFromList;
1063.                        }
1064.    
1065.                        continue;
```  
```Argument [0]  
vierbergenlars\SemVer\version Object
(
    [version:vierbergenlars\SemVer\version:private] =&gt; 5.3.3
    [major:vierbergenlars\SemVer\version:private] =&gt; 5
    [minor:vierbergenlars\SemVer\version:private] =&gt; 3
    [patch:vierbergenlars\SemVer\version:private] =&gt; 3
    [build:vierbergenlars\SemVer\version:private] =&gt; -1
    [prtag:vierbergenlars\SemVer\version:private] =&gt; 
    [chunks:vierbergenlars\SemVer\expression:private] =&gt; Array
        (
        )

)

Argument [1]  
3.11.4.7
```  
- **ModuleCore::getModulesOnDisk** - [line `334` - `controllers/admin/AdminModulesController.php`]  
 - [3 Arguments]  
```php  
329.                }
330.                $modulesPreferences[$v['module']] = $v;
331.            }
332.    
333.            // Retrieve Modules List
334. =>         $modules = Module::getModulesOnDisk(true, $this->logged_on_addons, $this->id_employee);
335.            $this->initModulesList($modules);
336.            $this->nb_modules_total = count($modules);
337.            $moduleErrors = [];
338.            $moduleSuccess = [];
339.            $upgradeAvailable = [];
```  
```Argument [0]  
1
Argument [1]  

Argument [2]  
1
```  
- **AdminModulesControllerCore->initContent** - [line `262` - `classes/controller/Controller.php`]  
```php  
257.                if (!$this->content_only && ($this->display_header || (isset($this->className) && $this->className))) {
258.                    $this->initHeader();
259.                }
260.    
261.                if ($this->viewAccess()) {
262. =>                 $this->initContent();
263.                } else {
264.                    $this->errors[] = Tools::displayError('Access denied.');
265.                }
266.    
267.                if (!$this->content_only && ($this->display_footer || (isset($this->className) && $this->className))) {
```  
- **ControllerCore->run** - [line `837` - `classes/Dispatcher.php`]  
```php  
832.                if (isset($paramsHookActionDispatcher)) {
833.                    Hook::exec('actionDispatcher', $paramsHookActionDispatcher);
834.                }
835.    
836.                // Running controller
837. =>             $controller->run();
838.            } catch (PrestaShopException $e) {
839.                $e->displayMessage();
840.            }
841.        }
842.    
```  
- **DispatcherCore->dispatch** - [line `63` - `admin/index.php`]  
```php  
58.    if (!isset($_REQUEST['controller']) && isset($_REQUEST['tab'])) {
59.        $_REQUEST['controller'] = strtolower($_REQUEST['tab']);
60.    }
61.    
62.    // Prepare and trigger admin dispatcher
63. => Dispatcher::getInstance()->dispatch();
```  
 

[Claudiocool]

Ich stelle gerade fest, dass ich schon ewig nicht mehr in den developer-Dingern bei Paypal drin war. Jetzt suche ich mir gerade einen Wolf wegen der Settings meines Accounts, um mal zu sehen, wie der Rücksprung bei mir eingestellt ist.

Habe gerade gefunden.....

..../onlineshop/modules/paypal/controllers/front/submit.php

Edited January 1, 2019 by Claudiocool (see edit history)

[DRMasterChief]

über  https://developer.paypal.com/developer/applications/  ins Dashboard >  My Apps & Credentials >  ca. in der Mitte der Seite REST API apps > 
und da dann auch ca. mittig auf der Seite: Return URL- Users are redirected to this URL after live transactions. Allow up to three hours for the change to take effect. Show/Hide

 

Seit einiger Zeit scheint das mit Null Ergonomie gestaltet zu sein,  finden tut man nix mehr...  und hunderte Links ins Leere.

Edited January 1, 2019 by DRMasterChief (see edit history)

[Claudiocool]

Meine werden (wie gerade oben geschrieben) zu

..../onlineshop/modules/paypal/controllers/front/submit.php

zurückgeleitet, wenn ich das so in meinem PayPal-Account nachsehe

[DRMasterChief]

URL redirect zu  /modules/paypal/controllers/front/submit.php

auch das geht leider nicht,  immer noch das gleiche....

[Claudiocool]

Hm.... dann wird das wohl irgendwo abgefangen und "umgebogen"