Amazon Payments (LPA) für JTL Shop4

[IchBinEs]

mit Sicherheit nicht, da die Bestellungen merkwürdiger Weise in der Zukunft

 

[Hangman]

Irgendwie komme ich bei einem Punkt nicht weiter. Es geht um die E-Mail Vorlage der Bestellbestätigung.

Unseren Kunden wird bei Zahlung über Amazon Payments immer die Bankverbindung per E-Mail mitgeschickt. Das darf nicht sein.

Der Punkt in der E-Mail-Vorlage sieht wie folgt aus:

{if $Bestellung->Zahlungsart->cModulId=="za_ueberweisung_jtl"}
...
{elseif $Bestellung->Zahlungsart->cModulId=="za_nachnahme_jtl"}
    {elseif $Bestellung->Zahlungsart->cModulId=="za_kreditkarte_jtl"}
    {elseif $Bestellung->Zahlungsart->cModulId=="za_rechnung_jtl"}
    {elseif $Bestellung->Zahlungsart->cModulId=="za_lastschrift_jtl"}
    {elseif $Bestellung->Zahlungsart->cModulId=="za_barzahlung_jtl"}
    {elseif $Bestellung->Zahlungsart->cModulId=="za_paypal_jtl"}
    {elseif $Bestellung->Zahlungsart->cModulId=="za_moneybookers_jtl"}
{/if}

Da Amazon Payments keine eigene Zahlungsart an sich darstellt, hänge ich hier fest und weiß nicht, wie man auf die Zahlungsart prüfen kann, damit unsere Bankverbindung nicht mehr mitgesendet wird.

Hat da jemand eine Lösung für?

Vielen Dank im Voraus.

 

[Diedrichs]

Ich habe nach dem Update auf dem 4.05 offene Order welche in der Zukunft liegen

Hast recht, ist bei mir doch auch so. Sorry.

 

[Sebastian Meyer]

mit Sicherheit nicht, da die Bestellungen merkwürdiger Weise in der Zukunft

Hallo,

die Bestellungen bleiben im Status OPEN bis sie manuell geschlossen werden oder Amazon sie nach 6 Monaten automatisch schließt.
Das Datum ist auch nicht das Bestelldatum, sondern das Ablaufdatum. Das liegt logischerweise in der Zukunft.

Also alles normal so.

 

[Sebastian Meyer]

Irgendwie komme ich bei einem Punkt nicht weiter. Es geht um die E-Mail Vorlage der Bestellbestätigung.

Unseren Kunden wird bei Zahlung über Amazon Payments immer die Bankverbindung per E-Mail mitgeschickt. Das darf nicht sein.

Der Punkt in der E-Mail-Vorlage sieht wie folgt aus:

{if $Bestellung->Zahlungsart->cModulId=="za_ueberweisung_jtl"}
...
{elseif $Bestellung->Zahlungsart->cModulId=="za_nachnahme_jtl"}
    {elseif $Bestellung->Zahlungsart->cModulId=="za_kreditkarte_jtl"}
    {elseif $Bestellung->Zahlungsart->cModulId=="za_rechnung_jtl"}
    {elseif $Bestellung->Zahlungsart->cModulId=="za_lastschrift_jtl"}
    {elseif $Bestellung->Zahlungsart->cModulId=="za_barzahlung_jtl"}
    {elseif $Bestellung->Zahlungsart->cModulId=="za_paypal_jtl"}
    {elseif $Bestellung->Zahlungsart->cModulId=="za_moneybookers_jtl"}
{/if}

Da Amazon Payments keine eigene Zahlungsart an sich darstellt, hänge ich hier fest und weiß nicht, wie man auf die Zahlungsart prüfen kann, damit unsere Bankverbindung nicht mehr mitgesendet wird.

Hat da jemand eine Lösung für?

Vielen Dank im Voraus.

Die Prüfung könnte z.B. auf den Zahlungsartnamen gehen.

Also {if $Bestellung->cZahlungsartName === "Amazon Payments"} bzw. {if $Bestellung->cZahlungsartName === " Amazon Pay"} (je nachdem, ob schon die neue Plugin-Version 1.06 im Einsatz ist oder nicht).
Der Name auf den geprüft werden muss, sehen Sie im Detail auch in der Mail bei "Sie haben folgende Zahlungsart gewählt: {$Bestellung->cZahlungsartName}".

 

[spaxxilein]

Wenn ich das Amazon Plugin aktiviere wird in der Zahlungsartenauswahl die PayPal Plus Paywall nicht mehr angezeigt. Jemand eine Idee wo ich die CSS anpassen muss, damit beides untereinander angezeigt wird!? Mit der vorherigen 1.04 Version des PP Plugins hat noch alles funktioniert.

 

[Sebastian Meyer]

Wenn ich das Amazon Plugin aktiviere wird in der Zahlungsartenauswahl die PayPal Plus Paywall nicht mehr angezeigt. Jemand eine Idee wo ich die CSS anpassen muss, damit beides untereinander angezeigt wird!? Mit der vorherigen 1.04 Version des PP Plugins hat noch alles funktioniert.

Welche Shop-Version?
Welches Template?
Welche Versionen vom PayPal-Plugin und vom Amazon Plugin sind genau im Einsatz?

 

[spaxxilein]

Shop 4.05.1, Template ist egal sowohl im Standard EVO als auch bei unserem Smile-template von themeart der gleiche Fehler, Paypal Plugin 1.06 (1.04 richtig deinstalliert und 1.06 neu aufgesetzt), AMA Plugin 1.05

Hab das Ama Plugin 106 mal installiert und danach die Frontend-Links aktualisiert, PP Paywall wird auch damit nicht angezeigt.

 

[Sebastian Meyer]

Das kann ich in meinem Testsystem nicht nachstellen.
PP+ und Amazon werden immer zusammen angezeigt, ohne CSS-Anpassungen.

Gibt es im Browser- Log irgendwelche Fehler auf der Seite? (F12 -> Console)

Hat sonst noch jemand dasselbe Problem?

 

[spaxxilein]

Nein keine Error Logs, es sieht so aus als würde die Paywall von Paypal rechts von der Amazon Box und damit in einem nicht sichtbaren Bereich geladen werden.

Habe dir eine Nachricht geschickt, hoffe das ist in Ordnung.

 

[hula1499]

Hallo,

nach nun über 1 Jahr Pause mit dem Amazon Payment Plugin (aufgrund der ständigen requests auch für Amazon Login, obwohl es im Plugin unterscheidungen gibt Pay/Login/alles und man bei nur Pay keinerlei Login requests benötigt)
wollten wir nach einigen Anpassungen (Template) wieder mal das Amazon Plugin, auf dem Dev, testen:

1.) Loginproblematik ist weiterhin vorhanden (wenn nur Pay ausgewählt ist, braucht es keine login-requests bei CMS Seiten etc. zu Amazon -> vollkommen unnötige Laderei)
2.) Amazon Pay Buttons -> also das ist alles andere als ideal gelöst da:
2a) Kein Amazon Pay Button auf der Artikeldetailseite (erst wenn ein Artikel im Warenkorb -> sonst kein Paybutton vorhanden)
2b) Kein Amazon Pay Button im Mini-Warenkorb -> erst bei neuladen der Seite, weiterem hinzufügen eines Artikels etc.

d.h. die einzige Anzeige des Amazon Pay-Buttons ist auf der warenkorb.php + bestellvorgang.php 1x - das wars.
Laut unserer Statistik besuchen Besteller unter 10% die warenkorb.php und gehen gleich zum bestellen/Kasse über.
Da wir den one-page checkout von Hypnos verwenden, gibts dort auch keinen sinnvollen Einsatz für Amazon Pay.

Für MICH ist Amazon Pay gleichzusetzen wie PPE. Die Logik dahinter ist ja ebenso identisch.
Kunde hat einen Artikel und kann den via "Schnellkauf" beziehen, ohne Daten oder sonstiges Zeug (wie halt PPE).
PPE funktioniert auf der Artikelebene (mit oder ohne Variationskombis), direkt im Miniwarenkorb, direkt auf der warenkorb.php.
Amazon Pay funktioniert lediglich auf der warenkorb.php+bestellvorgang.php -> egal was / wie man es template mässig einstellt.

Hier wird mögliches Potential vollkommen vom Plugin verschwendet.
Für maximalen Einsatz muss der Button auf der Detailseite sein (wie PPE) und auf der Mini-Warenkorbübersicht (wie PPE).
Der Kunde soll kaufen und seine Möglichkeiten sofort sehen und nicht erst, wenn er auf die warenkorb/bestellvorgang geht, da hat man den Kunden eh meist schon an der Hand.

 

[Sebastian Meyer]

Hallo,

danke für das Feedback.

Ich gehe mal auf die Punkte ein:

1.) Loginproblematik ist weiterhin vorhanden (wenn nur Pay ausgewählt ist, braucht es keine login-requests bei CMS Seiten etc. zu Amazon -> vollkommen unnötige Laderei)
2.) Amazon Pay Buttons -> also das ist alles andere als ideal gelöst da:
2a) Kein Amazon Pay Button auf der Artikeldetailseite (erst wenn ein Artikel im Warenkorb -> sonst kein Paybutton vorhanden)
2b) Kein Amazon Pay Button im Mini-Warenkorb -> erst bei neuladen der Seite, weiterem hinzufügen eines Artikels etc.

Die Skripte, die hier von Amazon geladen werden, erzeugen selbst wiederum auch Requests, das ist richtig.

Zum technischen Hintergrund: ich kann als Plugin-Entwickler die JS-Dateien per info.xml einbinden oder manuell. Wenn ich sie per info.xml einbinde, hat das zwei Vorteile:
- Das entspricht der Konvention zur Plugin-Entwicklung.
- So eingebundene Dateien werden per Minify mit ausgeliefert und sparen damit wieder Requests.

Der Nachteil ist, dass ich nicht bestimmen kann, auf welcher Seite die Dateien überhaupt geladen werden.

Wir entwickeln dieses Plugin als allgemeines Plugin für alle JTL-Shops.
Nur weil es bei einem Kunden an bestimmten Stellen nicht gebraucht wird, heißt das nicht, dass das überall so ist.

Noch ein wichtiger technischer Hintergrund: die Buttons selbst werden nicht durch das Plugin, sondern durch die von Amazon geladenen Skripte gerendert.
In dem Sinne könnte man die Buttons folglich gar nicht im Mini-WK rendern (der ja auch auf jeder Seite zu sehen ist!), wenn man das Rendering auf Seitentypen eingrenzen würde. Hier widersprechen sich also Punkt 1 und Punkt 2b.

d.h. die einzige Anzeige des Amazon Pay-Buttons ist auf der warenkorb.php + bestellvorgang.php 1x - das wars.
Laut unserer Statistik besuchen Besteller unter 10% die warenkorb.php und gehen gleich zum bestellen/Kasse über.
Da wir den one-page checkout von Hypnos verwenden, gibts dort auch keinen sinnvollen Einsatz für Amazon Pay.

Hier gibt es im Shop also eine Speziallogik. Im Standard-Shop gibt es m.M.n. keine Möglichkeit, an dem Button vorbeizukommen (außer ggf. Quick-Checkout, wenn man bereits eingeloggt ist).

Für MICH ist Amazon Pay gleichzusetzen wie PPE. Die Logik dahinter ist ja ebenso identisch.
Kunde hat einen Artikel und kann den via "Schnellkauf" beziehen, ohne Daten oder sonstiges Zeug (wie halt PPE).
PPE funktioniert auf der Artikelebene (mit oder ohne Variationskombis), direkt im Miniwarenkorb, direkt auf der warenkorb.php.
Amazon Pay funktioniert lediglich auf der warenkorb.php+bestellvorgang.php -> egal was / wie man es template mässig einstellt.

Amazon Pay ist eben nicht PPE. Durch oben genannte technische Problematik, dass der Button selbst von Amazon gerendert wird, kann man sich auch schwer mit eigener Logik draufschalten wie "wenn du geklickt wirst, pack was in den Warenkorb, bevor du zu Amazon weiterleitest".
Das Klick-Handling des Buttons erfolgt komplett über die Amazon Pay-Skripte.
Den Button auf einer Artikeldetailseite einzublenden (da würde er im Übrigen auch angezeigt werden, sobald eine Bestellung möglich ist) macht daher imgrunde keinen Sinn, weil er nicht das tut, was der Kunde beim Klick erwarten würde.
Rein technisch ist die Anzeige aber ohne Weiteres möglich.

Was hier fehlt, ist eher Amazon-seitig eine Lösung in Richtung 1-Click-Kauf wie es ihn auf Amazon gibt - das ist aber nicht dasselbe wie das Bezahlen mit Amazon Pay.

Das Thema, den Button im Mini-Warenkorb beim ersten Reinlegen zu zeigen, nehme ich mal mit - das Problem ist hier der AJAX-Request, der den Mini-WK nachlädt i.V.m. der Tatsache, dass die Amazon-Buttons bei einem bestimmten Event gerendert werden, welcher ebenfalls durch die Amazon-Skripte, aber nur ein Mal beim Laden der Seite, getriggert wird.

Nachtrag: Mini-Warenkorb sieht schlecht aus, weil das HTML dort über die io.php geladen wird. Diese nutzt intern Smarty->fetch(...) und bei ->fetch(...) wird (anders als bei ->display(...)) das Template nicht durch die Output-Filter-Hooks geschickt. Das Plugin sieht dieses Snippet also nicht, um dort die Elemente einzuhängen. (Nur beim Laden einer neuen Seite ist das initial möglich - wird durch den AJAX-Reload der Daten dann aber auch wieder zunichte gemacht.)

 

[hula1499]

Hallo Sebastian, zuerst einmal danke für dein umfassendes Feedback.

Wir entwickeln dieses Plugin als allgemeines Plugin für alle JTL-Shops.
Nur weil es bei einem Kunden an bestimmten Stellen nicht gebraucht wird, heißt das nicht, dass das überall so ist.

Bin 100% bei dir.
Jedoch gibt es im Plugin eine Abfrage Login/Pay/beides - hätte man es so programmiert, dass diese Abfrage auch eine Relevanz bei der Einblendung hat, braucht man nicht unnötigen Traffic produzieren und könnte
die Kunden, die eben im Plugin "Pay" eingestellt haben, davon ausklammern, dass auf CMS Seiten, Impressum, AGB etc. vollkommen unnötige Ressourcen geladen werden, ständig und überall.
Ich weiss ja nicht, was bei der Erstellung des Plugins berücksichtigt worden ist, aber in Zeiten von Smartphones, Tablets, Phablets und günstige 3G Tarife ist der Anteil der User von diesem Segment immer höher.
Bei uns mittlerweile ca. 55% aller Bestellungen. Der Traffic beim Provider, Last am Server interessiert mich nicht, aber 28% mehr request durch euer Plugin (auch für Leute die Ama Payment gar nicht vorhanden ist (andere Länder)) interessiert mich schon.
Trotz technischer Laie kann ich mir nicht vorstellen, dass so eine Abfrage ein technisches "Problem" wäre:
.) ist im Plugin Alles/Login eingestellt - lade immer alles
.) ist im Plugin nur Pay eingestellt, lade erst dann, wenn Pay auch zu tragen kommt (derzeit ja nur im checkout, vorher braucht das ganze Zeug ja niemand).

Noch ein wichtiger technischer Hintergrund: die Buttons selbst werden nicht durch das Plugin, sondern durch die von Amazon geladenen Skripte gerendert.
In dem Sinne könnte man die Buttons folglich gar nicht im Mini-WK rendern (der ja auch auf jeder Seite zu sehen ist!), wenn man das Rendering auf Seitentypen eingrenzen würde. Hier widersprechen sich also Punkt 1 und Punkt 2b.

Ok, ich bin kein Programmierer, aber:

.) wir bekommen es ja hin, dass der Button angezeigt wird (leider erst bei reload der Seite)
.) PPE krieg ich ja auch rein (ok, wird ja selbst eingeblendet)

Mit dem Mini-WK und auf jeder Seite gerendert....erwischt, dran hab ich nicht gedacht.
Aber dann würd das für die, die nur Pay verwenden ja auch wieder Sinn machen.

So wie ich unseren SP verstanden habe, liegt es grösstenteils daran, dass PPE das Produkt "in den Warenkorb" legt (beim click) und euer Plugin diese FUnktion eben nicht nutzt in dieser Art und Weise daher der Button nicht sofort
im Warenkorb (mini) sichtbar ist (erst bei reload, erst bei zweitem Produkt).
Sorry wenn ich mich hier viell. zu wage ausdrücke, gebe nur das wider, woran ich mich so an die Gespräche diesbezüglich erinner

Amazon Pay ist eben nicht PPE. Durch oben genannte technische Problematik, dass der Button selbst von Amazon gerendert wird, kann man sich auch schwer mit eigener Logik draufschalten wie "wenn du geklickt wirst, pack was in den Warenkorb, bevor du zu Amazon weiterleitest".
Das Klick-Handling des Buttons erfolgt komplett über die Amazon Pay-Skripte.
Den Button auf einer Artikeldetailseite einzublenden (da würde er im Übrigen auch angezeigt werden, sobald eine Bestellung möglich ist) macht daher imgrunde keinen Sinn, weil er nicht das tut, was der Kunde beim Klick erwarten würde.
Rein technisch ist die Anzeige aber ohne Weiteres möglich.

Was hier fehlt, ist eher Amazon-seitig eine Lösung in Richtung 1-Click-Kauf wie es ihn auf Amazon gibt - das ist aber nicht dasselbe wie das Bezahlen mit Amazon Pay.

Das ist aber dann einfach ein Logikfehler (ich kann nicht verifizieren ob er bei euch oder Amazon selbst liegt).

Artikelseite (jetzt mal ohne Variationen): PPE -> klick drauf -> schick zu PP, fertig
Ama Pay ist ja nix andres (vom Ablauf her!). Kunde will was, und macht dann den nächsten Step (Ama einloggen, bestätigen, fertig).
Und Ama Pay funktioniert ja auch so - nur halt an den falschen Stellen.
Im Warenkorb ist der Button ja da und macht genau das, was er bei PPE macht.
Klick ich beim checkout auf den Ama Pay Button, macht er nix andres wie oben beschrieben. Da hat der Kunde auch nichts weiter interagiert (ausser auf eine weitere Seite zu klicken).
D.h. die Funktionalität ist - generell - ja vorhanden. Wenn ich diese im beim Warenkorb einblenden kann, "muss" ich die auch voll funktionell beim Artikel einblenden lassen können. Ist ja nix andres.

Das Thema, den Button im Mini-Warenkorb beim ersten Reinlegen zu zeigen, nehme ich mal mit - das Problem ist hier der AJAX-Request, der den Mini-WK nachlädt i.V.m. der Tatsache, dass die Amazon-Buttons bei einem bestimmten Event gerendert werden, welcher ebenfalls durch die Amazon-Skripte, aber nur ein Mal beim Laden der Seite, getriggert wird.

Nachtrag: Mini-Warenkorb sieht schlecht aus, weil das HTML dort über die io.php geladen wird. Diese nutzt intern Smarty->fetch(...) und bei ->fetch(...) wird (anders als bei ->display(...)) das Template nicht durch die Output-Filter-Hooks geschickt. Das Plugin sieht dieses Snippet also nicht, um dort die Elemente einzuhängen. (Nur beim Laden einer neuen Seite ist das initial möglich - wird durch den AJAX-Reload der Daten dann aber auch wieder zunichte gemacht.)

Ja, der Nachtrag ist das Problem, welches wir auch feststellen. Erst bei einem reload ist der Button sichtbar, dadurch natürlich leider "wertlos" für den Kunden.

Aus kaufmännischer Sicht, aus Sicht von/für Amazon selbst, aus Sicht des Händlers muss der Button, um voll effizient zu sein, hier eingeblendet sein/werden:

.) Artikeldetailseite (mit/ohne Variationen, bei Nachladen einer Vari, muss er natürlich auch das request mitnehmen)
.) Mini Warenkorb
.) Kategorieseite (natürlich nur bei Produkten ohne interaktion/Variationen) also klarerweise nur dort, wo auch jetzt ein "warenkorb-button" ist

Wie PPE auch.

Amazon nervt uns im 2-3 Wochen Rhytmus damit, wann wir endlich wieder aufschalten. Ich kann nix aufschalten, wo ich auf der einene Seite soviele Ressourcen laden lassen muss (klar, nicht eure Schuld) - auf der andren Seite jedoch den Button nur auf einer Seite sichtbar hab und nicht dort, wo er eigentlich hingehören sollte (kaufmännisch gesehen).

Wir bekommen in, am DEV, mit diversen Anpassungen, nur so hin:
.) ARtikeldetailseite - erst nach reload (aber dann auf der ganzen Seite, bei allen Produkten sichtbar)
.) Miniwarenkorb - erst nach reload (aber dann immer sichtbar - session)

Also technisch ist das schon möglich, der reload ist halt nur das Problem.

Wir verwenden Hypnos, onepage-checkout. Hier ist Ama Pay (in der üblichen Auslieferung) vollkommen unnütz.
Wenn ich beim onepagecheckout bin, ist er die allerletzte Stelle und viel zu spät.
Ich weiss schon, jetzt kommt: dann setz ein andres Template ein. Ja, irgendwann mal wird JTL auch eins haben, dann gibts mit Evo das selbe Problem, ausserdem bringt man den Button in einem onepagecheckout nicht mehr vernünftig unter.

 

[chico1401]

mir ist noch ein Fehler aufgefallen....
Wenn ich bei unserem Template (Hypnos) den Login Button bei der Artikelübersicht anzeigen möchte, funktioniert dies über die ID = Paymentbuttons.
Soweit so gut.
Bei einem "reinen" Artikel bekommt steht dann als ID=AmazonPayButton_2, bei VarKombis ID=AmazonPayButton_1, welche dann nicht angezeigt wird.....
Wir hängen nämlich den PayPal Express an diese ID und bei den VarKombis haben so beide gefehlt....

 

[Sebastian Meyer]

mir ist noch ein Fehler aufgefallen....
Wenn ich bei unserem Template (Hypnos) den Login Button bei der Artikelübersicht anzeigen möchte, funktioniert dies über die ID = Paymentbuttons.
Soweit so gut.
Bei einem "reinen" Artikel bekommt steht dann als ID=AmazonPayButton_2, bei VarKombis ID=AmazonPayButton_1, welche dann nicht angezeigt wird.....
Wir hängen nämlich den PayPal Express an diese ID und bei den VarKombis haben so beide gefehlt....

Hi,

die "#AmazonPayButton_x" ist eine interne technische ID, die eindeutig sein muss, damit mehrere Buttons auf der Website alle korrekt durch die JS-Skripte initialisiert werden.
Daher wird hinten einfach pro Button ein Index rangehängt.

Diese ID sollte daher nicht als Selektor für irgendwas anderes genutzt werden. (Davon abgesehen kann das auch schief gehen, wenn die Hooks anderer Plugins vorher ausgeführt werden - dann ist das Element z.B. noch gar nicht im DOM vorhanden.)

Viele Grüße,
Sebastian Meyer

 

[martinwolf]

mir ist noch ein Fehler aufgefallen....
Wenn ich bei unserem Template (Hypnos) den Login Button bei der Artikelübersicht anzeigen möchte, funktioniert dies über die ID = Paymentbuttons.
Soweit so gut.
Bei einem "reinen" Artikel bekommt steht dann als ID=AmazonPayButton_2, bei VarKombis ID=AmazonPayButton_1, welche dann nicht angezeigt wird.....
Wir hängen nämlich den PayPal Express an diese ID und bei den VarKombis haben so beide gefehlt....

Nicht ganz. In der Übersicht gibt es kein Element mit der ID "paymentbuttons". Dieses wird nur auf der Detailseite und im Warenkorb erzeugt. Daher wäre der Selektor für die Dateilseite und den Warenkorb jeweils "#paymentbuttons". Über die Einbindungsmethode append werden die Buttons dann darin platziert. So ist gewährleistet dass es keine Konflikte mit anderen Plugins gibt. Das Element "paymentbuttons" dient auch zur Einbindung von PayPal Express oder anderen Schnellzahlungs Elementen.

 

[chico1401]

ich meinte auch die Artikeldetailsseite, funktioniert aber bei uns trotzdem nicht.
Habe jetzt auch extra nochmal die PayPal Express Anzeige deaktiviert, und Amazon Payment wird nicht angezeigt, wegen o.g. Problem, aber nur bei VarKombis

 

[chico1401]

Frage:
Ist das Plugin php 7.0 fähig oder gibt es eine spezielle Version?

 

[Sebastian Meyer]

Hi,

ja, das Plugin ist PHP 7.0-fähig und bedarf keines besonderen Downloads (der wird normalerweise wegen ionCube benötigt).

Viele Grüße,
Sebastian Meyer

 

[zhelyde]

Das kann ich in meinem Testsystem nicht nachstellen.
PP+ und Amazon werden immer zusammen angezeigt, ohne CSS-Anpassungen.

Gibt es im Browser- Log irgendwelche Fehler auf der Seite? (F12 -> Console)

Hat sonst noch jemand dasselbe Problem?

wir haben heute den Amazon Payments Plugin installiert ( Shop 4.05.2, AMA Plugin 1.08, EVO Template) und eingerichtet und seit ist Paypal weg. Was sollen wir nun machen?