Konfiguracja e-maili w PrestaShop: SMTP, Gmail i wiadomości transakcyjne

Ostatnia weryfikacja: czerwiec 2026, uwzględnia zasady uwierzytelniania dla masowych nadawców Gmail/Yahoo, które weszły w życie w 2024 roku. Limity i cenniki dostawców się zmieniają, dlatego aktualne dane warto potwierdzić bezpośrednio u każdego z nich. Ścieżki w panelu administracyjnym zweryfikowano dla PrestaShop 1.7, 8.x i 9.x.

"Moi klienci nie otrzymują e-maili z potwierdzeniem zamówienia." To jedno z najczęstszych zgłoszeń pomocy technicznej, jakie składa właściciel sklepu PrestaShop, i prawie nigdy nie jest to błąd samego PrestaShop. E-mail wygląda jak najprostsza część prowadzenia sklepu, platforma wysyła potwierdzenie w chwili złożenia zamówienia, ale droga tej wiadomości z serwera do skrzynki klienta prowadzi przez ograniczenia hostingu, rekordy uwierzytelniające i filtry antyspamowe, które potrafią zawieść po cichu. Zamówienie przechodzi, płatność zostaje pobrana, a klient nic nie dostaje. Wtedy pisze do Ciebie albo, co gorsza, uznaje, że zakup się nie udał, i zgłasza obciążenie do zakwestionowania. Ten poradnik dotyczy konkretnie niezawodnego dostarczania e-maili z PrestaShop: dokładnych ustawień w panelu administracyjnym, wyboru dostawcy SMTP, który naprawdę ma znaczenie, rekordów DNS chroniących przed folderem spam oraz sposobu potwierdzenia, że wszystko działa, zanim odkryje to prawdziwy klient.

Dwie metody wysyłki e-maili w PrestaShop, i dlaczego jedna z nich daje złudne poczucie bezpieczeństwa

Otwórz Parametry zaawansowane → E-mail w panelu administracyjnym, a zobaczysz, że PrestaShop oferuje dwa sposoby wysyłania poczty: wbudowaną funkcję PHP mail() oraz opcję "Ustaw własne parametry SMTP". Opcja PHP mail() przekazuje wiadomość do lokalnego agenta pocztowego (Sendmail lub Postfix) działającego na Twoim serwerze WWW. Na papierze to działa. W praktyce, na hostingu współdzielonym i zarządzanym, z którego korzysta większość sklepów PrestaShop, jest to najczęstsza przyczyna problemu "moje e-maile zniknęły":

• Hostingodawcy ją wyłączają. Wielu dostawców całkowicie wyłącza mail(), aby ograniczyć spam wysyłany z przejętych stron. PrestaShop może widzieć jedynie udane lokalne przekazanie wiadomości, końcowe błędy dostarczenia często pojawiają się tylko w logach serwera lub dostawcy, a nie w panelu administracyjnym.
• Często nie zapewnia poprawnego uwierzytelnienia. Samo PHP mail() nie uwierzytelnia nadawcy, więc jeśli serwer/MTA i DNS nie są celowo skonfigurowane, wiadomość wysłana w ten sposób często nie ma prawidłowego dopasowania SPF, DKIM ani DMARC, a współczesne Gmail, Outlook i Yahoo domyślnie traktują nieuwierzytelnioną pocztę od masowego nadawcy jako spam. (Gmail i Yahoo formalnie zaostrzyły te zasady dla masowych nadawców w 2024 roku.)
• Nie daje informacji zwrotnej o dostarczeniu. Funkcja zwraca true albo false przy przekazaniu, nie przy dostarczeniu. "True" mówi tylko, że serwer przyjął wiadomość, a nie że dotarła do skrzynki odbiorczej, została odbita albo odfiltrowana.
• Dziedziczy reputację współdzielonego IP. Na hostingu współdzielonym wysyłasz z adresu IP, z którego korzystają też dziesiątki innych stron; jeśli jedna z nich spamuje, Twoje potwierdzenia zamówień ponoszą tego konsekwencje.

Praktyczny wniosek jest krótki: zawsze używaj SMTP, podłączonego do prawdziwej usługi e-mail. Reszta tego poradnika pokazuje, jak zrobić to poprawnie.

Konfiguracja SMTP w PrestaShop, pole po polu

W Parametry zaawansowane → E-mail wybierz "Ustaw własne parametry SMTP". Zobaczysz poniższe pola. Każdy z opisanych niżej dostawców wypełnia te same miejsca, zmieniają się tylko wartości:

• Serwer SMTP, nazwa hosta dostawcy (na przykład smtp.gmail.com).
• Nazwa użytkownika SMTP, zwykle pełny adres nadawcy, choć niektóre usługi używają stałej wartości tekstowej (SendGrid wymaga słowa apikey).
• Hasło SMTP, hasło do skrzynki, hasło aplikacji albo klucz API, zależnie od dostawcy.
• Szyfrowanie, TLS (port 587) albo SSL (port 465). Nigdy nie wybieraj "Wyłączone"; wtedy dane logowania są przesyłane przez internet jawnym tekstem.
• Port SMTP, 587 dla TLS (współczesne ustawienie domyślne) albo 465 dla SSL.

Co zyskujesz, gdy ustawisz to poprawnie? Połączenie uwierzytelniające Cię jako prawidłowego nadawcę, czyli warunek konieczny dla wszystkiego, co dzieje się dalej, podpisywania DKIM, trafiania do skrzynki odbiorczej i panelu dostawcy, który naprawdę pokazuje, co stało się z każdą wiadomością. Poniżej są trzy poziomy dostawców, na których najczęściej kończą sklepy PrestaShop.

SMTP Gmail, dobry dla małego sklepu, ale z twardym limitem

Gmail jest najczęstszym pierwszym wyborem, bo właściciel sklepu już ma konto. Ustawienia:

Aby wygenerować Hasło aplikacji: na koncie Google przejdź do Bezpieczeństwo → Weryfikacja dwuetapowa → Hasła aplikacji, utwórz hasło dla "Poczta" / "Inne (nazwa własna)" z etykietą "PrestaShop" i wklej 16-znakowy ciąg w polu hasła SMTP w PrestaShop. Najpierw musi być włączona Weryfikacja dwuetapowa, bez tego Google nie pokaże opcji Haseł aplikacji.

Problemem jest wolumen. Darmowe konto Gmail ma limit około 500 odbiorców dziennie; Google Workspace podnosi go do około 2 000. Każde zamówienie w PrestaShop zwykle uruchamia dwa lub trzy e-maile, potwierdzenie dla klienta, powiadomienie administratora i późniejsze powiadomienie o wysyłce, więc sklep obsługujący ponad 100 zamówień dziennie może zbliżyć się do limitu darmowego Gmaila, a po jego przekroczeniu wiadomości zaczynają być opóźniane albo odrzucane bez oczywistego sygnału w panelu administracyjnym. Gmail to dobry start, nie rozwiązanie docelowe.

SMTP Outlook / Microsoft 365

Microsoft stopniowo ogranicza podstawowe uwierzytelnianie SMTP, dlatego w wielu tenantach trzeba najpierw wyraźnie włączyć Authenticated SMTP dla skrzynki w centrum administracyjnym Exchange, zanim PrestaShop będzie mógł się połączyć. Jeśli test połączenia z Microsoft 365 kończy się niepowodzeniem mimo poprawnych danych logowania, ten przełącznik jest zwykle przyczyną.

Usługi e-maili transakcyjnych, właściwa odpowiedź, gdy pojawia się realny wolumen

Po przekroczeniu kilku setek wiadomości dziennie przejdź na usługę zbudowaną do wysyłki transakcyjnej: SendGrid, Mailgun, Brevo lub Amazon SES. Dostajesz dedykowaną reputację nadawczą, automatyczną obsługę odbić i skarg oraz panel dostarczalności, rzeczy, których Gmail nie zapewnia. Przykład na SendGrid:

Ceny i limity darmowych planów się zmieniają, więc sprawdzaj aktualną stronę dostawcy zamiast ufać liczbie z artykułu blogowego, ale przewaga konstrukcyjna pozostaje ta sama: adres IP do wysyłki, którego reputacją aktywnie zarządzasz Ty i dostawca, dane o odbiciach wracające do Ciebie oraz status dostarczenia dla każdej wiadomości. W każdym sklepie, w którym brak potwierdzenia zamówienia oznacza zgłoszenie do obsługi albo chargeback, właśnie ta widoczność jest najważniejsza.

Uwierzytelnianie poczty: SPF, DKIM i DMARC

Poprawne ustawienia SMTP wypychają wiadomość na zewnątrz. Trzy rekordy DNS decydują, czy serwer odbiorcy ufa jej na tyle, aby umieścić ją w skrzynce odbiorczej. Bez nich nawet idealnie skonfigurowane SMTP ląduje w spamie, to druga najczęstsza skarga dotycząca e-maili po "nic się w ogóle nie wysyła" i, w przeciwieństwie do ustawień PrestaShop, te rekordy znajdują się w DNS Twojej domeny, a nie w panelu administracyjnym.

SPF. Kto może wysyłać w Twoim imieniu

SPF (Sender Policy Framework) to rekord DNS TXT z listą serwerów uprawnionych do wysyłania poczty dla Twojej domeny. Serwer odbiorcy sprawdza go, aby potwierdzić, że wiadomość przyszła z autoryzowanego źródła. Typowy rekord dla sklepu wysyłającego przez Google i SendGrid:

v=spf1 include:_spf.google.com include:sendgrid.net ~all

Uwzględniaj tylko usługi, z których naprawdę wysyłasz. Każdy dodatkowy include lekko osłabia rekord, a SPF ma twardy limit 10 zapytań DNS, po którym po prostu przestaje przechodzić weryfikację.

DKIM, podpis potwierdzający, że wiadomość nie została zmieniona

DKIM (DomainKeys Identified Mail) dodaje do każdej wiadomości podpis kryptograficzny, który potwierdza, że pochodzi z Twojej domeny i nie została zmieniona po drodze. Klucz generuje dostawca; Ty publikujesz go jako rekord TXT albo CNAME. Dla Google Workspace na własnej domenie włączysz to w Aplikacje → Google Workspace → Gmail → Uwierzytelnij e-mail. W SendGrid użyj Settings → Sender Authentication → Authenticate Your Domain, co wygeneruje rekordy CNAME do dodania w DNS.

DMARC, co zrobić z pocztą, która nie przejdzie dwóch pierwszych kontroli

DMARC łączy SPF i DKIM oraz mówi odbiorcom, jak traktować wiadomości, które nie przejdą weryfikacji. Zacznij od trybu monitorowania, żeby niczego nie zepsuć:

v=DMARC1; p=none; rua=mailto:dmarc-reports@yourdomain.com

To raportuje niepowodzenia bez blokowania czegokolwiek. Po kilku tygodniach czystych raportów zaostrz politykę do p=quarantine (kierowanie niepoprawnych wiadomości do spamu), a docelowo do p=reject (blokowanie ich). Przejście od razu na p=reject, zanim potwierdzisz, że Twoja legalna poczta przechodzi, to sposób, w jaki sklepy przypadkowo blokują własne potwierdzenia zamówień.

Poprawny adres "From" (cichy zabójca dostarczalności)

Adres nadawcy w PrestaShop ustawia się w Parametry sklepu → Kontakt → Sklepy (oraz w adresie kontaktowym dla danego sklepu). Subtelny, ale bardzo częsty błąd: ten adres "From" musi być zgodny z domeną uwierzytelnioną dla SMTP. Wysyłanie jako info@yourstore.com przy jednoczesnym uwierzytelnianiu przez smtp.gmail.com tożsamością @gmail.com tworzy niedopasowanie uwierzytelnienia, które SPF/DMARC oznaczy, a Twoja poczta trafi do spamu, choć każde pojedyncze ustawienie "wygląda" poprawnie. Domena nadawcy, tożsamość SMTP i rekordy uwierzytelniające powinny wskazywać to samo miejsce.

Udowodnij, że działa, zanim klient udowodni, że nie działa

Nie ufaj ekranowi ustawień tylko dlatego, że pokazuje "zapisano". Przetestuj rzeczywistą ścieżkę dostarczenia:

• Wbudowany test PrestaShop. Na stronie Parametry zaawansowane → E-mail znajduje się pole "Wyślij testową wiadomość e-mail", wyślij ją do siebie i potwierdź, że trafia do skrzynki odbiorczej, nie do spamu.
• mail-tester.com. Wyślij wiadomość na adres, który pokazuje serwis; otrzymasz ocenę SPF, DKIM, DMARC, treści i obecności na czarnych listach w skali do 10. Celuj w 9+ zanim uznasz temat za zamknięty.
• Testuj u różnych dostawców. Wyślij osobno na Gmail, Outlook/Hotmail i Yahoo, ich reguły antyspamowe się różnią, a przejście jednego testu nie oznacza przejścia wszystkich trzech.
• Czytaj nagłówki. W odebranej wiadomości Gmail kliknij trzy kropki → Pokaż oryginał i szukaj SPF: PASS, DKIM: PASS oraz DMARC: PASS. Jeśli gdziekolwiek widzisz FAIL albo NONE, popraw odpowiedni rekord DNS przed uruchomieniem wysyłki na żywo.

E-maile transakcyjne i marketingowe, trzymaj je na osobnych torach

Ten poradnik dotyczy e-maili transakcyjnych: potwierdzeń zamówień, powiadomień o wysyłce, resetowania haseł, wiadomości, które PrestaShop wysyła automatycznie jako bezpośredni skutek działania klienta. Traktuj je jako inny strumień niż newslettery i promocje marketingowe, bo mieszanie ich kosztuje:

• Zanieczyszczenie reputacji. Jeśli newsletter zbiera zgłoszenia spamu i jedzie na tym samym IP/domenie co potwierdzenia zamówień, ściąga w dół także te potwierdzenia.
• Inne zasady prawne. Poczta transakcyjna nie wymaga linku rezygnacji z subskrypcji (jest potrzebna do realizacji zakupu); poczta marketingowa prawnie go wymaga. Rozdzielenie tych strumieni utrzymuje wyraźną granicę zgodności.
• Skoki wolumenu. Wysyłka newslettera do 50 000 odbiorców może zapchać współdzielone połączenie SMTP i opóźnić pilne potwierdzenie zamówienia, na które czeka klient.

Dobra praktyka: wysyłaj pocztę transakcyjną PrestaShop przez swoją usługę SMTP, a newslettery prowadź z dedykowanej platformy (Mailchimp, Brevo, Klaviyo). Jeśli chcesz połączyć te dwa światy, na przykład automatycznie dodawać nowego klienta PrestaShop do listy newslettera, zepnij je warstwą automatyzacji zamiast mieszać strumienie wysyłki; bezkodowy sposób opisujemy w Zapier i Make dla PrestaShop, a konkretnie dla wyzwalaczy przepływów pracy w PrestaShop i Zapier bez pisania kodu.

Lista diagnostyczna dla problemu "e-mail się nie wysyła"

To przypadki, które najczęściej widzimy, gdy sprzedawcy proszą nas o sprawdzenie niedziałających e-maili w PrestaShop, mniej więcej w kolejności, w jakiej warto je weryfikować.

Nic nie wysyła się w ogóle

• Najpierw sprawdź log e-maili. Gdy logowanie jest włączone, Parametry zaawansowane → E-mail pokazuje wiadomości, które PrestaShop próbował wysłać (odbiorca, szablon, temat, czas). Jeśli wiadomości są w logu, ale nie dochodzą, PrestaShop je generuje i przekazuje dalej, a problem jest niżej w ścieżce (uwierzytelnianie albo spam). Jeśli w logu nie ma nic, wysyłka pada wcześniej, ponownie sprawdź host SMTP, port i dane logowania oraz upewnij się, że samo logowanie jest włączone.
• Przetestuj dane logowania bezpośrednio. Zaloguj się do skrzynki albo konsoli dostawcy dokładnie tą nazwą użytkownika i hasłem, które wklejasz do PrestaShop. Jeśli Tobie się nie uda, PrestaShop też się nie uda.
• Sprawdź, czy port nie jest blokowany przez firewall. Niektórzy hostingodawcy blokują połączenia wychodzące 587/465. Jeśli test połączenia kończy się timeoutem, poproś hosting o potwierdzenie, że te porty są otwarte dla ruchu wychodzącego.

Poczta się wysyła, ale trafia do spamu

• Brakujący albo nieprzechodzący SPF/DKIM. Sprawdź w mxtoolbox.com, czy oba rekordy istnieją i przechodzą weryfikację dla Twojej domeny.
• Niedopasowany adres From. Zobacz sekcję "From" powyżej, to najczęściej pomijana przyczyna spamu.
• Spamowa treść szablonu. Natarczywy język typu "za darmo / rabat / działaj teraz" oraz słaby stosunek tekstu do obrazów w własnych szablonach uruchamiają filtry treści.

Problemy występują sporadycznie

• Limity wysyłki. Przekraczasz dzienny limit wysyłki dostawcy; porównaj rzeczywisty wolumen z limitem planu i zmień plan albo dostawcę, jeśli sklep już z niego wyrósł.
• Timeouty połączenia. Wolny serwer SMTP może przekroczyć domyślny timeout połączenia w PrestaShop, jego podniesienie (na przykład z 5 do 20 sekund) często usuwa niestabilne wysyłki.

Wysłano pomyślnie, ale klient twierdzi, że nic nie dostał

Sprawdź adres klienta pod kątem literówki, przejrzyj log odbić u dostawcy i poproś klienta, żeby zajrzał do spamu oraz dodał Twój adres nadawcy do zaufanych. "Wysłano" w PrestaShop oznacza tylko, że wiadomość została przyjęta przez serwer SMTP, to w panelu dostawcy zobaczysz, czy została odbita. Gdy potwierdzisz, że adres jest poprawny i przyczyna problemu z dostarczalnością została usunięta, warto ponownie wysłać to konkretne potwierdzenie zamiast zostawiać klienta bez wiadomości: nasz moduł Resend Order Confirmation ponownie wysyła potwierdzenie zamówienia bezpośrednio ze strony zamówienia, dzięki czemu pojedyncze niedostarczenie nie zamienia się w ręczne odtwarzanie e-maila.

Dostosowywanie szablonów e-maili PrestaShop

Szablony e-maili PrestaShop mogą znajdować się w kilku lokalizacjach mails/<language_code>/, w rdzeniu, motywie i katalogach poczty modułów, zależnie od wersji, motywu i zainstalowanych modułów, każdy typ jako plik HTML oraz tekstowa kopia TXT. Nowsze wersje (1.7/8/9) pozwalają też edytować wygląd w Projekt → Motyw e-mail. Kilka zasad, które pomagają własnym szablonom renderować się wszędzie:

• Używaj inline CSS, wielu klientów pocztowych usuwa bloki <style>.
• Układaj treść za pomocą tabel; renderowanie HTML w e-mailach w praktyce utknęło w 2005 roku.
• Utrzymuj szerokość poniżej 600px dla urządzeń mobilnych.
• Testuj w kilku klientach (Gmail w przeglądarce, Outlook desktop, Apple Mail, mobile).
• Nigdy nie usuwaj placeholderów takich jak {firstname}, {lastname} czy {order_name}, PrestaShop podstawia w ich miejsce prawdziwe dane w momencie wysyłki, a ich usunięcie psuje scalanie.

Logowanie i rzeczywiste monitorowanie dostarczeń

Gdy logowanie e-maili jest włączone, PrestaShop zapisuje każdą próbę wysyłki w bazie danych, widoczną w Parametry zaawansowane → E-mail, wraz z odbiorcą, użytym szablonem, językiem, tematem i czasem wysłania. Pamiętaj jednak, co oznacza wpis na tej liście: PrestaShop przekazał wiadomość do serwera SMTP. To nie jest dowód dostarczenia do skrzynki odbiorczej, a log nie zawiera statusu delivered/bounced dla pojedynczej wiadomości. Tę informację znajdziesz dopiero w panelu dostawcy, SendGrid, Mailgun i Amazon SES raportują dla każdej wiadomości statusy delivered, bounced, deferred oraz wskaźniki skarg. Zaglądaj tam co tydzień; rosnący wskaźnik odbić to wczesny sygnał, że tworzy się problem z dostarczalnością, zanim zaczną zauważać go klienci.

Najczęściej zadawane pytania

Dlaczego e-maile z potwierdzeniem zamówienia PrestaShop nie są dostarczane?

Najczęstszą przyczyną jest używanie PHP mail() na hostingu, który tę funkcję wyłącza albo wysyła nią nieuwierzytelnioną pocztę, współczesne Gmail, Outlook i Yahoo wrzucają nieuwierzytelnioną pocztę masową do spamu. Przełącz się na "Ustaw własne parametry SMTP" w Parametry zaawansowane → E-mail, podłącz prawdziwą usługę e-mail i opublikuj rekordy SPF, DKIM oraz DMARC. Potem potwierdź ścieżkę testem, zanim powierzysz jej prawdziwe zamówienia.

Jakiego portu SMTP i szyfrowania użyć?

Port 587 z TLS to współczesne ustawienie domyślne i rekomendacja większości dostawców; port 465 z SSL jest starszą alternatywą i nadal działa. Nigdy nie wybieraj "Wyłączone", wtedy dane logowania lecą bez szyfrowania. Jeśli test połączenia kończy się timeoutem na którymkolwiek porcie, hosting może blokować wychodzące SMTP i trzeba poprosić go o otwarcie ruchu.

Czy mogę po prostu używać konta Gmail do wysyłania e-maili sklepu?

W małym sklepie tak, użyj smtp.gmail.com na porcie 587/TLS z 16-znakowym Hasłem aplikacji (nie hasłem logowania; najpierw musi być włączona Weryfikacja dwuetapowa). Darmowe konto Gmail ma jednak limit około 500 odbiorców dziennie, a Workspace około 2 000. Ponieważ każde zamówienie uruchamia dwa lub trzy e-maile, sklep powyżej ~100 zamówień dziennie uderzy w ten limit i poczta zacznie być po cichu opóźniana. Gmail to dobry start, nie rozwiązanie docelowe, przy większym wolumenie przejdź na SendGrid, Mailgun, Brevo albo Amazon SES.

E-mail się wysyła, ale trafia do spamu. Co jest nie tak?

Prawie zawsze chodzi o brakujące albo nieprzechodzące uwierzytelnianie lub niedopasowany adres From. Sprawdź, czy SPF i DKIM istnieją oraz przechodzą weryfikację (mxtoolbox.com), i upewnij się, że domena adresu "From" zgadza się z domeną, przez którą uwierzytelniasz SMTP, wysyłanie jako info@yourstore.com przy uwierzytelnianiu tożsamością @gmail.com zostanie oznaczone przez SPF/DMARC i zrzucone do spamu, nawet jeśli każde ustawienie "wygląda" poprawnie.

Klient twierdzi, że nigdy nie dostał potwierdzenia, co teraz?

Najpierw potwierdź, że to faktycznie brak dostarczenia: sprawdź adres pod kątem literówki i log odbić u dostawcy ("Wysłano" w PrestaShop oznacza tylko, że serwer SMTP przyjął wiadomość, nie że została dostarczona). Usuń przyczynę problemu z dostarczalnością, a potem ponownie wyślij to konkretne potwierdzenie zamiast zostawiać klienta bez wiadomości, Resend Order Confirmation ponownie uruchamia wysyłkę ze strony zamówienia jednym kliknięciem.

Czy potwierdzenia zamówień i newsletter powinny iść przez tę samą usługę?

Nie, trzymaj je na osobnych torach. Jeśli newsletter zbiera zgłoszenia spamu i współdzieli IP/domenę z pocztą transakcyjną, ściąga w dół także potwierdzenia zamówień. Wysyłaj pocztę transakcyjną przez usługę SMTP, a newslettery prowadź z dedykowanej platformy (Mailchimp, Brevo, Klaviyo). Jeśli trzeba, połącz te dwa światy warstwą automatyzacji zamiast mieszać strumienie wysyłki.

Gdzie e-mail mieści się w sklepie, który wyrasta z ręcznej pracy

Niezawodna poczta transakcyjna to fundament, ale rzadko jest jedynym miejscem, w którym rosnący sklep traci czas i informacje. To samo zdarzenie zamówienia, które uruchamia e-mail z potwierdzeniem, zwykle musi też trafić do systemu księgowego, a z czasem do ERP, ręczne kopiowanie tych danych to dokładnie ten rodzaj pracy, który przestaje działać przy większym wolumenie. Jeśli jesteś już na etapie, w którym e-maile z zamówień są uporządkowane, ale reszta zaplecza nadal działa na kopiuj-wklej, następne elementy układanki to:

• Księgowość. Automatyczne przekazywanie danych faktury z każdego zamówienia do Xero lub QuickBooks zamiast ręcznego przepisywania, zobacz łączenie PrestaShop z oprogramowaniem księgowym.
• ERP. Gdy stany magazynowe, zamówienia i klienci muszą pozostawać zsynchronizowani z systemem zaplecza, wzorce integracji, które naprawdę się sprawdzają, opisujemy w PrestaShop-to-ERP integration patterns, a sygnały, że nadszedł czas, w Gdy ręczna obsługa przestaje wystarczać Twojemu sklepowi.
• Łączniki no-code. Dla lżejszych połączeń, dodania nowego klienta do listy, wysłania zamówienia do narzędzia, zobacz Zapier i Make dla PrestaShop.

Dostarczalność e-maili nie jest efektowna i właśnie dlatego bywa zaniedbywana, dopóki klient bez potwierdzenia nie otworzy sporu. Przenieś SMTP do prawdziwego dostawcy, opublikuj rekordy SPF, DKIM i DMARC, dopasuj adres "From" i przetestuj całą ścieżkę, zanim powierzysz jej zamówienia na żywo. Moduły rozszerzające możliwości zarządzania sklepem i integracji w PrestaShop, budowane tak, aby przetrwać aktualizacje wersji PrestaShop i PHP, zamiast zepsuć się przy kolejnej, znajdziesz w katalogu na mypresta.rocks.