Warum es wichtig ist, Original-Zahlungsformulare zu verwenden

Das Zahlungsformular ist der Punkt, an dem der Benutzer die sensibelsten Daten eingibt: Kartennummer, CVC, Wallet-Logins. Wenn das Formular nicht originell ist (gefälschte Website, „selbst geschriebenes“ Kartenfeld beim Händler statt Hosted-Formular des Anbieters, kaputte Integration), riskieren Sie Datenlecks, Bankausfälle, Chargeback und Sperren. Das ursprüngliche Formular ist die Seite/das Widget des Zahlungsdienstleisters (PSP/Bank), die/das die Sicherheitszertifizierung bestanden hat und mit einem korrekten Skript (iFrame/Hosted Fields/Redirect) verbunden ist.

Was ist die „ursprüngliche Zahlungsform“

Hosted bei PSP: PAN/CVC/Term-Felder - innerhalb des iFrame/Hosted Fields des Anbieters oder auf dessen Domain (Weiterleitung).

PCI-DSS-konform: Der Merchant sieht und speichert keine „rohen“ Kartendaten, erhält nur das Token.

Unterstützt SCA/3-D Secure 2: Bestätigung der Zahlung über die Bank (Push/SMS/Biometrie).

Geschützt durch Protokolle: strenge TLS, HSTS, CSP, Clickjacking-Schutz.

Identifizierbar: korrekte Domain/Zertifikat und berechenbare UX mit Merchant-Details.

Warum es kritisch ist (für Benutzer und Unternehmen)

Für den Benutzer

Kartendatenschutz: Die Tokenisierung und Isolierung der Kartenfelder schließt das „Gucken“ mit Merchant und Skripten aus.

Weniger Phishing und Kontodiebstahl: Der Name des Empfängers und die 3-DS2 bestätigen die Zahlung an Ihre Bank.

Höhere Chancen auf erfolgreiche Bezahlung: korrekte Integration = weniger technische Ausfälle.

Für Unternehmen

Compliance und geringere Strafen: PCI DSS Compliance reduziert die Verantwortung und Kosten für Audits.

Weniger Chargeback: 3-DS2 überträgt die Haftung im Streitfall auf den Emittenten.

Mehr Conversion: Schneller SCA, Apple/Google Pay, gespeicherte Token für One-Click.

Markenschutz: Kein „Formjacking“ (Einbettung bösartiger Skripte) und keine Lecks.

Wie eine richtige Integration aussehen sollte

1. Umleitung auf die Domain PSP oder Hosted Fields/iFrame innerhalb der Merchant-Seite.

2. Die Kartenfelder (PAN/CVC/expiry) gehören technisch zum Anbieter - der Merchant erhält den Token.

3. SCA/3-DS 2 startet automatisch: Push in die Bank-App, Biometrie, SMS-Code.

4. Schutz auf Seitenebene: HSTS, Content Security Policy (CSP), X-Frame-Options, Nonce/Hashes für Skripte.

5. Saubere UX: einzelne Schriftart/Layout oder Marke PSP Widget, korrekte Händler descriptor.

Wie gefährlich sind nicht-originale Formen

Formjacking (Magecart): Bösartige JS entfernen PAN/CVC „on the fly“.

Phishing/Domain-Ersatz: Ähnliche URLs, gefälschte Logos, das „Schloss“ allein garantiert nichts.

Nichteinhaltung des PCI: Geldbußen, obligatorische Audits, Blockierung des Acquirings.

Ausfälle und Einbehaltungen: Emittenten schneiden „graue“ Integrationen, mehr „Nicht ehren“.

KYC-Leaks: Abfrage „Kartenfoto von beiden Seiten“ und Reisepass per E-Mail - grober Verstoß.

Merkmale der Originalform (für den Benutzer)

Die Kartenfelder befinden sich im eingebauten iFrame (Cursor und Rahmen „innerhalb“ des kleinen Fensters) oder man gelangt auf die Domain einer bekannten PSP/Bank.

Adressleiste: HTTPS, gültiges Zertifikat, korrekte Domain ohne Tippfehler.

3-D Secure/SCA erscheint automatisch (Push/SMS/Biometrie von Ihrer Bank).

Keine Anfragen senden PAN/CVC/Foto-Karte zu chat/Mail.

Die Datenschutzerklärung und die Zahlungsbedingungen sind offen und lesbar.

Rote Fahnen (sofort stoppen)

Kartenfelder direkt auf der Merchant-Website ohne iFrame/Hosted Fields.

Bitte PAN/CVC per E-Mail/Messenger oder „Foto der Karte von beiden Seiten“.

Die Domain ist seltsam: 'pay-secure. shop-brand-verify. net 'anstelle der Marken-Domain/PSP.

Die Seite zieht im Bezahlschritt nicht-private Ressourcen (http) oder „schwört“ auf das Zertifikat.

Kaputte Lokalisierung, verpixelte Logos, Fehler, „pay for 2:59“ Timer.

Checkliste für den Nutzer (1 Minute)

Die Zahlung erfolgt über eine Umleitung auf PSP oder iFrame/Hosted Fields.
HTTPS/Zertifikat gültig, Domain ohne Ersatz.
SCA/3-DS2 funktioniert (push/SMS/Biometrie).
Ich schicke keine PAN/CVC/Foto-Karte in den Chat/Mail.
Privacy Policy und Kontakte zur Verfügung zu halten.

Checkliste für Unternehmen (Integration/Sicherheit)

Ich verwende Hosted Fields/iFrame oder PSP-Weiterleitung; merchant sieht PAN/CVC nicht.
PCI DSS: SAQ A/SAQ A-EP nach Integrationsart, Tokenisierung, Netzsegmentierung.
CSP/HSTS/XFO enthalten; externe Skripte - nach allow-list mit Hashes/nonce.
3-DS 2/SCA enthalten ist; fallback на OTP/push; Unterstützung für Wallets (Apple/Google Pay).
Front Change Monitoring (SRI, kanarische Skripte), Schutz vor Formjacking.
Klare Texte: Wer ist Acquirer/PSP, wie werden die Daten verarbeitet, Rückgabefristen.
Regelmäßige Pentests und Abhängigkeitskontrolle (SCA - Software Composition Analysis).

Typische Probleme und wie man sie schnell löst

Symptom	Der Grund	Die Lösung
Viel „Dekliniert/Nicht ehren“	Falsche Integration, fehlende 3-DS2	Aktivieren Sie 3-DS2, überprüfen Sie BIN-Regeln, descriptor und MCC
Kunden klagen über „Freds“	Formjacking/Schadsoftware im Frontend	CSP/SRI aktivieren, Felder in Hosted Fields, Forensik und Schlüsselrotation übersetzen
Bittet um ein Foto der Karte per E-Mail	Falscher Sapport-Prozess	Sofort verbieten; nur über einen sicheren KYC-Provider, ohne PAN/CVC
Die Bank fragt oft nach SCA	Risikosignale/neue Geräte	Orchestrierung einrichten, Token/Geräte speichern, Verhaltensbewertung verbessern

FAQ (kurz)

Schloss in der Adressleiste = sicher?

Nein. Das ist nur Verschlüsselung. Schauen Sie sich die Domain, das Hosted-Formular, die 3-DS2 und die Richtlinien an.

Warum ist iFrame besser als die Felder auf der Website?

Denn PANs/CVCs gehen direkt an die PSP und berühren nicht die Front des Merchants - weniger Risiken und PCI-Anforderungen.

Kann ich Kartendaten per Telefon/Chat abrufen?

Nein. Das ist ein grober PCI-Verstoß. Verwenden Sie den Zahlungslink/die Rechnung mit dem Hosted-Formular.

Wenn das Formular ohne SCA „hängt“?

Neustart, überprüfen Sie Ihr Netzwerk/Browser. Stellen Sie sicher, dass Sie PSP-Popups/Skripte nicht blockieren.

Mini-Politik für das Unternehmen (fertiger Rahmen)

1. Nur Hosted Fields/Weiterleitung für PAN/CVC.

2. 3-DS 2/SCA ist für Karten obligatorisch; Apple/Google Pay verbunden sind.

3. CSP/HSTS/XFO/SRI + strenge allow-list Domains.

4. Überwachung der Front und Alerts auf Ersetzung von Skripten.

5. SAQ/PCI-Audit jährlich; Pentests nach Zeitplan.

6. Sapport fragt nie nach PAN/CVC/Foto-Karte; Nur geschützte KYC-Kanäle.

Die ursprüngliche Zahlungsform ist keine Ästhetik, sondern Sicherheit und Legalität. Hosted Fields, Tokenization und SCA schützen den Karteninhaber, steigern die Konversion und nehmen dem Unternehmen einen erheblichen Teil der Risiken ab. Benutzer - Domain, Formular und SCA überprüfen; Unternehmen - verwenden Sie nur zertifizierte Integrationen mit harten Frontverteidigungen. Wenn Sie diese Regeln befolgen, schließen Sie 90% der Szenarien für Datenlecks und Zahlungsausfälle.