Zahlungen einrichten — und der eine Schritt, der still Geld verliert — Dokumentation

Zahlungs-Zugangsdaten sind rein serverseitig: Sie werden verschlüsselt auf dem Server gespeichert und niemals in der Datenbank im Klartext, niemals in einem gespeicherten Wert angezeigt. Das ist Absicht. Es folgt, wohin jeder Wert gehört — und der eine Schritt, der leicht zu übersehen und teuer zu übersehen ist.

Der Schritt, der Geld kostet, wenn Sie ihn überspringen

Die meisten indonesischen Zahlungsmethoden sind asynchron. Ein Käufer wählt ein virtuelles Konto, eine E-Wallet oder zahlt in einem Einzelhandelsgeschäft und schließt dann den Tab. Er zahlt vielleicht eine Stunde später fertig, aus seiner Banking-App, auf einem anderen Gerät. Nichts davon kehrt je zu Ihrer Website zurück.

Der Kauf wird also dadurch abgeschlossen, dass der Anbieter Ihren Server anruft — ein Webhook — und durch nichts sonst.

Wenn dieser Anruf nie ankommt:

erreicht das Geld des Käufers Sie,
seine Lizenz wird nie ausgestellt,
die Bestellung steht auf „pending",
und nirgendwo sagt irgendetwas, warum.

Das ist kein seltener Randfall. Bei den indonesischen Methoden ist es der normale Weg.

Woher jeder Anbieter seine URL bekommt

Anbieter	Webhook-URL	Wer sie setzt
Xendit	`https://yourdomain/webhooks/xendit`	Sie, von Hand, einmalig
PayPal	(keine)	nicht nötig — es wird bei der Rückkehr abgeschlossen

PayPal wird abgeschlossen, wenn der Käufer zurückkommt, sodass es gar keinen Webhook braucht. Xendit ist das, das Sie braucht — siehe unten.

Xendit ist das, das Sie braucht. Sein „invoice paid"-Callback ist kontoweit, nicht pro Rechnung, sodass er einmalig in Xendits eigenem Dashboard gesetzt wird.

Xendit, Klick für Klick

Melden Sie sich bei dashboard.xendit.co an.
Settings → Developers → Webhooks.
Fügen Sie unter Invoices paid die URL ein, die Ihre Admin-Seite für Xendit anzeigt (https://yourdomain/webhooks/xendit).
Speichern und kopieren Sie das webhook verification token, das auf derselben Seite angezeigt wird.
Legen Sie dieses Token in der .env Ihres Servers als XENDIT_CALLBACK_TOKEN ab, neben XENDIT_SECRET_KEY.
Starten Sie die Website neu, damit die neuen Werte gelesen werden.

Beide Hälften sind erforderlich. Die URL ohne das Token bedeutet, dass Zustellungen ankommen und abgelehnt werden; das Token ohne die URL bedeutet, dass überhaupt nichts ankommt.

Beweisen, dass es wirklich funktioniert

Vertrauen Sie nicht auf „ich habe es eingefügt". Öffnen Sie Admin → Settings → Payment webhooks. Es meldet, was tatsächlich Ihren Server erreicht hat:

Was es sagt	Was es bedeutet	Was zu tun ist
Never received	Von diesem Anbieter ist noch nie etwas angekommen	Die URL fehlt oder ist im Dashboard des Anbieters falsch
Not matching	Zustellungen kommen an, nennen aber keine Bestellung von Ihnen	Die URL zeigt aus einem anderen Anbieterkonto auf Sie als das, das der Shop verwendet
Working	Mindestens eine Zustellung passte zu einer echten Bestellung	Nichts — es ist verkabelt

Die Zähler bewegen sich nur für Anrufe, die die eigenen Zugangsdaten des Anbieters tragen, sodass ein zufälliger Probe-Zugriff aus dem Internet ein nicht konfiguriertes Gateway niemals gesund aussehen lassen kann.

Testen Sie es durchgängig, bevor Sie echtes Geld annehmen. Xendits Dashboard hat auf derselben Seite eine „test webhook"-Schaltfläche; verwenden Sie sie und laden Sie dann die Admin-Karte neu. Sagt sie weiterhin Never received, ist die URL falsch — prüfen Sie auf einen Tippfehler, ein fehlendes https:// oder einen abschließenden Schrägstrich.

Die Zugangsdaten selbst

Es gibt zwei Wege, sie zu setzen. Beide halten das Geheimnis außer Sicht — keiner zeigt je einen gespeicherten Wert.

Über die Admin-Seite (empfohlen)

Admin → Settings → Payment gateway credentials. Geben Sie die PayPal Client ID + Secret (und den sandbox/live-Schalter) sowie den Xendit Secret Key + Callback-Token ein. Sie werden verschlüsselt auf dem Server gespeichert; die Felder sind nur schreibbar, sodass sie nach dem Speichern nie wieder angezeigt werden — die Seite zeigt nur Configured / Not set. Lassen Sie ein Feld leer, um es unverändert zu lassen; verwenden Sie Remove stored credentials, um eines zu löschen.

Einmalige Einrichtung: Erzeugen Sie den Schlüssel, der sie verschlüsselt, getrennt vom App-Schlüssel gehalten, sodass ein Datenbank-Dump und ein .env-Leck jeweils für sich allein nutzlos sind:

php artisan store:secrets-key      # writes STORE_SECRETS_KEY to .env — then BACK IT UP off the server
php artisan config:clear

Der Verlust von STORE_SECRETS_KEY macht gespeicherte Zugangsdaten unlesbar (Sie würden sie einfach neu eingeben).

Oder über `.env` (Alternative)

Wenn Sie es vorziehen, setzen Sie sie stattdessen in der .env auf dem Server und starten dann neu. Werte von der Admin-Seite haben Vorrang, wenn beide vorhanden sind.

# Xendit
XENDIT_SECRET_KEY=...
XENDIT_CALLBACK_TOKEN=...     # from Settings → Developers → Webhooks

# PayPal
PAYPAL_CLIENT_ID=...
PAYPAL_SECRET=...
PAYPAL_ENV=sandbox           # or: live

Ein Gateway ohne Zugangsdaten ist schlicht ausgeschaltet — es gibt nichts weiter zu aktivieren.

Wenn Ihr Server hinter einem Proxy oder einer Firewall steht

Der Webhook-Pfad ist eine öffentliche, Server-zu-Server-URL. Er hat notwendigerweise kein Login — der Anbieter kann sich nicht als Sie anmelden. Er ist stattdessen durch die eigene Signatur oder das Token des Anbieters geschützt, durch ein autoritatives erneutes Auslesen des Zahlungsstatus direkt vom Anbieter und durch eine Rate-Begrenzung.

Das bedeutet, POST /webhooks/* muss aus dem öffentlichen Internet erreichbar sein. Blockieren Sie ihn oder setzen Sie die gesamte Website hinter eine IP-Positivliste, hören asynchrone Zahlungen auf, erfüllt zu werden — mit genau demselben stillen Symptom, als hätten Sie die URL nie konfiguriert.

Zahlungen einrichten — und der eine Schritt, der still Geld verliert