Social Login in PrestaShop: Google, Facebook und Apple

So würden wir vorgehen

Wir würden mit Ihrem bestehenden Shop beginnen: seinen Registrierungsregeln, Kundendaten, dem Theme, Checkout-Modulen, Einwilligungswerkzeugen und Integrationen, die Kunden anlegen oder aktualisieren. Wählen Sie Anbieter anhand Ihrer Zielmärkte und Supportanfragen und prüfen Sie dann, ob eine installierte Integration den Bedarf bereits deckt. Ihr Team muss die Anbieter-Apps pflegen und Kunden bei der Wiederherstellung ihres Zugangs helfen können.

Ist eine Änderung gerechtfertigt, konfigurieren Sie sie auf einer isolierten Staging-Kopie mit demselben Theme und denselben Modulen, kontrollierten Testidentitäten und bewusst festgelegten Callback-Einstellungen der Anbieter. Sperren Sie auf dieser Kopie E-Mails an echte Kunden und Exporte in produktive Kundensysteme. Erlauben Sie E-Mails nur an kontrollierte Testpostfächer einschließlich der Apple-Relay-Adressen der Testidentitäten und verwenden Sie eine Sandbox für Integrationstests. Erproben Sie die folgenden Tests und schalten Sie anschließend in einem geplanten Zeitfenster um, wobei die bisherige Konfiguration und Identitätszuordnungen gesichert bleiben. Vereinbaren Sie, wie Sie die Änderung rückgängig machen und dabei nach dem Start angelegte Kunden und Bestellungen erhalten.

Wenn Sie die Möglichkeiten für Ihren Shop bewerten lassen möchten, testet das PrestaShop Module Selection & Fit Assessment mögliche Wege auf einer kontrollierten Shopkopie.

Anmeldemethoden für Ihre Kunden wählen

Die Anmeldung über externe Anbieter ermöglicht Kunden die Authentifizierung mit einem bestehenden Anbieterkonto, statt ein weiteres Shoppasswort anzulegen. Bei wiederkehrenden Kunden kann der Vorteil darin liegen, ein vergessenes Shoppasswort zu umgehen, statt die Erstregistrierung zu beschleunigen. Kontowahl, Einwilligung, Mehrfaktor-Authentifizierung und das Ergänzen fehlender Shopangaben können weiterhin nötig sein. Versprechen Sie keine feste Abschlusszeit.

Halten Sie normale Anmeldung und Kontowiederherstellung verfügbar und behalten Sie Gastbestellungen bei, wenn dies zu Ihrem Geschäft passt. Die Anbieteranmeldung ist eine Option und kein Grund, die Kontoerstellung zu erzwingen. Bei der nativen Registrierung von PrestaShop 1.7.8 und 9 enthält der Formatter ein Passwortfeld ohne separates Passwortbestätigungsfeld; eigene Themes und Module können Felder ergänzen.

Wählen Sie Anbieter nach Kundennachfrage und gemessener Nutzung. Es gibt weder eine allgemeingültige Anbietermischung noch eine belastbare Regel, dass Nutzer eines Anbieters höherwertige Bestellungen aufgeben. Prüfen Sie, ob Ihre Integration PrestaShop-Version, aktives Theme, normale Anmeldung, Registrierung und Checkout-Anmeldung unterstützt.

Bei der Anbieteranmeldung bleibt das Passwort dieses Anbieters außerhalb Ihres Shops. Sie ersetzt nicht den Schutz von Kundendaten, lokalen Konten, Tokens, Sitzungen und administrativem Zugriff.

Identitätsablauf und Validierung verstehen

1. Der Shop startet eine mit der aktuellen Kundensitzung verknüpfte Autorisierungsanfrage beim Anbieter.
2. Der Kunde authentifiziert sich beim Anbieter und genehmigt den angeforderten Zugriff, soweit erforderlich.
3. Der Anbieter sendet eine Autorisierungsantwort an den registrierten Callback.
4. Der Shop validiert die Antwort und tauscht bei einem Autorisierungscode-Ablauf den Code über den unterstützten Serverendpunkt des Anbieters aus.
5. Die Integration validiert die Identität, findet deren bestehende Anbieterzuordnung oder führt sichere Kontoerstellung/-verknüpfung durch und richtet dann die Shop-Sitzung ein.

OAuth-Autorisierung und Identitätsprüfung hängen zusammen, sind aber verschieden. Google und Apple verwenden Identitätstokens nach OpenID-Connect-Art. Jeder Anbieter hat einen eigenen unterstützten Schnittstellenvertrag; eine allgemeine Profilabfrage ersetzt dessen Validierung nicht.

Prüfen Sie bei Identitätstokens Signatur, Aussteller, Zielgruppe, Ablauf und gegebenenfalls die erwartete Nonce. Binden Sie die Antwort durch einen passenden State-Wert und Schutz vor Wiederholungsangriffen an die gestartete Sitzung. Verwenden Sie PKCE, wenn Anbieter und Ablauf dies unterstützen oder verlangen. Weisen Sie Abweichungen vor Kontoerstellung oder Anmeldung zurück.

Speichern Sie eine stabile Anbieterkennung mit der lokalen Kundenzuordnung. Identifizieren Sie bei OpenID Connect das Konto über validierten Aussteller und Subject. Google empfiehlt ausdrücklich seinen stabilen Claim sub statt E-Mail als Identitätsschlüssel. Siehe Googles OpenID-Connect-Leitfaden.

Verwenden Sie produktiv HTTPS, validieren Sie Rückkehrziele streng und schützen Sie Geheimnisse in serverseitiger Konfiguration. Schreiben Sie geheime Schlüssel, Zugriffstokens oder vollständige Autorisierungsantworten nicht in Routineprotokolle. Bewahren Sie Tokens nur auf, wenn die Funktion sie benötigt, und wechseln Sie Zugangsdaten bei Bedarf.

Google-Anmeldung vorbereiten

1. Erstellen oder wählen Sie das passende Google-Projekt und konfigurieren Sie Branding, Zielgruppe und Einwilligungseinstellungen seiner Identitäts-App.
2. Fordern Sie nur benötigte Identitäts-Scopes an, normalerweise openid, email und bei Bedarf profile.
3. Erstellen Sie den zur Integration passenden Client, häufig einen OAuth-Client für Webanwendungen.
4. Kopieren Sie die tatsächliche Callback-URL der Integration in die autorisierten Weiterleitungs-URIs. Ergänzen Sie JavaScript-Ursprünge nur, wenn der Browserablauf sie erfordert.
5. Speichern Sie Client-ID und gegebenenfalls erforderliches Client-Geheimnis über die unterstützten Integrationseinstellungen.
6. Testen Sie vor dem Start sowohl neue als auch bestehende Kunden, einschließlich eines Kontos außerhalb der Entwicklungs-/Testzielgruppe.

Gleichen Sie Schema, Hostname, Port, Pfad und gegebenenfalls Query-String des Callbacks exakt ab. Ein Wechsel von Root-Domain, www, Shop-Unterverzeichnis oder sprachabhängiger Route kann eine Abweichung verursachen. Legen Sie Staging- und Produktivzugangsdaten sowie Callback-Einstellungen bewusst fest.

Behandeln Sie Namen und Profilbilder als optionale personenbezogene Daten, nicht als erforderliche Adressen oder Nachweis der Kundenberechtigung. Ein Anbieterprofil liefert nicht jedes Rechnungs- oder Lieferfeld, das Ihr Shop benötigt.

Facebook Login und externen Zugriff vorbereiten

Verwenden Sie die aktuelle Einrichtungscheckliste für Ihre gewählte Meta-App und Integration. Dokumentieren Sie vor dem Test App-Typ, vorgesehene Zielgruppe, angeforderte Berechtigungen und die tatsächliche HTTPS-Callback-URL. Fordern Sie nur Profil- und E-Mail-Berechtigungen an, die Sie tatsächlich verwenden. Konfigurieren Sie vor dem Start die erforderlichen Einstellungen der App zu Datenschutzerklärung und Nutzerdatenlöschung und testen Sie den veröffentlichten Löschungsweg.

Prüfen Sie die aktuellen Zugriffsanforderungen für den App-Typ, einschließlich Berechtigungszugriffsstufen, Prüfung und gegebenenfalls Unternehmensverifizierung. Erfolg mit Entwicklungs-/Testkonten und das Umschalten auf Live reichen nicht als Nachweis, dass normale externe Kunden sich anmelden können. Konsultieren Sie die offizielle Facebook-Login-Dokumentation und die Einstellungen Ihrer App.

Eine E-Mail-Adresse kann fehlen oder für die App nicht verfügbar sein. Erkennen Sie diesen Fall, fragen Sie den Kunden nach einer Kontakt-E-Mail und verifizieren Sie diese durch einen geeigneten Prozess, bevor Sie sie für Kontoinhaberschaft oder Wiederherstellung nutzen. Erfinden Sie keine zustellbare E-Mail aus einer Anbieter-ID und verknüpfen Sie kein bestehendes Shop-Konto stillschweigend.

Testen Sie Berechtigungsverweigerung, teilweise Genehmigung, einen Nutzer ohne zurückgegebene E-Mail, einen externen Nutzer ohne App-Rolle und eine widerrufene Verbindung. Bieten Sie einen hilfreichen Ersatzweg statt einer leeren Callback-Seite.

Apple-Voraussetzungen und Relay-E-Mail prüfen

Apples dokumentierte Webeinrichtung erfordert eine vorhandene App-Store-App mit Sign in with Apple. Verknüpfen Sie die Services ID der Website mit der aktivierten primären App ID; eine Mitgliedschaft und ungenutzte App ID allein erfüllen nicht alle Voraussetzungen. Folgen Sie Apples Umgebungsanforderungen.

1. Bestätigen Sie die geeignete App und primäre App ID.
2. Erstellen/konfigurieren Sie die Services ID der Website und verknüpfen Sie sie mit dieser primären App.
3. Registrieren Sie die tatsächlichen Website-Domains und absoluten HTTPS-Rückkehr-URLs.
4. Erstellen Sie den passenden privaten Schlüssel und konfigurieren Sie die von der Integration benötigten Team-/Client-/Schlüsselkennungen.
5. Stellen Sie sicher, dass die Integration das signierte JWT-Client-Geheimnis korrekt erstellt und erneuert, und schützen Sie den privaten Schlüssel.

Nutzen Sie Apples Web-Konfigurationsschritte für die Kontokonfiguration. Testen Sie sowohl eine neue Autorisierung als auch wiederkehrende Anmeldungen.

Die erste Autorisierung kann ein Nutzerobjekt mit dem Namen enthalten. Validieren und speichern Sie es zu diesem Zeitpunkt und bieten Sie bei fehlenden Angaben einen Ergänzungsweg an. Spätere Autorisierungen liefern dieses Nutzerobjekt nicht erneut. Lesen Sie die E-Mail-Adresse, sofern verfügbar, aus dem validierten Identitätstoken; bieten Sie bei fehlender Adresse einen Ergänzungs- und Verifizierungsweg an. Überschreiben Sie einen gespeicherten Namen nicht mit einem fehlenden Wert. Siehe die Apple-Callback-Dokumentation.

Akzeptieren Sie Apples verifizierte echte oder private Relay-E-Mail-Adresse. Die bisher verwendete Domain generierter Adressen lautet @privaterelay.appleid.com. Apples Ankündigung von 2026 sieht vor, neue Relay-Adressen für Sign in with Apple im späteren Verlauf von 2026 auf @private.icloud.com umzustellen, während bestehende Adressen weiter funktionieren. Behandeln Sie dies als angekündigten Übergang und bestätigen Sie bei der Umsetzung den Rollout und die Unterstützung durch die Integration. Unterstützen Sie beide Domains und verwenden Sie kein fest codiertes einzelnes Suffix als Identitätsnachweis. Siehe Apples Aktualisierung zur Relay-Domain.

Registrieren Sie Ihre ausgehenden E-Mail-Quellen und authentifizieren Sie diese nach Apples Anforderungen. Testen Sie Bestell-, Versand- und Wiederherstellungsnachrichten über das Relay, auch bei einem Nutzer mit deaktivierter Weiterleitung. Die Relay-Adresse ist ein gültiger Kontaktendpunkt und kein Weg, die verborgene Adresse zu ermitteln. Folgen Sie den Anweisungen zum privaten Relay.

Konten verknüpfen, ohne Bestellhistorien offenzulegen

Suchen Sie zuerst nach einer bestehenden Zuordnung der validierten Anbieteridentität. Verwenden Sie nach der Verknüpfung diese stabile Zuordnung für spätere Anmeldungen. E-Mail-Adressen können sich ändern, fehlen oder private Relay-Adressen sein.

Stimmt die E-Mail einer erstmals auftretenden Identität mit einem vorhandenen Kunden überein, behandeln Sie dies als mögliche Verknüpfung, nicht als Erlaubnis zur Kontoanmeldung. Verlangen Sie den Nachweis der Kontrolle über das bestehende Shop-Konto, etwa durch erneute Authentifizierung oder einen sicheren verifizierten Wiederherstellungs-/Verknüpfungsablauf. Anbieter-Vertrauenswürdigkeit und Bedeutung der E-Mail-Verifizierung unterscheiden sich.

1. Validieren Sie Anbieteridentität und gestartete Anmeldesitzung.
2. Existiert ihre Zuordnung, bestätigen Sie die Anmeldeberechtigung des lokalen Kontos.
3. Gibt es einen möglichen lokalen Treffer, erläutern Sie die Verknüpfung und verlangen Sie den erforderlichen Nachweis.
4. Verknüpfen Sie die Identität erst nach Bestätigung und mit Duplikat- und Gleichzeitigkeitsschutz.
5. Gibt es keinen Treffer, ergänzen Sie erforderliche Kundenfelder und erstellen Sie ein Konto.

Nach sicherer Bestätigung können mehrere Anbieter einem Kunden zugeordnet sein. Führen Sie Konten nicht allein wegen ähnlicher Namen oder anderer Profilfelder zusammen. Behandeln Sie eine Apple-Relay-E-Mail und eine andere Google-E-Mail als unterschiedliche Kontaktwerte, bis der Kunde die Verknüpfung nachweist und genehmigt.

Ermöglichen Sie das Aufheben von Kontoverknüpfungen und die Kontowiederherstellung, ohne Kunden auszusperren. Richten Sie vor Entfernung des letzten nutzbaren Anbieters eine andere gültige Anmeldemethode ein. Handhaben Sie widerrufene Einwilligungen, deaktivierte lokale Konten, geänderte E-Mails und Löschung von Anbieterkonten gezielt.

Die Anmeldung eines bestehenden Geschäftskunden durchspielen

Ein Geschäftskunde hat freigegebene Preise, gespeicherte Adressen, frühere Bestellungen und eine ERP-Kundenreferenz. Er wählt Google mit derselben E-Mail-Adresse wie in seinem Passwortkonto, es besteht jedoch noch keine Anbieterzuordnung. Nutzen Sie den oben beschriebenen Prozess zum Nachweis der Kontoinhaberschaft und prüfen Sie anschließend, ob die Zuordnung auf den ursprünglichen Kundendatensatz verweist. Prüfen Sie Kundengruppe, Freigabestatus und ERP-Referenz ebenso wie die sichtbare Bestellhistorie.

Wiederholen Sie den Test mit einer neuen Anbieteridentität, deren E-Mail-Adresse keinem Konto entspricht. Die Authentifizierung muss Ihren normalen Regeln für die Geschäftskundenregistrierung folgen: Der Nachweis der Kontrolle über ein Google-Konto erteilt weder eine Geschäftskundenfreigabe noch Sonderpreise. Legt Ihre Anbindung bei der Registrierung ERP-Kunden an, prüfen Sie, dass der Verknüpfungsweg keinen zweiten Neukundenexport sendet. Halten Sie die lokale Kennung des Testkunden im Abnahmeprotokoll fest, damit der Entwickler den verwendeten Datensatz zeigen kann.

Datenschutzentscheidungen und Schaltflächen klar halten

Dokumentieren Sie empfangene Identitäts- und Kontaktdaten, Nutzungszweck, Aufbewahrungsdauer und beteiligte Anbieter. Wählen Sie die passende Rechtsgrundlage und halten Sie optionale Werbeeinwilligung getrennt. Die Freigabe eines Anbieterprofils ist keine Newsletter-Einwilligung.

Fordern Sie nur notwendige Scopes an. Name, E-Mail oder Bild implizieren keine Erlaubnis zur Erhebung von Freunden, Beiträgen oder anderen sachfremden Daten. Wenden Sie Ihren Kontolöschungs- und Aufbewahrungsprozess auf Identitätszuordnungen an und widerrufen Sie gegebenenfalls Zugangsdaten, während gesetzlich erforderliche Unterlagen erhalten bleiben.

Prüfen Sie für die konkrete Installation, ob Drittanbieterskripte oder Speicherung eine Einwilligung erfordern. Testen Sie Ablehnung und Widerruf, wobei normale Anmeldung oder Gastweg weiter nutzbar bleiben. Siehe den PrestaShop-Datenschutzleitfaden zum übergreifenden Shop-Prozess.

Platzieren Sie Schaltflächen auffindbar auf Anmelde- und Registrierungsseiten mit einer klaren normalen Anmeldealternative. Ergänzen Sie Checkout-Anmeldung nur, wenn die Integration den aktuellen Warenkorb erhält und zum richtigen Schritt zurückkehrt. Behaupten Sie nicht, dass Identitätsanmeldung automatisch Lieferadressen ausfüllt.

Verwenden Sie die aktuell genehmigten Schaltflächengrafiken, Beschriftungen und Markenvorgaben jedes Anbieters. Prüfen Sie Berührungsflächen, Tastaturfokus, zugängliche Namen, Kontrast und Rückkehrpfad nach Schließen eines Popups. Testen Sie Mobilgeräte und assistive Technologien, statt ein kleines Logo als eindeutiges Anmeldeelement vorauszusetzen.

Rückkehr ohne Anmeldung untersuchen

Stellen Sie zunächst fest, wo der Ablauf stoppte: vor dem Verlassen des Shops, bei der Anbieterfreigabe, am Callback oder während der lokalen Kontoerstellung. Erfassen Sie Anbieter, Shopdomain, Browser, Startseite, Zeitpunkt und eine von sensiblen Daten bereinigte Fehlerreferenz. Eine korrekt angezeigte Schaltfläche beweist nicht, dass ihr Callback eine Kundensitzung einrichten kann.

Vergleichen Sie nach der Prüfung der registrierten URL den erreichten Callback mit dem Hostnamen, auf dem die Anmeldung begann. Prüfen Sie kanonische Weiterleitungen, die HTTPS-Behandlung des Reverse-Proxys und ob die ursprüngliche Sitzung den Hin- und Rückweg übersteht. Prüfen Sie auf Staging, ob Einwilligungskontrollen ein benötigtes Skript blockieren und ob der Browser einen Popup- oder Speicherfehler meldet. Lassen Sie die Ablehnung ungültiger State-Werte, Nonces und Signaturen während der Ursachenanalyse aktiviert.

Ist die Anbietervalidierung erfolgreich, die Kontoerstellung aber nicht, prüfen Sie Kundenpflichtfelder, individuelle Validierung und Fehler kundenbezogener Module. Unterscheiden Sie diese Fehler von einer Ablehnung durch den Anbieter, damit der Support den richtigen nächsten Schritt anbieten kann, ohne den Kunden um die Wiederholung einer bereits erfolgreichen Autorisierung zu bitten.

Start, Fehler und Kontowiederherstellung testen

Erfassen Sie vor dem Start Registrierungs- und Checkout-Abschluss mit einheitlichen Definitionen. Messen Sie danach gestartete Anbieteranmeldungen, Abschlüsse, Fehler, sicher verknüpfte Konten und Bestellabschluss bei vergleichbaren Besucherströmen. Hohe Nutzung allein beweist nicht, dass die Funktion zusätzliche Verkäufe verursacht hat.

Arbeiten abnehmen und Umschaltung planen

1. Notieren Sie die installierten Versionen von PrestaShop, Theme, Checkout und Anmeldemodul, erforderliche Kundenfelder, Sprachen und Einstellungen zur gemeinsamen Nutzung im Multistore. Erfassen Sie, welche Kundenintegrationen und Einwilligungskontrollen zum Umfang gehören.
2. Sichern Sie die Kontrolle des Unternehmens über den Zugang zu Anbieter-Apps, mit benannten Administratoren und einem Wiederherstellungsweg. Dokumentieren Sie, wer Callback-Einstellungen pflegt, Anbieterhinweise bearbeitet und ablaufende Zugangsdaten einschließlich Apples signiertem Client-Geheimnis erneuert.
3. Bereiten Sie die Staging-Kopie und ihren Anbieterzugang vor. Ist ihr Callback durch Staging-Authentifizierung oder Wartungskontrollen geschützt, richten Sie einen kontrollierten, mit dem Anbieterablauf kompatiblen Zugriff ein, statt die gesamte Kopie zu öffnen.
4. Arbeiten Sie die Szenariotabelle durch und bewahren Sie für jeden relevanten Weg und jedes Gerät ein Ergebnis auf. Nutzen Sie freigegebene Testkonten ohne App-Entwicklerrolle, wenn externer Zugriff nachzuweisen ist. Dokumentieren Sie lokale Kundenkennung, erwartetes und tatsächliches Ergebnis, ohne Tokens oder unnötige personenbezogene Daten zu erfassen.
5. Sichern Sie Konfiguration und Identitätszuordnungen, erproben Sie bei Bedarf die Migration und vereinbaren Sie das Live-Zeitfenster. Stellen Sie die getesteten Dateien und Einstellungen bereit; halten Sie produktive Kunden- und Bestelldaten aktuell, statt die Live-Datenbank durch die Staging-Kopie zu ersetzen.
6. Prüfen Sie produktive Callbacks und die vorgesehene App-Zielgruppe und überwachen Sie anschließend Fehler, doppelte Registrierungen und abgeschlossene Käufe. Geben Sie dem Support den Wiederherstellungsweg über die normale Anmeldung und einen benannten Eskalationskontakt. Wiederholen Sie relevante Prüfungen nach Änderungen an Anbieter, Modul, Theme oder Checkout.

Fragen an den Entwickler oder die Agentur

• Können Sie zeigen, welche Anbieterkennungen welchem Kunden zugeordnet sind, auch nach einem Modulaustausch oder einem Wechsel der Anbieter-App?
• Entfernt das Deaktivieren oder Deinstallieren des Moduls seine Zuordnungen, und wie erhalten Sie nach dem Start angelegte Verknüpfungen, wenn wir die Änderung rückgängig machen?
• Welche Hooks oder Integrationen laufen beim Anlegen oder Verknüpfen eines Kunden, und wie haben Sie Geschäftskundengruppen, Freigaberegeln und Kundenexporte geprüft?
• Wo befinden sich die Abnahmeergebnisse, Angaben zur Inhaberschaft der Anbieterkonten, Erneuerungsanweisungen und bereinigten Diagnosedaten, die unser Support benötigt?

Häufige Fragen von Shopbetreibern

Ist Sign in with Apple dasselbe wie Apple Pay?

Nein. Sign in with Apple authentifiziert ein Kundenkonto; Apple Pay ist eine Zahlungsmethode, die eine Zahlungsintegration verarbeitet. Das Aktivieren der einen Funktion konfiguriert nicht die andere.

Kann ein Ersatzmodul unsere bestehenden Anbieterzuordnungen nutzen?

Nur wenn die Migration die gespeicherten Kennungen und Kontozuordnungen unterstützt. Ein neues Modul kann ein anderes Speicherformat verwenden. Manche Anbieter begrenzen ihre Nutzerkennungen zudem auf eine App oder ein Entwicklerkonto. Ein Wechsel dieser App oder dieses Kontos kann daher neben dem Import der Zuordnungstabelle eine vom Anbieter unterstützte Migration oder eine sichere Kontoverknüpfung erfordern. Verlangen Sie vor der Umschaltung eine Demonstration mit wiederkehrenden Kunden und vereinbaren Sie einen Wiederherstellungsweg für Zuordnungen, die nicht übernommen werden können.

Ordnet die Anmeldung frühere Gastbestellungen einem Kunden zu?

Die Anbieterauthentifizierung allein belegt nicht die Inhaberschaft früherer Gastbestellungen. Fragen Sie, ob Ihr Shop ein unterstütztes Verfahren zur nachträglichen Bestellzuordnung bietet und welche Nachweise es vor der Anzeige dieser Bestellungen verlangt.

Wem sollten die App-Konten bei Google, Meta und Apple gehören?

Ihr Unternehmen benötigt dauerhaften administrativen Zugriff und Wiederherstellungsinformationen, auch wenn eine Agentur die Einrichtung übernimmt. Beziehen Sie Anbieter-Apps in Dienstleisterübergaben und das Ausscheiden von Mitarbeitern ein, damit Zugangsdaten oder Zugriffshinweise beim Entwicklerwechsel nicht bei einer Person verbleiben, die den Shop nicht mehr betreut.