Zahlungen und E-Mail-Versand

Wie Shops ihre eigenen Stripe- und PayPal-Konten verbinden und wie der echte Mail-Versand (Brevo) eingerichtet wird.

#Online-Zahlungen mit eigenen Konten

Jeder Shop verbindet seine eigenen Konten; das Geld läuft nie über die Plattform.

Shop-Dashboard (Einstellungen → Zahlungen, Inhaber/Admin)
   │  Schlüssel einmalig, per Callback-Token
   ▼
Plattform  POST /api/v1/shops/:id/payments
   ├─ prüft die Schlüssel beim Anbieter (Stripe /v1/account, PayPal OAuth)
   ├─ legt den Webhook an:  https://api.<shop>/hooks/payment/stripe_stripe
   │                         https://api.<shop>/hooks/payment/paypal_paypal
   ├─ schreibt STRIPE_* bzw. PAYPAL_* in die Umgebung des Shop-Stacks
   ├─ deployt den Stack (rollend, ohne Ausfall)
   └─ speichert nur den Status (Modus, Konto, Webhook-ID) in shop_payment_accounts
Medusa  registriert den Provider beim Start; der Job payment-setup verknüpft ihn
        in der nächsten Minute mit allen Regionen → erscheint an der Kasse

Anbieter	Medusa-Provider	Umgebung
Stripe	`@medusajs/medusa/payment-stripe` → `pp_stripe_stripe`	`STRIPE_API_KEY`, `STRIPE_PUBLISHABLE_KEY` (Storefront), `STRIPE_WEBHOOK_SECRET`
PayPal	`@alphabite/medusa-paypal` → `pp_paypal_paypal`	`PAYPAL_CLIENT_ID` (auch Storefront), `PAYPAL_CLIENT_SECRET`, `PAYPAL_SANDBOX`, `PAYPAL_WEBHOOK_ID`

Stripe: Payment Element mit automatischen Zahlungsmethoden; Abbuchung beim Bestellen (STRIPE_CAPTURE=manual nur reservieren).
PayPal: Die Storefront lädt das offizielle JS-SDK von paypal.com und rendert die Buttons für die PayPal-Bestellung der Zahlungssitzung. Nach der Freigabe schließt die Storefront den Warenkorb ab; Medusa erfasst (captured) die PayPal-Bestellung dabei. Lehnt PayPal ab, legt die Storefront eine neue Sitzung an.
Testmodus: Stripe erkennt ihn an sk_test_/pk_test_, PayPal wählt der Händler (Sandbox/Live). Die Plattform prüft, dass beide Stripe-Schlüssel aus demselben Modus stammen und meldet PayPal-Zugangsdaten aus dem anderen Modus.
Trennen (Dashboard oder Agentur → Shop → Betrieb) löscht den Webhook beim Anbieter, leert die Umgebung und deployt.

Hinweis

Nur Shops auf dem Server (Dokploy, https-Adresse der Shop-API) – Webhooks brauchen eine öffentliche https-URL. Lokal trägst du Test-Schlüssel direkt in apps/medusa/.env und apps/storefront/.env ein.

#Echter Mail-Versand (Brevo)

Neue Shops senden in Mailpit (Testpostfach auf dem Shop-Server). Für echten Versand nutzt die Plattform einen SMTP-Anbieter, standardmäßig Brevo (EU, DSGVO).

Bei Brevo die Absenderdomain authentifizieren, z. B. mail.example.com: Brevo zeigt die DNS-Einträge (Brevo-Code, DKIM, DMARC) – im DNS anlegen und in Brevo prüfen lassen.
Unter SMTP & API den SMTP-Login und einen SMTP-Schlüssel erzeugen.

In tools/platform-cli/.env eintragen (gitignored):

tools/platform-cli/.env

bash

MAIL_SMTP_USER=…          # SMTP-Login von Brevo
MAIL_SMTP_PASSWORD=…      # SMTP-Schlüssel
MAIL_DOMAIN=mail.example.com
PLATFORM_MAIL_FROM="Sitelayr <no-reply@mail.example.com>"

Prüfen und übernehmen:
bash
```
pnpm platform mail setup --to du@example.com
```
Die CLI meldet sich per SMTP an, schickt eine Testmail, schreibt SMTP_*/MAIL_FROM (Mails der Plattform) und SHOP_SMTP_*/SHOP_MAIL_DOMAIN (für Shops) in den Plattform-Stack und deployt ihn.
Je Shop: Agentur → Shop → Betrieb → E-Mails → Echten Versand einschalten. Absender ist dann <Shopname> <shop-id@MAIL_DOMAIN>, Antworten gehen an die Kontakt-E-Mail des Shops (Reply-To).

Zuletzt aktualisiert am 8. November 2026

ZurückMonitoring und Fehler