{"content_id":"dtvo1yuy0p","slug":"ai-payment-feature-7-core-decisions","locale":"de","schema_type":"TechArticle","category":"how_to","category_name":"Anleitungen","title":"7 Entscheidungen vor der Entwicklung einer Bezahlfunktion mit KI","summary":"KI kann Zahlungscode schnell erstellen, doch die Sicherheit einer Bezahlfunktion hängt von der Gestaltung von Richtlinien für Bestellstatus, Erstattungsfristen, Teilerstattungen und den Schutz vor Doppelzahlungen ab. Insbesondere koreanische E-Commerce-Dienste müssen Widerrufsrecht, Verzugszinsen bei verspäteten Erstattungen, die Bekanntgabe der Erstattungsbedingungen und die Vermeidung von Dark Patterns klar in den Entwicklungsanforderungen berücksichtigen.","sponsorship_disclosure":null,"author":{"name":"injoys","url":"https://injoys.com/ko/about"},"key_points":["Eine Bezahlfunktion ist nicht nur eine einfache Funktion zur Kartenautorisierung, sondern ein Betriebssystem, das Bestellungen, Abrechnungen, Erstattungen, Kundendienst und rechtliche Hinweise miteinander verbindet.","Bestellstatus wie „Zahlung ausstehend“, „Zahlung abgeschlossen“, „storniert“, „Erstattung läuft“ und „Erstattung abgeschlossen“ müssen so definiert werden, dass Kunden und Betreiber sie gleich verstehen.","Im koreanischen E-Commerce müssen im Allgemeinen die Widerrufsfrist für Verbraucher, die Frist für die Erstattungsabwicklung durch den Anbieter und die Regelungen zu Verzugszinsen berücksichtigt werden.","Zur Vermeidung von Doppelzahlungen reicht es nicht aus, lediglich die Schaltfläche zu deaktivieren; erforderlich sind serverseitige Idempotenzschlüssel, Bestellsperren und Prüfungen auf doppelte Zahlungsautorisierungen.","Gestaltungen, die Erstattungsbedingungen und Stornierungsverfahren verbergen oder Kündigungen erschweren, schaden dem Kundenvertrauen und erhöhen das Risiko einer Regulierung wegen Dark Patterns."],"content_markdown":"## Kernaussagen\n\nDer riskanteste Prompt, wenn eine AI mit der Implementierung einer Zahlungsfunktion beauftragt wird, ist die einfache Aufforderung „Füge eine Zahlungsfunktion hinzu“. Eine Zahlungsfunktion besteht nicht nur aus Code, der Geld entgegennimmt, sondern ist ein Betriebs-, Buchhaltungs- und Kundensupportsystem, das für den Geldfluss verantwortlich ist.\n\nTechnisch kann eine AI die Integration einer Zahlungsseite, den Aufruf einer Autorisierungs-API, den Empfang von Webhooks und die Speicherung von Bestellungen schnell implementieren. Sind jedoch die folgenden Richtlinien nicht festgelegt, können im realen Betrieb Geisterbestellungen, Doppelzahlungen, verzögerte Erstattungen, eine Flut von Kundendienstanfragen und fehlende rechtliche Hinweise auftreten.\n\n| Entscheidungsbereich | Vorab zu klärende Frage | Risiko bei Fehlern |\n|---|---|---|\n| Bestellstatus | Welche Status durchläuft eine Bestellung in welcher Reihenfolge? | Es entstehen Geisterbestellungen, bei denen bezahlt wurde, aber keine Bestellung vorhanden ist |\n| Erstattungsfrist | Wie werden Widerruf und Bearbeitungsfristen für Erstattungen berücksichtigt? | Verletzung gesetzlicher Fristen, Verzugszinsen und Streitrisiken |\n| Teilerstattung | Wie werden die Rückgabe einzelner Artikel, Gutscheine und Versandkosten berechnet? | Jedes Mal manuelle Berechnung durch das Betriebsteam, Misstrauen der Kunden |\n| Doppelzahlung | Wie wird verhindert, dass dieselbe Bestellung zweimal abgerechnet wird? | Kundenbeschwerden aufgrund der Kartenabrechnung, Vertrauensverlust |\n| Fehlermeldung | Wie werden Überschreitung des Limits, unzureichendes Guthaben und fehlgeschlagene Authentifizierung kommuniziert? | Sinkende Konversionsrate bei erneuten Versuchen, mehr unnötige Anfragen |\n| Zahlungsverlauf | Wo können Kunden den Zahlungs- und Erstattungsstatus prüfen? | Mehr Kundendienstanfragen, intransparenter Status |\n| Erstattungshinweis | Wo werden Erstattungsregeln und die Schaltfläche zum Stornieren platziert? | Diskussionen über Dark Patterns, regulatorische Risiken |\n\n## 1. Gestaltung der Bestellstatus: Der Status ist die Sprache des Betriebs\n\nBei der Entwicklung einer Zahlungsfunktion darf es nicht nur einen einzigen Bestellstatus wie „Bestellung abgeschlossen“ geben. Eine reale Bestellung durchläuft mehrere Phasen wie Zahlungsversuch, Autorisierung, Stornierung, Erstattung, Fehlschlag und Ablauf.\n\n### Beispiel für empfohlene Status\n\n| Beispiel für Statuscode | Für Kunden sichtbarer Status | Bedeutung |\n|---|---|---|\n| `payment_pending` | Zahlung ausstehend | Die Bestellung wurde erstellt, aber die Zahlung ist noch nicht abgeschlossen |\n| `paid` | Zahlung abgeschlossen | Die Zahlung wurde autorisiert und die Bestellung ist gültig |\n| `payment_failed` | Zahlung fehlgeschlagen | Der Zahlungsversuch ist fehlgeschlagen und es muss geprüft werden, ob ein erneuter Versuch möglich ist |\n| `cancel_requested` | Stornierung beantragt | Der Kunde hat eine Stornierung beantragt, die noch bearbeitet werden muss |\n| `cancelled` | Stornierung abgeschlossen | Die Stornierung der Bestellung vor der Zahlung oder die Aufhebung der Autorisierung ist abgeschlossen |\n| `refund_requested` | Erstattung beantragt | Nach der Zahlung ist ein Erstattungsantrag eingegangen |\n| `refund_processing` | Erstattung wird bearbeitet | Die Erstattung wird genehmigt oder über das Zahlungsmittel abgewickelt |\n| `partially_refunded` | Teilerstattung abgeschlossen | Nur ein Teil des Bestellbetrags wurde erstattet |\n| `refunded` | Erstattung abgeschlossen | Die Erstattung ist abgeschlossen |\n| `expired` | Bestellung abgelaufen | Die Wartezeit für die Zahlung ist abgelaufen und die Bestellung wurde ungültig |\n\n### Grundsätze für die Statusgestaltung\n\n- Bestellstatus und Zahlungsstatus werden nicht als vollständig identisch betrachtet. Eine Bestellung kann vorhanden sein, obwohl die Zahlung fehlschlägt, und die Zahlung kann autorisiert worden sein, obwohl die Speicherung der Bestellung fehlschlägt.\n- Bei jeder Statusänderung werden Zeitpunkt, Bearbeiter, Grund, Kennung der Zahlungstransaktion und Kennung der Erstattungstransaktion protokolliert.\n- Kundenansicht, Administrationsansicht und Formulierungen des Kundendienstes müssen dieselben Statusdefinitionen verwenden.\n- Statusübergänge werden unidirektional gestaltet. Die Wiederherstellung nach Ausnahmen erfolgt mit gesonderten Administratorrechten und wird protokolliert.\n\n## 2. Widerruf und gesetzliche Erstattungsfrist: keine Richtlinie, sondern eine rechtliche Anforderung\n\nWer in Korea elektronischen Handel mit Verbrauchern betreibt, muss das Gesetz zum Verbraucherschutz im elektronischen Geschäftsverkehr und ähnlichen Bereichen berücksichtigen. Grundsätzlich können Verbraucher innerhalb eines bestimmten Zeitraums widerrufen, und Unternehmen müssen nach einem Erstattungsantrag oder Rückgabeverfahren den Betrag innerhalb der festgelegten Frist zurückzahlen.\n\nIn der Praxis sind insbesondere die folgenden Kriterien wichtig.\n\n- Verbraucher können grundsätzlich innerhalb von 7 Tagen ab dem gesetzlich festgelegten Stichtag, etwa dem Tag des Erhalts der Waren, widerrufen.\n- Unternehmen müssen den Betrag innerhalb der gesetzlichen Frist erstatten, nachdem ein Erstattungsgrund entstanden ist. Bei Verzögerungen können Verzugsentschädigungen oder Verzugszinsen anfallen.\n- Für digitale Inhalte, individuell angefertigte Waren oder Waren, deren Wert durch Nutzung erheblich sinkt, können Ausnahmen gelten. Für die Anwendung einer Ausnahme müssen jedoch Anforderungen wie vorherige Information und Zustimmung sorgfältig geprüft werden.\n- Die konkrete Anwendung kann je nach Produkttyp, Vertragsform, den Verbrauchern erteilten Hinweisen und Beginn der Nutzung variieren. Daher ist eine rechtliche Prüfung erforderlich.\n\n### Umwandlung in Entwicklungsanforderungen\n\nEs reicht nicht aus, gesetzliche Vorgaben nur in den AGB festzuhalten. Sie müssen auch in Systemanforderungen umgesetzt werden.\n\n| Gesetzliche oder richtlinienbezogene Anforderung | Systemanforderung |\n|---|---|\n| Prüfung, ob ein Widerruf innerhalb von 7 Tagen möglich ist | Automatische Berechnung des Erstattungszeitraums anhand des Empfangsdatums der Bestellung oder des Datums der Leistungserbringung |\n| Erstattung innerhalb von 3 Werktagen erforderlich | Anzeige des Erstattungsantragsdatums und der Bearbeitungsfrist in der Administrationsansicht |\n| Risiko einer verzögerten Erstattung | Hinweise bei nahendem und überschrittenem Fristende |\n| Hinweis auf ausgenommene Produkte erforderlich | Vor der Zahlung deutlich darauf hinweisen, dass die Erstattung für das Produkt eingeschränkt ist, und das Zustimmungsprotokoll speichern |\n| Vorbereitung auf Streitfälle erforderlich | AGB-Version, Zeitpunkt des Hinweises, Zeitpunkt der Zustimmung sowie Kunden-IP oder Kontoprotokolle aufbewahren |\n\n## 3. Regeln für Teilerstattungen: Gutscheine, Versandkosten und Steuern vorab definieren\n\nTeilerstattungen sind wesentlich komplexer als vollständige Stornierungen. Werden mehrere Artikel gemeinsam bestellt und nur einige davon zurückgegeben, muss entschieden werden, wie der ursprünglich gewährte Rabatt und die Versandkosten aufgeteilt werden.\n\n### Unbedingt festzulegende Punkte\n\n- Wie der Zahlungsbetrag pro Artikel zugeordnet wird\n- Ob ein Gutschein für die gesamte Bestellung proportional auf die einzelnen Artikel verteilt wird\n- Ob ein Gutschein für einen bestimmten Artikel nur auf diesen Artikel angewendet wird\n- Ob Versandkosten abgezogen werden, wenn die Bedingung für kostenlosen Versand nachträglich nicht mehr erfüllt ist\n- Wie Rücksendekosten bei bloßem Meinungswechsel von Rücksendekosten wegen eines Produktmangels unterschieden werden\n- In welcher Reihenfolge mit Punkten, Guthaben und Geschenkkarten bezahlte Beträge erstattet werden\n- Wie Rechnungen, Barzahlungsbelege und Quittungen nach einer Teilerstattung angepasst werden\n\n### Beispiel für die Berechnung einer Teilerstattung\n\n| Posten | Betrag |\n|---|---:|\n| Artikel A | 30,000원 |\n| Artikel B | 70,000원 |\n| Gutschein für die gesamte Bestellung | -10,000원 |\n| Tatsächlicher Zahlungsbetrag | 90,000원 |\n\nWird der Gutschein proportional zum Warenwert verteilt, entfallen 3,000원 Rabatt auf Artikel A und 7,000원 auf Artikel B. Wird in diesem Fall nur Artikel A erstattet, beträgt der für die Erstattung maßgebliche Betrag nicht 30,000원, sondern 27,000원. Bestehen Bedingungen für kostenlosen Versand, Rücksendekosten oder Einschränkungen für die Erstattung je Zahlungsmittel, kann der endgültige Erstattungsbetrag weiter abweichen.\n\nEs gibt nicht nur eine richtige Antwort. Entscheidend ist, im Voraus einheitliche Regeln festzulegen und sie so bekannt zu geben, dass Kunden sie vor der Zahlung oder vor dem Erstattungsantrag verstehen können.\n\n## 4. Verhinderung von Doppelzahlungen: Das Deaktivieren der Schaltfläche reicht nicht aus\n\nDoppelzahlungen gehören zu den Zahlungsvorfällen, die Kunden am schnellsten bemerken. Kunden sehen die Benachrichtigung über die Kartenautorisierung und die Kartenabrechnung früher als den internen Bestellstatus des Dienstes. Wird dieselbe Bestellung zweimal abgerechnet, sinkt das Vertrauen erheblich.\n\n### Ursachen\n\n- Der Kunde klickt mehrmals hintereinander auf die Zahlungsschaltfläche\n- Der Kunde aktualisiert die Seite unmittelbar nach der Zahlung oder klickt auf „Zurück“\n- Aufgrund einer Verzögerung im Mobilfunknetz wird dieselbe Anfrage erneut gesendet\n- Die Antwort auf die Zahlungsautorisierung ist erfolgreich, aber die Speicherung auf dem Dienstserver schlägt fehl\n- Webhook und Client-Weiterleitung ändern den Bestellstatus gleichzeitig\n\n### Schutzmechanismen\n\n| Schutzmaßnahme | Beschreibung |\n|---|---|\n| Sperrung der Client-Schaltfläche | Verhindert erneutes Klicken nach dem Klick auf die Zahlungsschaltfläche, wird aber nur als ergänzende Maßnahme verwendet |\n| Serverseitige Bestellsperre | Verhindert, dass für dieselbe Bestell-ID gleichzeitig mehrere Anfragen zur Zahlungsautorisierung ausgeführt werden |\n| Idempotenzschlüssel | Verwendet eine Kennung, durch die auch bei mehrmaligem Senden derselben Zahlungsanfrage nur ein Ergebnis erzeugt wird |\n| Eindeutige Transaktionsnummer | Verhindert durch Datenbank-Constraints die doppelte Speicherung von Bestellnummer und Zahlungstransaktionsnummer |\n| Statusbasierte Prüfung | Verhindert zusätzliche Autorisierungsanfragen für Bestellungen, die bereits den Status `paid` haben |\n| Deduplizierung von Webhooks | Stellt sicher, dass eine Statusänderung nur einmal erfolgt, auch wenn dasselbe Webhook-Ereignis mehrfach eingeht |\n\nWenn eine AI mit der Erstellung von Zahlungscode beauftragt wird, sollte nicht nur „Mehrfachklicks verhindern“, sondern ausdrücklich „Zahlungsautorisierung und Abschluss der Zahlungsbearbeitung müssen für dieselbe Bestellung idempotent funktionieren“ vorgegeben werden.\n\n## 5. Hinweise bei Zahlungsfehlern: Ein Fehlschlag ist kein Vorfall, sondern ein normaler Ablauf\n\nZahlungsfehler sind normale Situationen, die täglich auftreten. Überschreitung des Limits, unzureichendes Guthaben, fehlgeschlagene Kartenauthentifizierung, falsches Passwort, fehlgeschlagene 3D Secure-Authentifizierung, ausbleibende Reaktion einer App für vereinfachte Zahlungen und Netzwerkfehler sind allesamt häufige Fälle.\n\nEin schlechter Hinweis endet mit „Es ist ein Fehler aufgetreten“. Der Kunde weiß dann nicht, ob die Zahlung erfolgt ist, ob er erneut klicken darf oder ob die Bestellung verloren geht.\n\n### Beispiele für Hinweise\n\n| Situation | Empfohlener Hinweis |\n|---|---|\n| Unzureichendes Guthaben | Die Zahlung konnte nicht abgeschlossen werden, weil das Guthaben des Zahlungsmittels nicht ausreicht. Wählen Sie ein anderes Zahlungsmittel oder prüfen Sie das Guthaben und versuchen Sie es erneut. |\n| Limit überschritten | Die Zahlung ist fehlgeschlagen, weil das Kartenlimit oder das Limit für eine einzelne Zahlung überschritten wurde. Prüfen Sie das Limit in der App des Kartenanbieters oder bezahlen Sie mit einer anderen Karte. |\n| Authentifizierung fehlgeschlagen | Da die Zahlungsauthentifizierung nicht abgeschlossen wurde, bleibt die Bestellung im Status „Zahlung ausstehend“. Sie können die Zahlung innerhalb von 30 Minuten erneut durchführen. |\n| Netzwerkfehler | Die Bestätigung des Zahlungsergebnisses verzögert sich. Um eine Doppelzahlung zu vermeiden, prüfen Sie bitte nach kurzer Zeit den Zahlungsverlauf. |\n| Bestellung abgelaufen | Die Wartezeit für die Zahlung ist abgelaufen und die Bestellung wurde ungültig. Wählen Sie die Artikel erneut aus und geben Sie eine neue Bestellung auf. |\n\n### Kernelemente eines Hinweises bei Fehlern\n\n- Es wird eindeutig mitgeteilt, ob die Zahlung tatsächlich nicht abgeschlossen wurde.\n- Es wird angegeben, wie lange die Bestellung bestehen bleibt.\n- Es wird erklärt, ob ein erneuter Versuch möglich ist oder ein anderes Zahlungsmittel verwendet werden muss.\n- Die für eine Anfrage beim Kundendienst erforderliche Bestellnummer wird angezeigt.\n- Wenn das Zahlungsergebnis unklar ist, darf nicht bedingungslos zu einer erneuten Zahlung aufgefordert werden. Stattdessen muss der Status „Wird geprüft“ angeboten werden.\n\n## 6. Seite mit dem Zahlungsverlauf: die zentrale Ansicht zur Entlastung des Kundendienstes\n\nOhne eine Seite mit dem Zahlungsverlauf wenden sich Kunden an den Kundendienst, um den Zahlungs-, Stornierungs- oder Erstattungsstatus zu prüfen. Der Zahlungsverlauf ist nicht nur eine einfache Belegansicht, sondern ein Vertrauensinstrument, mit dem Kunden den aktuellen Status ihres Geldes nachvollziehen können.\n\n### Informationen auf der Seite mit dem Zahlungsverlauf\n\n- Bestellnummer\n- Bestellzeitpunkt und Zahlungszeitpunkt\n- Produktname, Menge und Optionen\n- Zahlungsmittel und Autorisierungsnummer oder Transaktionskennung\n- Warenwert, Rabatt, Versandkosten, verwendete Punkte und endgültiger Zahlungsbetrag\n- Aktueller Bestellstatus und Erstattungsstatus\n- Datum des Erstattungsantrags, Datum der Erstattungsgenehmigung und voraussichtliches Abschlussdatum der Erstattung\n- Angabe, ob eine Stornierung oder Erstattung möglich ist\n- Links zu Beleg, Transaktionsübersicht und Barzahlungsbeleg\n- Für Anfragen beim Kundendienst benötigte Informationen\n\n### Verknüpfung mit der Betreiberansicht\n\nKundenansicht und Administrationsansicht müssen dieselben Daten anzeigen. Wenn Kunden „Erstattung wird bearbeitet“ sehen, während in der Administrationsansicht „Bearbeitung abgeschlossen“ steht, wird die Kommunikation des Kundendienstes inkonsistent. Die Statusbezeichnungen können unterschiedlich formuliert werden, aber es darf nur einen internen Statuscode und einen Satz von Übergangsregeln geben.\n\n## 7. Platzierung der Erstattungsregeln: Versteckte Regeln werden zum Risiko\n\nEs reicht nicht aus, die Erstattungsregeln nur in einer Ecke der AGB-Seite zu platzieren. Auf der Seite, auf der Kunden ihre Zahlungsentscheidung treffen, müssen sie den Erstattungszeitraum, Einschränkungen der Erstattung und das Stornierungsverfahren leicht erkennen können.\n\n### Geeignete Stellen für Hinweise\n\n- In der Nähe des Preises oder der Kaufschaltfläche auf der Produktdetailseite\n- Im Warenkorb oder auf der Bestellseite\n- Im Bereich zur Zustimmung zu AGB und Erstattungsregeln direkt oberhalb der Zahlungsschaltfläche\n- Auf der Zahlungsbestätigungsseite\n- In der Bestelldetailansicht des persönlichen Bereichs\n- Auf der Seite für Erstattungsanträge\n\n### Zu vermeidende Gestaltungen\n\n- Eine Gestaltung, bei der Registrierung und Zahlung in einem Schritt möglich sind, Kündigung oder Erstattung jedoch nur telefonisch über den Kundendienst erfolgen können\n- Eine Gestaltung, bei der die Schaltfläche zum Stornieren tief in mehreren Schritten verborgen ist\n- Eine Gestaltung, bei der Einschränkungen der Erstattung erst nach der Zahlung angezeigt werden\n- Eine Gestaltung, bei der Farbe, Formulierung und Reihenfolge der Schaltflächen so angeordnet sind, dass Kunden irregeführt werden\n- Eine Gestaltung, bei der nicht klar auf die automatische Zahlung nach Ende eines kostenlosen Testzeitraums hingewiesen wird\n\nSolche Gestaltungen beeinträchtigen nicht nur das Kundenerlebnis, sondern können auch als Dark Patterns bewertet werden. Insbesondere sollte die Schwierigkeit von Stornierung und Kündigung nicht wesentlich von der Schwierigkeit der Registrierung und Zahlung abweichen.\n\n## Checkliste für einen Prompt an eine AI\n\nWenn ein AI-Entwicklungstool mit der Implementierung einer Zahlungsfunktion beauftragt wird, müssen zunächst die Richtlinien wie folgt übermittelt werden.\n\n### Beispiel für einen Prompt zur Zahlungsfunktion\n\n```text\nImplementiere die Zahlungsfunktion eines koreanischen E-Commerce-Dienstes für Verbraucher.\nBerücksichtige dabei unbedingt die folgenden Richtlinien.\n\n1. Verwende für den Bestellstatus payment_pending, paid, payment_failed, cancel_requested, cancelled, refund_requested, refund_processing, partially_refunded, refunded und expired.\n2. Ändere Bestellungen mit ausstehender Zahlung nach 30 Minuten in expired.\n3. Erlaube für dieselbe Bestellung nur 1 Zahlungsautorisierung und verwende eine serverseitige Bestellsperre sowie einen Idempotenzschlüssel.\n4. Da Zahlungs-Webhooks mehrfach empfangen werden können, darf dieselbe Ereignis-ID nur einmal verarbeitet werden.\n5. Speichere das Datum des Erstattungsantrags, die Bearbeitungsfrist für die Erstattung, den Bearbeiter, den Grund und die Erstattungstransaktionsnummer.\n6. Berechne Teilerstattungen anhand des tatsächlich gezahlten Betrags je Artikel und verteile einen Gutschein für die gesamte Bestellung proportional zum Warenwert.\n7. Gib bei einem Zahlungsfehler je nach Fehlergrund einen entsprechenden Kundenhinweis zurück.\n8. Ermögliche Kunden, im persönlichen Bereich ihren Zahlungsverlauf und Erstattungsstatus zu prüfen.\n9. Zeige vor der Zahlung einen Link zu den Erstattungsregeln und ein Kontrollkästchen zur Zustimmung an und speichere den Zeitpunkt der Zustimmung sowie die AGB-Version.\n10. Wenn Richtlinien nicht festgelegt sind, stelle zuerst Fragen, bevor du Code schreibst.\n```\n\nDer letzte Satz „Wenn Richtlinien nicht festgelegt sind, stelle zuerst Fragen“ ist wichtig. Dadurch kann die AI zu leicht übersehenen Richtlinien wie der automatischen Genehmigung von Erstattungen, den Genehmigungsrechten von Administratoren und der Methode zum Abzug der Versandkosten Rückfragen stellen.\n\n## Erforderliche Funktionen der Betreiberansicht\n\nEine Zahlungsfunktion ist nicht allein mit der Kundenansicht vollständig. Da Erstattungen und Stornierungen täglich anfallende Betriebsaufgaben sind, ist eine Administrationsansicht zwingend erforderlich.\n\n| Administratorfunktion | Grund |\n|---|---|\n| Liste ausstehender Erstattungen | Erforderlich, damit zu bearbeitende Erstattungen nicht übersehen werden |\n| Anzeige der gesetzlichen Bearbeitungsfrist | Erforderlich, um das Risiko verzögerter Erstattungen zu verringern |\n| Warnung bei nahendem oder überschrittenem Fristende | Erforderlich, damit Betreiber interne Vorgaben wie 3 Werktage sofort erkennen |\n| Auswahl des Erstattungsgrunds | Erforderlich für Statistiken und Kostenverteilung, etwa bei Meinungswechsel, Produktmängeln oder Falschlieferungen |\n| Vorschau der Teilerstattungsberechnung | Erforderlich, um manuelle Berechnungsfehler der Betreiber zu reduzieren |\n| Bearbeitungsprotokoll | Erforderlich für Streitfälle und Prüfungen |\n| Rechteverwaltung | Erforderlich, um die Genehmigung von Erstattungen und erzwungene Statusänderungen einzuschränken |\n\n## Mindestumfang des Zahlungsdatenmodells\n\nDie Datenstruktur unterscheidet sich je nach Dienst. Mindestens die folgenden Daten sollten jedoch getrennt gehalten werden.\n\n| Tabelle oder Objekt | Zentrale Felder |\n|---|---|\n| Bestellung | Bestell-ID, Kunden-ID, Bestellstatus, Bestellbetrag, Rabattbetrag, Versandkosten, Erstellungszeitpunkt, Ablaufzeitpunkt |\n| Bestellartikel | Produkt-ID, Produktname, Optionen, Menge, Betrag je Artikel, zugeordneter Rabattbetrag je Artikel |\n| Zahlung | Zahlungs-ID, Bestell-ID, Zahlungsmittel, Autorisierungsnummer, autorisierter Betrag, Zahlungsstatus, Autorisierungszeitpunkt |\n| Erstattung | Erstattungs-ID, Bestell-ID, Erstattungsbetrag, Erstattungsgrund, Erstattungsstatus, Antragszeitpunkt, Abschlusszeitpunkt |\n| Statusverlauf | Ziel-ID, vorheriger Status, neuer Status, Ändernder, Änderungsgrund, Änderungszeitpunkt |\n| Zustimmung zu AGB | Art der AGB, AGB-Version, Zustimmungsstatus, Zustimmungszeitpunkt, Kunden-ID |\n\nWichtig ist, den autorisierten Zahlungsbetrag, den Erstattungsbetrag und den Gesamtbetrag der Bestellung nicht zu überschreiben. Geldbezogene Werte sollten möglichst als Verlauf und auf Transaktionsebene aufbewahrt werden, damit Buchhaltung und Kundenkommunikation später übereinstimmen.\n\n## Checkliste vor der Veröffentlichung\n\n- Wird die Zahlung für dieselbe Bestellung nur 1-mal autorisiert, auch wenn die Zahlungsschaltfläche 10-mal gedrückt wird?\n- Ist eine Wiederherstellung möglich, wenn die Speicherung auf dem Server nach der Zahlungsautorisierung fehlschlägt?\n- Wird ein Zahlungs-Webhook nicht doppelt verarbeitet, auch wenn dasselbe Ereignis mehrfach gesendet wird?\n- Können Kunden den Grund für einen Zahlungsfehler und die Methode für einen erneuten Versuch verstehen?\n- Laufen Bestellungen mit ausstehender Zahlung nach einer bestimmten Zeit automatisch ab?\n- Entspricht der Teilerstattungsbetrag den Richtlinien für Gutscheine, Punkte und Versandkosten?\n- Werden der Zeitraum vom Erstattungsantrag bis zur Bearbeitungsfrist und das Fristende in der Administrationsansicht angezeigt?\n- Sind die Erstattungsregeln vor der Zahlung leicht einsehbar?\n- Gibt es bei digitalen Inhalten oder Produkten mit eingeschränkter Erstattung vorherige Hinweise und Zustimmungsprotokolle?\n- Können Kunden ihren Zahlungsverlauf und Erstattungsstatus im persönlichen Bereich selbst prüfen?\n\n## Fazit\n\nEine AI kann den Code für eine Zahlungsfunktion schnell erstellen. Ein sicheres und rechtskonform betriebenes Zahlungssystem beginnt jedoch mit Richtlinienentscheidungen, die vor dem Code getroffen werden.\n\nWenn Bestellstatus, gesetzliche Erstattungsfristen, Berechnungsformeln für Teilerstattungen, Schutz vor Doppelzahlungen, Hinweise bei Zahlungsfehlern, die Seite mit dem Zahlungsverlauf und die Platzierung der Erstattungsregeln zuerst festgelegt und anschließend von einer AI implementiert werden, lassen sich wesentlich stabilere Ergebnisse erzielen. Eine Zahlungsfunktion sollte nicht als „Funktion zum Entgegennehmen von Geld“, sondern als „Funktion zur Übernahme der Verantwortung für Geld“ gestaltet werden.","content_html":"\u003ch2\u003e\n\u003ca href=\"#kernaussagen\" class=\"anchor\" id=\"kernaussagen\"\u003e\u003c/a\u003eKernaussagen\u003c/h2\u003e\n\u003cp\u003eDer riskanteste Prompt, wenn eine AI mit der Implementierung einer Zahlungsfunktion beauftragt wird, ist die einfache Aufforderung „Füge eine Zahlungsfunktion hinzu“. Eine Zahlungsfunktion besteht nicht nur aus Code, der Geld entgegennimmt, sondern ist ein Betriebs-, Buchhaltungs- und Kundensupportsystem, das für den Geldfluss verantwortlich ist.\u003c/p\u003e\n\u003cp\u003eTechnisch kann eine AI die Integration einer Zahlungsseite, den Aufruf einer Autorisierungs-API, den Empfang von Webhooks und die Speicherung von Bestellungen schnell implementieren. Sind jedoch die folgenden Richtlinien nicht festgelegt, können im realen Betrieb Geisterbestellungen, Doppelzahlungen, verzögerte Erstattungen, eine Flut von Kundendienstanfragen und fehlende rechtliche Hinweise auftreten.\u003c/p\u003e\n\u003cdiv class=\"overflow-x-auto\"\u003e\u003ctable\u003e\n\u003cthead\u003e\n\u003ctr\u003e\n\u003cth\u003eEntscheidungsbereich\u003c/th\u003e\n\u003cth\u003eVorab zu klärende Frage\u003c/th\u003e\n\u003cth\u003eRisiko bei Fehlern\u003c/th\u003e\n\u003c/tr\u003e\n\u003c/thead\u003e\n\u003ctbody\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Entscheidungsbereich\"\u003eBestellstatus\u003c/td\u003e\n\u003ctd data-label=\"Vorab zu klärende Frage\"\u003eWelche Status durchläuft eine Bestellung in welcher Reihenfolge?\u003c/td\u003e\n\u003ctd data-label=\"Risiko bei Fehlern\"\u003eEs entstehen Geisterbestellungen, bei denen bezahlt wurde, aber keine Bestellung vorhanden ist\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Entscheidungsbereich\"\u003eErstattungsfrist\u003c/td\u003e\n\u003ctd data-label=\"Vorab zu klärende Frage\"\u003eWie werden Widerruf und Bearbeitungsfristen für Erstattungen berücksichtigt?\u003c/td\u003e\n\u003ctd data-label=\"Risiko bei Fehlern\"\u003eVerletzung gesetzlicher Fristen, Verzugszinsen und Streitrisiken\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Entscheidungsbereich\"\u003eTeilerstattung\u003c/td\u003e\n\u003ctd data-label=\"Vorab zu klärende Frage\"\u003eWie werden die Rückgabe einzelner Artikel, Gutscheine und Versandkosten berechnet?\u003c/td\u003e\n\u003ctd data-label=\"Risiko bei Fehlern\"\u003eJedes Mal manuelle Berechnung durch das Betriebsteam, Misstrauen der Kunden\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Entscheidungsbereich\"\u003eDoppelzahlung\u003c/td\u003e\n\u003ctd data-label=\"Vorab zu klärende Frage\"\u003eWie wird verhindert, dass dieselbe Bestellung zweimal abgerechnet wird?\u003c/td\u003e\n\u003ctd data-label=\"Risiko bei Fehlern\"\u003eKundenbeschwerden aufgrund der Kartenabrechnung, Vertrauensverlust\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Entscheidungsbereich\"\u003eFehlermeldung\u003c/td\u003e\n\u003ctd data-label=\"Vorab zu klärende Frage\"\u003eWie werden Überschreitung des Limits, unzureichendes Guthaben und fehlgeschlagene Authentifizierung kommuniziert?\u003c/td\u003e\n\u003ctd data-label=\"Risiko bei Fehlern\"\u003eSinkende Konversionsrate bei erneuten Versuchen, mehr unnötige Anfragen\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Entscheidungsbereich\"\u003eZahlungsverlauf\u003c/td\u003e\n\u003ctd data-label=\"Vorab zu klärende Frage\"\u003eWo können Kunden den Zahlungs- und Erstattungsstatus prüfen?\u003c/td\u003e\n\u003ctd data-label=\"Risiko bei Fehlern\"\u003eMehr Kundendienstanfragen, intransparenter Status\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Entscheidungsbereich\"\u003eErstattungshinweis\u003c/td\u003e\n\u003ctd data-label=\"Vorab zu klärende Frage\"\u003eWo werden Erstattungsregeln und die Schaltfläche zum Stornieren platziert?\u003c/td\u003e\n\u003ctd data-label=\"Risiko bei Fehlern\"\u003eDiskussionen über Dark Patterns, regulatorische Risiken\u003c/td\u003e\n\u003c/tr\u003e\n\u003c/tbody\u003e\n\u003c/table\u003e\u003c/div\u003e\n\u003ch2\u003e\n\u003ca href=\"#1-gestaltung-der-bestellstatus-der-status-ist-die-sprache-des-betriebs\" class=\"anchor\" id=\"1-gestaltung-der-bestellstatus-der-status-ist-die-sprache-des-betriebs\"\u003e\u003c/a\u003e1. Gestaltung der Bestellstatus: Der Status ist die Sprache des Betriebs\u003c/h2\u003e\n\u003cp\u003eBei der Entwicklung einer Zahlungsfunktion darf es nicht nur einen einzigen Bestellstatus wie „Bestellung abgeschlossen“ geben. Eine reale Bestellung durchläuft mehrere Phasen wie Zahlungsversuch, Autorisierung, Stornierung, Erstattung, Fehlschlag und Ablauf.\u003c/p\u003e\n\u003ch3\u003e\n\u003ca href=\"#beispiel-f%C3%BCr-empfohlene-status\" class=\"anchor\" id=\"beispiel-für-empfohlene-status\"\u003e\u003c/a\u003eBeispiel für empfohlene Status\u003c/h3\u003e\n\u003cdiv class=\"overflow-x-auto\"\u003e\u003ctable\u003e\n\u003cthead\u003e\n\u003ctr\u003e\n\u003cth\u003eBeispiel für Statuscode\u003c/th\u003e\n\u003cth\u003eFür Kunden sichtbarer Status\u003c/th\u003e\n\u003cth\u003eBedeutung\u003c/th\u003e\n\u003c/tr\u003e\n\u003c/thead\u003e\n\u003ctbody\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Beispiel für Statuscode\"\u003e\u003ccode\u003epayment_pending\u003c/code\u003e\u003c/td\u003e\n\u003ctd data-label=\"Für Kunden sichtbarer Status\"\u003eZahlung ausstehend\u003c/td\u003e\n\u003ctd data-label=\"Bedeutung\"\u003eDie Bestellung wurde erstellt, aber die Zahlung ist noch nicht abgeschlossen\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Beispiel für Statuscode\"\u003e\u003ccode\u003epaid\u003c/code\u003e\u003c/td\u003e\n\u003ctd data-label=\"Für Kunden sichtbarer Status\"\u003eZahlung abgeschlossen\u003c/td\u003e\n\u003ctd data-label=\"Bedeutung\"\u003eDie Zahlung wurde autorisiert und die Bestellung ist gültig\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Beispiel für Statuscode\"\u003e\u003ccode\u003epayment_failed\u003c/code\u003e\u003c/td\u003e\n\u003ctd data-label=\"Für Kunden sichtbarer Status\"\u003eZahlung fehlgeschlagen\u003c/td\u003e\n\u003ctd data-label=\"Bedeutung\"\u003eDer Zahlungsversuch ist fehlgeschlagen und es muss geprüft werden, ob ein erneuter Versuch möglich ist\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Beispiel für Statuscode\"\u003e\u003ccode\u003ecancel_requested\u003c/code\u003e\u003c/td\u003e\n\u003ctd data-label=\"Für Kunden sichtbarer Status\"\u003eStornierung beantragt\u003c/td\u003e\n\u003ctd data-label=\"Bedeutung\"\u003eDer Kunde hat eine Stornierung beantragt, die noch bearbeitet werden muss\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Beispiel für Statuscode\"\u003e\u003ccode\u003ecancelled\u003c/code\u003e\u003c/td\u003e\n\u003ctd data-label=\"Für Kunden sichtbarer Status\"\u003eStornierung abgeschlossen\u003c/td\u003e\n\u003ctd data-label=\"Bedeutung\"\u003eDie Stornierung der Bestellung vor der Zahlung oder die Aufhebung der Autorisierung ist abgeschlossen\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Beispiel für Statuscode\"\u003e\u003ccode\u003erefund_requested\u003c/code\u003e\u003c/td\u003e\n\u003ctd data-label=\"Für Kunden sichtbarer Status\"\u003eErstattung beantragt\u003c/td\u003e\n\u003ctd data-label=\"Bedeutung\"\u003eNach der Zahlung ist ein Erstattungsantrag eingegangen\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Beispiel für Statuscode\"\u003e\u003ccode\u003erefund_processing\u003c/code\u003e\u003c/td\u003e\n\u003ctd data-label=\"Für Kunden sichtbarer Status\"\u003eErstattung wird bearbeitet\u003c/td\u003e\n\u003ctd data-label=\"Bedeutung\"\u003eDie Erstattung wird genehmigt oder über das Zahlungsmittel abgewickelt\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Beispiel für Statuscode\"\u003e\u003ccode\u003epartially_refunded\u003c/code\u003e\u003c/td\u003e\n\u003ctd data-label=\"Für Kunden sichtbarer Status\"\u003eTeilerstattung abgeschlossen\u003c/td\u003e\n\u003ctd data-label=\"Bedeutung\"\u003eNur ein Teil des Bestellbetrags wurde erstattet\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Beispiel für Statuscode\"\u003e\u003ccode\u003erefunded\u003c/code\u003e\u003c/td\u003e\n\u003ctd data-label=\"Für Kunden sichtbarer Status\"\u003eErstattung abgeschlossen\u003c/td\u003e\n\u003ctd data-label=\"Bedeutung\"\u003eDie Erstattung ist abgeschlossen\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Beispiel für Statuscode\"\u003e\u003ccode\u003eexpired\u003c/code\u003e\u003c/td\u003e\n\u003ctd data-label=\"Für Kunden sichtbarer Status\"\u003eBestellung abgelaufen\u003c/td\u003e\n\u003ctd data-label=\"Bedeutung\"\u003eDie Wartezeit für die Zahlung ist abgelaufen und die Bestellung wurde ungültig\u003c/td\u003e\n\u003c/tr\u003e\n\u003c/tbody\u003e\n\u003c/table\u003e\u003c/div\u003e\n\u003ch3\u003e\n\u003ca href=\"#grunds%C3%A4tze-f%C3%BCr-die-statusgestaltung\" class=\"anchor\" id=\"grundsätze-für-die-statusgestaltung\"\u003e\u003c/a\u003eGrundsätze für die Statusgestaltung\u003c/h3\u003e\n\u003cul\u003e\n\u003cli\u003eBestellstatus und Zahlungsstatus werden nicht als vollständig identisch betrachtet. Eine Bestellung kann vorhanden sein, obwohl die Zahlung fehlschlägt, und die Zahlung kann autorisiert worden sein, obwohl die Speicherung der Bestellung fehlschlägt.\u003c/li\u003e\n\u003cli\u003eBei jeder Statusänderung werden Zeitpunkt, Bearbeiter, Grund, Kennung der Zahlungstransaktion und Kennung der Erstattungstransaktion protokolliert.\u003c/li\u003e\n\u003cli\u003eKundenansicht, Administrationsansicht und Formulierungen des Kundendienstes müssen dieselben Statusdefinitionen verwenden.\u003c/li\u003e\n\u003cli\u003eStatusübergänge werden unidirektional gestaltet. Die Wiederherstellung nach Ausnahmen erfolgt mit gesonderten Administratorrechten und wird protokolliert.\u003c/li\u003e\n\u003c/ul\u003e\n\u003ch2\u003e\n\u003ca href=\"#2-widerruf-und-gesetzliche-erstattungsfrist-keine-richtlinie-sondern-eine-rechtliche-anforderung\" class=\"anchor\" id=\"2-widerruf-und-gesetzliche-erstattungsfrist-keine-richtlinie-sondern-eine-rechtliche-anforderung\"\u003e\u003c/a\u003e2. Widerruf und gesetzliche Erstattungsfrist: keine Richtlinie, sondern eine rechtliche Anforderung\u003c/h2\u003e\n\u003cp\u003eWer in Korea elektronischen Handel mit Verbrauchern betreibt, muss das Gesetz zum Verbraucherschutz im elektronischen Geschäftsverkehr und ähnlichen Bereichen berücksichtigen. Grundsätzlich können Verbraucher innerhalb eines bestimmten Zeitraums widerrufen, und Unternehmen müssen nach einem Erstattungsantrag oder Rückgabeverfahren den Betrag innerhalb der festgelegten Frist zurückzahlen.\u003c/p\u003e\n\u003cp\u003eIn der Praxis sind insbesondere die folgenden Kriterien wichtig.\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003eVerbraucher können grundsätzlich innerhalb von 7 Tagen ab dem gesetzlich festgelegten Stichtag, etwa dem Tag des Erhalts der Waren, widerrufen.\u003c/li\u003e\n\u003cli\u003eUnternehmen müssen den Betrag innerhalb der gesetzlichen Frist erstatten, nachdem ein Erstattungsgrund entstanden ist. Bei Verzögerungen können Verzugsentschädigungen oder Verzugszinsen anfallen.\u003c/li\u003e\n\u003cli\u003eFür digitale Inhalte, individuell angefertigte Waren oder Waren, deren Wert durch Nutzung erheblich sinkt, können Ausnahmen gelten. Für die Anwendung einer Ausnahme müssen jedoch Anforderungen wie vorherige Information und Zustimmung sorgfältig geprüft werden.\u003c/li\u003e\n\u003cli\u003eDie konkrete Anwendung kann je nach Produkttyp, Vertragsform, den Verbrauchern erteilten Hinweisen und Beginn der Nutzung variieren. Daher ist eine rechtliche Prüfung erforderlich.\u003c/li\u003e\n\u003c/ul\u003e\n\u003ch3\u003e\n\u003ca href=\"#umwandlung-in-entwicklungsanforderungen\" class=\"anchor\" id=\"umwandlung-in-entwicklungsanforderungen\"\u003e\u003c/a\u003eUmwandlung in Entwicklungsanforderungen\u003c/h3\u003e\n\u003cp\u003eEs reicht nicht aus, gesetzliche Vorgaben nur in den AGB festzuhalten. Sie müssen auch in Systemanforderungen umgesetzt werden.\u003c/p\u003e\n\u003cdiv class=\"overflow-x-auto\"\u003e\u003ctable\u003e\n\u003cthead\u003e\n\u003ctr\u003e\n\u003cth\u003eGesetzliche oder richtlinienbezogene Anforderung\u003c/th\u003e\n\u003cth\u003eSystemanforderung\u003c/th\u003e\n\u003c/tr\u003e\n\u003c/thead\u003e\n\u003ctbody\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Gesetzliche oder richtlinienbezogene Anforderung\"\u003ePrüfung, ob ein Widerruf innerhalb von 7 Tagen möglich ist\u003c/td\u003e\n\u003ctd data-label=\"Systemanforderung\"\u003eAutomatische Berechnung des Erstattungszeitraums anhand des Empfangsdatums der Bestellung oder des Datums der Leistungserbringung\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Gesetzliche oder richtlinienbezogene Anforderung\"\u003eErstattung innerhalb von 3 Werktagen erforderlich\u003c/td\u003e\n\u003ctd data-label=\"Systemanforderung\"\u003eAnzeige des Erstattungsantragsdatums und der Bearbeitungsfrist in der Administrationsansicht\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Gesetzliche oder richtlinienbezogene Anforderung\"\u003eRisiko einer verzögerten Erstattung\u003c/td\u003e\n\u003ctd data-label=\"Systemanforderung\"\u003eHinweise bei nahendem und überschrittenem Fristende\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Gesetzliche oder richtlinienbezogene Anforderung\"\u003eHinweis auf ausgenommene Produkte erforderlich\u003c/td\u003e\n\u003ctd data-label=\"Systemanforderung\"\u003eVor der Zahlung deutlich darauf hinweisen, dass die Erstattung für das Produkt eingeschränkt ist, und das Zustimmungsprotokoll speichern\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Gesetzliche oder richtlinienbezogene Anforderung\"\u003eVorbereitung auf Streitfälle erforderlich\u003c/td\u003e\n\u003ctd data-label=\"Systemanforderung\"\u003eAGB-Version, Zeitpunkt des Hinweises, Zeitpunkt der Zustimmung sowie Kunden-IP oder Kontoprotokolle aufbewahren\u003c/td\u003e\n\u003c/tr\u003e\n\u003c/tbody\u003e\n\u003c/table\u003e\u003c/div\u003e\n\u003ch2\u003e\n\u003ca href=\"#3-regeln-f%C3%BCr-teilerstattungen-gutscheine-versandkosten-und-steuern-vorab-definieren\" class=\"anchor\" id=\"3-regeln-für-teilerstattungen-gutscheine-versandkosten-und-steuern-vorab-definieren\"\u003e\u003c/a\u003e3. Regeln für Teilerstattungen: Gutscheine, Versandkosten und Steuern vorab definieren\u003c/h2\u003e\n\u003cp\u003eTeilerstattungen sind wesentlich komplexer als vollständige Stornierungen. Werden mehrere Artikel gemeinsam bestellt und nur einige davon zurückgegeben, muss entschieden werden, wie der ursprünglich gewährte Rabatt und die Versandkosten aufgeteilt werden.\u003c/p\u003e\n\u003ch3\u003e\n\u003ca href=\"#unbedingt-festzulegende-punkte\" class=\"anchor\" id=\"unbedingt-festzulegende-punkte\"\u003e\u003c/a\u003eUnbedingt festzulegende Punkte\u003c/h3\u003e\n\u003cul\u003e\n\u003cli\u003eWie der Zahlungsbetrag pro Artikel zugeordnet wird\u003c/li\u003e\n\u003cli\u003eOb ein Gutschein für die gesamte Bestellung proportional auf die einzelnen Artikel verteilt wird\u003c/li\u003e\n\u003cli\u003eOb ein Gutschein für einen bestimmten Artikel nur auf diesen Artikel angewendet wird\u003c/li\u003e\n\u003cli\u003eOb Versandkosten abgezogen werden, wenn die Bedingung für kostenlosen Versand nachträglich nicht mehr erfüllt ist\u003c/li\u003e\n\u003cli\u003eWie Rücksendekosten bei bloßem Meinungswechsel von Rücksendekosten wegen eines Produktmangels unterschieden werden\u003c/li\u003e\n\u003cli\u003eIn welcher Reihenfolge mit Punkten, Guthaben und Geschenkkarten bezahlte Beträge erstattet werden\u003c/li\u003e\n\u003cli\u003eWie Rechnungen, Barzahlungsbelege und Quittungen nach einer Teilerstattung angepasst werden\u003c/li\u003e\n\u003c/ul\u003e\n\u003ch3\u003e\n\u003ca href=\"#beispiel-f%C3%BCr-die-berechnung-einer-teilerstattung\" class=\"anchor\" id=\"beispiel-für-die-berechnung-einer-teilerstattung\"\u003e\u003c/a\u003eBeispiel für die Berechnung einer Teilerstattung\u003c/h3\u003e\n\u003cdiv class=\"overflow-x-auto\"\u003e\u003ctable\u003e\n\u003cthead\u003e\n\u003ctr\u003e\n\u003cth\u003ePosten\u003c/th\u003e\n\u003cth\u003eBetrag\u003c/th\u003e\n\u003c/tr\u003e\n\u003c/thead\u003e\n\u003ctbody\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Posten\"\u003eArtikel A\u003c/td\u003e\n\u003ctd data-label=\"Betrag\"\u003e30,000원\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Posten\"\u003eArtikel B\u003c/td\u003e\n\u003ctd data-label=\"Betrag\"\u003e70,000원\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Posten\"\u003eGutschein für die gesamte Bestellung\u003c/td\u003e\n\u003ctd data-label=\"Betrag\"\u003e-10,000원\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Posten\"\u003eTatsächlicher Zahlungsbetrag\u003c/td\u003e\n\u003ctd data-label=\"Betrag\"\u003e90,000원\u003c/td\u003e\n\u003c/tr\u003e\n\u003c/tbody\u003e\n\u003c/table\u003e\u003c/div\u003e\n\u003cp\u003eWird der Gutschein proportional zum Warenwert verteilt, entfallen 3,000원 Rabatt auf Artikel A und 7,000원 auf Artikel B. Wird in diesem Fall nur Artikel A erstattet, beträgt der für die Erstattung maßgebliche Betrag nicht 30,000원, sondern 27,000원. Bestehen Bedingungen für kostenlosen Versand, Rücksendekosten oder Einschränkungen für die Erstattung je Zahlungsmittel, kann der endgültige Erstattungsbetrag weiter abweichen.\u003c/p\u003e\n\u003cp\u003eEs gibt nicht nur eine richtige Antwort. Entscheidend ist, im Voraus einheitliche Regeln festzulegen und sie so bekannt zu geben, dass Kunden sie vor der Zahlung oder vor dem Erstattungsantrag verstehen können.\u003c/p\u003e\n\u003ch2\u003e\n\u003ca href=\"#4-verhinderung-von-doppelzahlungen-das-deaktivieren-der-schaltfl%C3%A4che-reicht-nicht-aus\" class=\"anchor\" id=\"4-verhinderung-von-doppelzahlungen-das-deaktivieren-der-schaltfläche-reicht-nicht-aus\"\u003e\u003c/a\u003e4. Verhinderung von Doppelzahlungen: Das Deaktivieren der Schaltfläche reicht nicht aus\u003c/h2\u003e\n\u003cp\u003eDoppelzahlungen gehören zu den Zahlungsvorfällen, die Kunden am schnellsten bemerken. Kunden sehen die Benachrichtigung über die Kartenautorisierung und die Kartenabrechnung früher als den internen Bestellstatus des Dienstes. Wird dieselbe Bestellung zweimal abgerechnet, sinkt das Vertrauen erheblich.\u003c/p\u003e\n\u003ch3\u003e\n\u003ca href=\"#ursachen\" class=\"anchor\" id=\"ursachen\"\u003e\u003c/a\u003eUrsachen\u003c/h3\u003e\n\u003cul\u003e\n\u003cli\u003eDer Kunde klickt mehrmals hintereinander auf die Zahlungsschaltfläche\u003c/li\u003e\n\u003cli\u003eDer Kunde aktualisiert die Seite unmittelbar nach der Zahlung oder klickt auf „Zurück“\u003c/li\u003e\n\u003cli\u003eAufgrund einer Verzögerung im Mobilfunknetz wird dieselbe Anfrage erneut gesendet\u003c/li\u003e\n\u003cli\u003eDie Antwort auf die Zahlungsautorisierung ist erfolgreich, aber die Speicherung auf dem Dienstserver schlägt fehl\u003c/li\u003e\n\u003cli\u003eWebhook und Client-Weiterleitung ändern den Bestellstatus gleichzeitig\u003c/li\u003e\n\u003c/ul\u003e\n\u003ch3\u003e\n\u003ca href=\"#schutzmechanismen\" class=\"anchor\" id=\"schutzmechanismen\"\u003e\u003c/a\u003eSchutzmechanismen\u003c/h3\u003e\n\u003cdiv class=\"overflow-x-auto\"\u003e\u003ctable\u003e\n\u003cthead\u003e\n\u003ctr\u003e\n\u003cth\u003eSchutzmaßnahme\u003c/th\u003e\n\u003cth\u003eBeschreibung\u003c/th\u003e\n\u003c/tr\u003e\n\u003c/thead\u003e\n\u003ctbody\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Schutzmaßnahme\"\u003eSperrung der Client-Schaltfläche\u003c/td\u003e\n\u003ctd data-label=\"Beschreibung\"\u003eVerhindert erneutes Klicken nach dem Klick auf die Zahlungsschaltfläche, wird aber nur als ergänzende Maßnahme verwendet\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Schutzmaßnahme\"\u003eServerseitige Bestellsperre\u003c/td\u003e\n\u003ctd data-label=\"Beschreibung\"\u003eVerhindert, dass für dieselbe Bestell-ID gleichzeitig mehrere Anfragen zur Zahlungsautorisierung ausgeführt werden\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Schutzmaßnahme\"\u003eIdempotenzschlüssel\u003c/td\u003e\n\u003ctd data-label=\"Beschreibung\"\u003eVerwendet eine Kennung, durch die auch bei mehrmaligem Senden derselben Zahlungsanfrage nur ein Ergebnis erzeugt wird\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Schutzmaßnahme\"\u003eEindeutige Transaktionsnummer\u003c/td\u003e\n\u003ctd data-label=\"Beschreibung\"\u003eVerhindert durch Datenbank-Constraints die doppelte Speicherung von Bestellnummer und Zahlungstransaktionsnummer\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Schutzmaßnahme\"\u003eStatusbasierte Prüfung\u003c/td\u003e\n\u003ctd data-label=\"Beschreibung\"\u003eVerhindert zusätzliche Autorisierungsanfragen für Bestellungen, die bereits den Status \u003ccode\u003epaid\u003c/code\u003e haben\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Schutzmaßnahme\"\u003eDeduplizierung von Webhooks\u003c/td\u003e\n\u003ctd data-label=\"Beschreibung\"\u003eStellt sicher, dass eine Statusänderung nur einmal erfolgt, auch wenn dasselbe Webhook-Ereignis mehrfach eingeht\u003c/td\u003e\n\u003c/tr\u003e\n\u003c/tbody\u003e\n\u003c/table\u003e\u003c/div\u003e\n\u003cp\u003eWenn eine AI mit der Erstellung von Zahlungscode beauftragt wird, sollte nicht nur „Mehrfachklicks verhindern“, sondern ausdrücklich „Zahlungsautorisierung und Abschluss der Zahlungsbearbeitung müssen für dieselbe Bestellung idempotent funktionieren“ vorgegeben werden.\u003c/p\u003e\n\u003ch2\u003e\n\u003ca href=\"#5-hinweise-bei-zahlungsfehlern-ein-fehlschlag-ist-kein-vorfall-sondern-ein-normaler-ablauf\" class=\"anchor\" id=\"5-hinweise-bei-zahlungsfehlern-ein-fehlschlag-ist-kein-vorfall-sondern-ein-normaler-ablauf\"\u003e\u003c/a\u003e5. Hinweise bei Zahlungsfehlern: Ein Fehlschlag ist kein Vorfall, sondern ein normaler Ablauf\u003c/h2\u003e\n\u003cp\u003eZahlungsfehler sind normale Situationen, die täglich auftreten. Überschreitung des Limits, unzureichendes Guthaben, fehlgeschlagene Kartenauthentifizierung, falsches Passwort, fehlgeschlagene 3D Secure-Authentifizierung, ausbleibende Reaktion einer App für vereinfachte Zahlungen und Netzwerkfehler sind allesamt häufige Fälle.\u003c/p\u003e\n\u003cp\u003eEin schlechter Hinweis endet mit „Es ist ein Fehler aufgetreten“. Der Kunde weiß dann nicht, ob die Zahlung erfolgt ist, ob er erneut klicken darf oder ob die Bestellung verloren geht.\u003c/p\u003e\n\u003ch3\u003e\n\u003ca href=\"#beispiele-f%C3%BCr-hinweise\" class=\"anchor\" id=\"beispiele-für-hinweise\"\u003e\u003c/a\u003eBeispiele für Hinweise\u003c/h3\u003e\n\u003cdiv class=\"overflow-x-auto\"\u003e\u003ctable\u003e\n\u003cthead\u003e\n\u003ctr\u003e\n\u003cth\u003eSituation\u003c/th\u003e\n\u003cth\u003eEmpfohlener Hinweis\u003c/th\u003e\n\u003c/tr\u003e\n\u003c/thead\u003e\n\u003ctbody\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Situation\"\u003eUnzureichendes Guthaben\u003c/td\u003e\n\u003ctd data-label=\"Empfohlener Hinweis\"\u003eDie Zahlung konnte nicht abgeschlossen werden, weil das Guthaben des Zahlungsmittels nicht ausreicht. Wählen Sie ein anderes Zahlungsmittel oder prüfen Sie das Guthaben und versuchen Sie es erneut.\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Situation\"\u003eLimit überschritten\u003c/td\u003e\n\u003ctd data-label=\"Empfohlener Hinweis\"\u003eDie Zahlung ist fehlgeschlagen, weil das Kartenlimit oder das Limit für eine einzelne Zahlung überschritten wurde. Prüfen Sie das Limit in der App des Kartenanbieters oder bezahlen Sie mit einer anderen Karte.\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Situation\"\u003eAuthentifizierung fehlgeschlagen\u003c/td\u003e\n\u003ctd data-label=\"Empfohlener Hinweis\"\u003eDa die Zahlungsauthentifizierung nicht abgeschlossen wurde, bleibt die Bestellung im Status „Zahlung ausstehend“. Sie können die Zahlung innerhalb von 30 Minuten erneut durchführen.\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Situation\"\u003eNetzwerkfehler\u003c/td\u003e\n\u003ctd data-label=\"Empfohlener Hinweis\"\u003eDie Bestätigung des Zahlungsergebnisses verzögert sich. Um eine Doppelzahlung zu vermeiden, prüfen Sie bitte nach kurzer Zeit den Zahlungsverlauf.\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Situation\"\u003eBestellung abgelaufen\u003c/td\u003e\n\u003ctd data-label=\"Empfohlener Hinweis\"\u003eDie Wartezeit für die Zahlung ist abgelaufen und die Bestellung wurde ungültig. Wählen Sie die Artikel erneut aus und geben Sie eine neue Bestellung auf.\u003c/td\u003e\n\u003c/tr\u003e\n\u003c/tbody\u003e\n\u003c/table\u003e\u003c/div\u003e\n\u003ch3\u003e\n\u003ca href=\"#kernelemente-eines-hinweises-bei-fehlern\" class=\"anchor\" id=\"kernelemente-eines-hinweises-bei-fehlern\"\u003e\u003c/a\u003eKernelemente eines Hinweises bei Fehlern\u003c/h3\u003e\n\u003cul\u003e\n\u003cli\u003eEs wird eindeutig mitgeteilt, ob die Zahlung tatsächlich nicht abgeschlossen wurde.\u003c/li\u003e\n\u003cli\u003eEs wird angegeben, wie lange die Bestellung bestehen bleibt.\u003c/li\u003e\n\u003cli\u003eEs wird erklärt, ob ein erneuter Versuch möglich ist oder ein anderes Zahlungsmittel verwendet werden muss.\u003c/li\u003e\n\u003cli\u003eDie für eine Anfrage beim Kundendienst erforderliche Bestellnummer wird angezeigt.\u003c/li\u003e\n\u003cli\u003eWenn das Zahlungsergebnis unklar ist, darf nicht bedingungslos zu einer erneuten Zahlung aufgefordert werden. Stattdessen muss der Status „Wird geprüft“ angeboten werden.\u003c/li\u003e\n\u003c/ul\u003e\n\u003ch2\u003e\n\u003ca href=\"#6-seite-mit-dem-zahlungsverlauf-die-zentrale-ansicht-zur-entlastung-des-kundendienstes\" class=\"anchor\" id=\"6-seite-mit-dem-zahlungsverlauf-die-zentrale-ansicht-zur-entlastung-des-kundendienstes\"\u003e\u003c/a\u003e6. Seite mit dem Zahlungsverlauf: die zentrale Ansicht zur Entlastung des Kundendienstes\u003c/h2\u003e\n\u003cp\u003eOhne eine Seite mit dem Zahlungsverlauf wenden sich Kunden an den Kundendienst, um den Zahlungs-, Stornierungs- oder Erstattungsstatus zu prüfen. Der Zahlungsverlauf ist nicht nur eine einfache Belegansicht, sondern ein Vertrauensinstrument, mit dem Kunden den aktuellen Status ihres Geldes nachvollziehen können.\u003c/p\u003e\n\u003ch3\u003e\n\u003ca href=\"#informationen-auf-der-seite-mit-dem-zahlungsverlauf\" class=\"anchor\" id=\"informationen-auf-der-seite-mit-dem-zahlungsverlauf\"\u003e\u003c/a\u003eInformationen auf der Seite mit dem Zahlungsverlauf\u003c/h3\u003e\n\u003cul\u003e\n\u003cli\u003eBestellnummer\u003c/li\u003e\n\u003cli\u003eBestellzeitpunkt und Zahlungszeitpunkt\u003c/li\u003e\n\u003cli\u003eProduktname, Menge und Optionen\u003c/li\u003e\n\u003cli\u003eZahlungsmittel und Autorisierungsnummer oder Transaktionskennung\u003c/li\u003e\n\u003cli\u003eWarenwert, Rabatt, Versandkosten, verwendete Punkte und endgültiger Zahlungsbetrag\u003c/li\u003e\n\u003cli\u003eAktueller Bestellstatus und Erstattungsstatus\u003c/li\u003e\n\u003cli\u003eDatum des Erstattungsantrags, Datum der Erstattungsgenehmigung und voraussichtliches Abschlussdatum der Erstattung\u003c/li\u003e\n\u003cli\u003eAngabe, ob eine Stornierung oder Erstattung möglich ist\u003c/li\u003e\n\u003cli\u003eLinks zu Beleg, Transaktionsübersicht und Barzahlungsbeleg\u003c/li\u003e\n\u003cli\u003eFür Anfragen beim Kundendienst benötigte Informationen\u003c/li\u003e\n\u003c/ul\u003e\n\u003ch3\u003e\n\u003ca href=\"#verkn%C3%BCpfung-mit-der-betreiberansicht\" class=\"anchor\" id=\"verknüpfung-mit-der-betreiberansicht\"\u003e\u003c/a\u003eVerknüpfung mit der Betreiberansicht\u003c/h3\u003e\n\u003cp\u003eKundenansicht und Administrationsansicht müssen dieselben Daten anzeigen. Wenn Kunden „Erstattung wird bearbeitet“ sehen, während in der Administrationsansicht „Bearbeitung abgeschlossen“ steht, wird die Kommunikation des Kundendienstes inkonsistent. Die Statusbezeichnungen können unterschiedlich formuliert werden, aber es darf nur einen internen Statuscode und einen Satz von Übergangsregeln geben.\u003c/p\u003e\n\u003ch2\u003e\n\u003ca href=\"#7-platzierung-der-erstattungsregeln-versteckte-regeln-werden-zum-risiko\" class=\"anchor\" id=\"7-platzierung-der-erstattungsregeln-versteckte-regeln-werden-zum-risiko\"\u003e\u003c/a\u003e7. Platzierung der Erstattungsregeln: Versteckte Regeln werden zum Risiko\u003c/h2\u003e\n\u003cp\u003eEs reicht nicht aus, die Erstattungsregeln nur in einer Ecke der AGB-Seite zu platzieren. Auf der Seite, auf der Kunden ihre Zahlungsentscheidung treffen, müssen sie den Erstattungszeitraum, Einschränkungen der Erstattung und das Stornierungsverfahren leicht erkennen können.\u003c/p\u003e\n\u003ch3\u003e\n\u003ca href=\"#geeignete-stellen-f%C3%BCr-hinweise\" class=\"anchor\" id=\"geeignete-stellen-für-hinweise\"\u003e\u003c/a\u003eGeeignete Stellen für Hinweise\u003c/h3\u003e\n\u003cul\u003e\n\u003cli\u003eIn der Nähe des Preises oder der Kaufschaltfläche auf der Produktdetailseite\u003c/li\u003e\n\u003cli\u003eIm Warenkorb oder auf der Bestellseite\u003c/li\u003e\n\u003cli\u003eIm Bereich zur Zustimmung zu AGB und Erstattungsregeln direkt oberhalb der Zahlungsschaltfläche\u003c/li\u003e\n\u003cli\u003eAuf der Zahlungsbestätigungsseite\u003c/li\u003e\n\u003cli\u003eIn der Bestelldetailansicht des persönlichen Bereichs\u003c/li\u003e\n\u003cli\u003eAuf der Seite für Erstattungsanträge\u003c/li\u003e\n\u003c/ul\u003e\n\u003ch3\u003e\n\u003ca href=\"#zu-vermeidende-gestaltungen\" class=\"anchor\" id=\"zu-vermeidende-gestaltungen\"\u003e\u003c/a\u003eZu vermeidende Gestaltungen\u003c/h3\u003e\n\u003cul\u003e\n\u003cli\u003eEine Gestaltung, bei der Registrierung und Zahlung in einem Schritt möglich sind, Kündigung oder Erstattung jedoch nur telefonisch über den Kundendienst erfolgen können\u003c/li\u003e\n\u003cli\u003eEine Gestaltung, bei der die Schaltfläche zum Stornieren tief in mehreren Schritten verborgen ist\u003c/li\u003e\n\u003cli\u003eEine Gestaltung, bei der Einschränkungen der Erstattung erst nach der Zahlung angezeigt werden\u003c/li\u003e\n\u003cli\u003eEine Gestaltung, bei der Farbe, Formulierung und Reihenfolge der Schaltflächen so angeordnet sind, dass Kunden irregeführt werden\u003c/li\u003e\n\u003cli\u003eEine Gestaltung, bei der nicht klar auf die automatische Zahlung nach Ende eines kostenlosen Testzeitraums hingewiesen wird\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003eSolche Gestaltungen beeinträchtigen nicht nur das Kundenerlebnis, sondern können auch als Dark Patterns bewertet werden. Insbesondere sollte die Schwierigkeit von Stornierung und Kündigung nicht wesentlich von der Schwierigkeit der Registrierung und Zahlung abweichen.\u003c/p\u003e\n\u003ch2\u003e\n\u003ca href=\"#checkliste-f%C3%BCr-einen-prompt-an-eine-ai\" class=\"anchor\" id=\"checkliste-für-einen-prompt-an-eine-ai\"\u003e\u003c/a\u003eCheckliste für einen Prompt an eine AI\u003c/h2\u003e\n\u003cp\u003eWenn ein AI-Entwicklungstool mit der Implementierung einer Zahlungsfunktion beauftragt wird, müssen zunächst die Richtlinien wie folgt übermittelt werden.\u003c/p\u003e\n\u003ch3\u003e\n\u003ca href=\"#beispiel-f%C3%BCr-einen-prompt-zur-zahlungsfunktion\" class=\"anchor\" id=\"beispiel-für-einen-prompt-zur-zahlungsfunktion\"\u003e\u003c/a\u003eBeispiel für einen Prompt zur Zahlungsfunktion\u003c/h3\u003e\n\u003cpre\u003e\u003ccode\u003e\u003cspan\u003eImplementiere die Zahlungsfunktion eines koreanischen E-Commerce-Dienstes für Verbraucher.\n\u003c/span\u003e\u003cspan\u003eBerücksichtige dabei unbedingt die folgenden Richtlinien.\n\u003c/span\u003e\u003cspan\u003e\n\u003c/span\u003e\u003cspan\u003e1. Verwende für den Bestellstatus payment_pending, paid, payment_failed, cancel_requested, cancelled, refund_requested, refund_processing, partially_refunded, refunded und expired.\n\u003c/span\u003e\u003cspan\u003e2. Ändere Bestellungen mit ausstehender Zahlung nach 30 Minuten in expired.\n\u003c/span\u003e\u003cspan\u003e3. Erlaube für dieselbe Bestellung nur 1 Zahlungsautorisierung und verwende eine serverseitige Bestellsperre sowie einen Idempotenzschlüssel.\n\u003c/span\u003e\u003cspan\u003e4. Da Zahlungs-Webhooks mehrfach empfangen werden können, darf dieselbe Ereignis-ID nur einmal verarbeitet werden.\n\u003c/span\u003e\u003cspan\u003e5. Speichere das Datum des Erstattungsantrags, die Bearbeitungsfrist für die Erstattung, den Bearbeiter, den Grund und die Erstattungstransaktionsnummer.\n\u003c/span\u003e\u003cspan\u003e6. Berechne Teilerstattungen anhand des tatsächlich gezahlten Betrags je Artikel und verteile einen Gutschein für die gesamte Bestellung proportional zum Warenwert.\n\u003c/span\u003e\u003cspan\u003e7. Gib bei einem Zahlungsfehler je nach Fehlergrund einen entsprechenden Kundenhinweis zurück.\n\u003c/span\u003e\u003cspan\u003e8. Ermögliche Kunden, im persönlichen Bereich ihren Zahlungsverlauf und Erstattungsstatus zu prüfen.\n\u003c/span\u003e\u003cspan\u003e9. Zeige vor der Zahlung einen Link zu den Erstattungsregeln und ein Kontrollkästchen zur Zustimmung an und speichere den Zeitpunkt der Zustimmung sowie die AGB-Version.\n\u003c/span\u003e\u003cspan\u003e10. Wenn Richtlinien nicht festgelegt sind, stelle zuerst Fragen, bevor du Code schreibst.\n\u003c/span\u003e\u003c/code\u003e\u003c/pre\u003e\n\u003cp\u003eDer letzte Satz „Wenn Richtlinien nicht festgelegt sind, stelle zuerst Fragen“ ist wichtig. Dadurch kann die AI zu leicht übersehenen Richtlinien wie der automatischen Genehmigung von Erstattungen, den Genehmigungsrechten von Administratoren und der Methode zum Abzug der Versandkosten Rückfragen stellen.\u003c/p\u003e\n\u003ch2\u003e\n\u003ca href=\"#erforderliche-funktionen-der-betreiberansicht\" class=\"anchor\" id=\"erforderliche-funktionen-der-betreiberansicht\"\u003e\u003c/a\u003eErforderliche Funktionen der Betreiberansicht\u003c/h2\u003e\n\u003cp\u003eEine Zahlungsfunktion ist nicht allein mit der Kundenansicht vollständig. Da Erstattungen und Stornierungen täglich anfallende Betriebsaufgaben sind, ist eine Administrationsansicht zwingend erforderlich.\u003c/p\u003e\n\u003cdiv class=\"overflow-x-auto\"\u003e\u003ctable\u003e\n\u003cthead\u003e\n\u003ctr\u003e\n\u003cth\u003eAdministratorfunktion\u003c/th\u003e\n\u003cth\u003eGrund\u003c/th\u003e\n\u003c/tr\u003e\n\u003c/thead\u003e\n\u003ctbody\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Administratorfunktion\"\u003eListe ausstehender Erstattungen\u003c/td\u003e\n\u003ctd data-label=\"Grund\"\u003eErforderlich, damit zu bearbeitende Erstattungen nicht übersehen werden\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Administratorfunktion\"\u003eAnzeige der gesetzlichen Bearbeitungsfrist\u003c/td\u003e\n\u003ctd data-label=\"Grund\"\u003eErforderlich, um das Risiko verzögerter Erstattungen zu verringern\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Administratorfunktion\"\u003eWarnung bei nahendem oder überschrittenem Fristende\u003c/td\u003e\n\u003ctd data-label=\"Grund\"\u003eErforderlich, damit Betreiber interne Vorgaben wie 3 Werktage sofort erkennen\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Administratorfunktion\"\u003eAuswahl des Erstattungsgrunds\u003c/td\u003e\n\u003ctd data-label=\"Grund\"\u003eErforderlich für Statistiken und Kostenverteilung, etwa bei Meinungswechsel, Produktmängeln oder Falschlieferungen\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Administratorfunktion\"\u003eVorschau der Teilerstattungsberechnung\u003c/td\u003e\n\u003ctd data-label=\"Grund\"\u003eErforderlich, um manuelle Berechnungsfehler der Betreiber zu reduzieren\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Administratorfunktion\"\u003eBearbeitungsprotokoll\u003c/td\u003e\n\u003ctd data-label=\"Grund\"\u003eErforderlich für Streitfälle und Prüfungen\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Administratorfunktion\"\u003eRechteverwaltung\u003c/td\u003e\n\u003ctd data-label=\"Grund\"\u003eErforderlich, um die Genehmigung von Erstattungen und erzwungene Statusänderungen einzuschränken\u003c/td\u003e\n\u003c/tr\u003e\n\u003c/tbody\u003e\n\u003c/table\u003e\u003c/div\u003e\n\u003ch2\u003e\n\u003ca href=\"#mindestumfang-des-zahlungsdatenmodells\" class=\"anchor\" id=\"mindestumfang-des-zahlungsdatenmodells\"\u003e\u003c/a\u003eMindestumfang des Zahlungsdatenmodells\u003c/h2\u003e\n\u003cp\u003eDie Datenstruktur unterscheidet sich je nach Dienst. Mindestens die folgenden Daten sollten jedoch getrennt gehalten werden.\u003c/p\u003e\n\u003cdiv class=\"overflow-x-auto\"\u003e\u003ctable\u003e\n\u003cthead\u003e\n\u003ctr\u003e\n\u003cth\u003eTabelle oder Objekt\u003c/th\u003e\n\u003cth\u003eZentrale Felder\u003c/th\u003e\n\u003c/tr\u003e\n\u003c/thead\u003e\n\u003ctbody\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Tabelle oder Objekt\"\u003eBestellung\u003c/td\u003e\n\u003ctd data-label=\"Zentrale Felder\"\u003eBestell-ID, Kunden-ID, Bestellstatus, Bestellbetrag, Rabattbetrag, Versandkosten, Erstellungszeitpunkt, Ablaufzeitpunkt\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Tabelle oder Objekt\"\u003eBestellartikel\u003c/td\u003e\n\u003ctd data-label=\"Zentrale Felder\"\u003eProdukt-ID, Produktname, Optionen, Menge, Betrag je Artikel, zugeordneter Rabattbetrag je Artikel\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Tabelle oder Objekt\"\u003eZahlung\u003c/td\u003e\n\u003ctd data-label=\"Zentrale Felder\"\u003eZahlungs-ID, Bestell-ID, Zahlungsmittel, Autorisierungsnummer, autorisierter Betrag, Zahlungsstatus, Autorisierungszeitpunkt\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Tabelle oder Objekt\"\u003eErstattung\u003c/td\u003e\n\u003ctd data-label=\"Zentrale Felder\"\u003eErstattungs-ID, Bestell-ID, Erstattungsbetrag, Erstattungsgrund, Erstattungsstatus, Antragszeitpunkt, Abschlusszeitpunkt\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Tabelle oder Objekt\"\u003eStatusverlauf\u003c/td\u003e\n\u003ctd data-label=\"Zentrale Felder\"\u003eZiel-ID, vorheriger Status, neuer Status, Ändernder, Änderungsgrund, Änderungszeitpunkt\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Tabelle oder Objekt\"\u003eZustimmung zu AGB\u003c/td\u003e\n\u003ctd data-label=\"Zentrale Felder\"\u003eArt der AGB, AGB-Version, Zustimmungsstatus, Zustimmungszeitpunkt, Kunden-ID\u003c/td\u003e\n\u003c/tr\u003e\n\u003c/tbody\u003e\n\u003c/table\u003e\u003c/div\u003e\n\u003cp\u003eWichtig ist, den autorisierten Zahlungsbetrag, den Erstattungsbetrag und den Gesamtbetrag der Bestellung nicht zu überschreiben. Geldbezogene Werte sollten möglichst als Verlauf und auf Transaktionsebene aufbewahrt werden, damit Buchhaltung und Kundenkommunikation später übereinstimmen.\u003c/p\u003e\n\u003ch2\u003e\n\u003ca href=\"#checkliste-vor-der-ver%C3%B6ffentlichung\" class=\"anchor\" id=\"checkliste-vor-der-veröffentlichung\"\u003e\u003c/a\u003eCheckliste vor der Veröffentlichung\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eWird die Zahlung für dieselbe Bestellung nur 1-mal autorisiert, auch wenn die Zahlungsschaltfläche 10-mal gedrückt wird?\u003c/li\u003e\n\u003cli\u003eIst eine Wiederherstellung möglich, wenn die Speicherung auf dem Server nach der Zahlungsautorisierung fehlschlägt?\u003c/li\u003e\n\u003cli\u003eWird ein Zahlungs-Webhook nicht doppelt verarbeitet, auch wenn dasselbe Ereignis mehrfach gesendet wird?\u003c/li\u003e\n\u003cli\u003eKönnen Kunden den Grund für einen Zahlungsfehler und die Methode für einen erneuten Versuch verstehen?\u003c/li\u003e\n\u003cli\u003eLaufen Bestellungen mit ausstehender Zahlung nach einer bestimmten Zeit automatisch ab?\u003c/li\u003e\n\u003cli\u003eEntspricht der Teilerstattungsbetrag den Richtlinien für Gutscheine, Punkte und Versandkosten?\u003c/li\u003e\n\u003cli\u003eWerden der Zeitraum vom Erstattungsantrag bis zur Bearbeitungsfrist und das Fristende in der Administrationsansicht angezeigt?\u003c/li\u003e\n\u003cli\u003eSind die Erstattungsregeln vor der Zahlung leicht einsehbar?\u003c/li\u003e\n\u003cli\u003eGibt es bei digitalen Inhalten oder Produkten mit eingeschränkter Erstattung vorherige Hinweise und Zustimmungsprotokolle?\u003c/li\u003e\n\u003cli\u003eKönnen Kunden ihren Zahlungsverlauf und Erstattungsstatus im persönlichen Bereich selbst prüfen?\u003c/li\u003e\n\u003c/ul\u003e\n\u003ch2\u003e\n\u003ca href=\"#fazit\" class=\"anchor\" id=\"fazit\"\u003e\u003c/a\u003eFazit\u003c/h2\u003e\n\u003cp\u003eEine AI kann den Code für eine Zahlungsfunktion schnell erstellen. Ein sicheres und rechtskonform betriebenes Zahlungssystem beginnt jedoch mit Richtlinienentscheidungen, die vor dem Code getroffen werden.\u003c/p\u003e\n\u003cp\u003eWenn Bestellstatus, gesetzliche Erstattungsfristen, Berechnungsformeln für Teilerstattungen, Schutz vor Doppelzahlungen, Hinweise bei Zahlungsfehlern, die Seite mit dem Zahlungsverlauf und die Platzierung der Erstattungsregeln zuerst festgelegt und anschließend von einer AI implementiert werden, lassen sich wesentlich stabilere Ergebnisse erzielen. Eine Zahlungsfunktion sollte nicht als „Funktion zum Entgegennehmen von Geld“, sondern als „Funktion zur Übernahme der Verantwortung für Geld“ gestaltet werden.\u003c/p\u003e\n","tags":["KI Entwicklung","Payment system","Refund policy","E commerce law","Dark patterns"],"faqs":[{"question":"Was muss zuerst festgelegt werden, wenn man eine KI anweist, eine Zahlungsfunktion zu erstellen?","answer":"Zuerst müssen die Abläufe für den Bestellstatus und den Zahlungsstatus festgelegt werden. Status wie „Zahlung ausstehend“, „Zahlung abgeschlossen“, „Zahlung fehlgeschlagen“, „Stornierung angefordert“, „Rückerstattung in Bearbeitung“ und „Rückerstattung abgeschlossen“ müssen definiert sein, damit die KI eine sichere Datenstruktur und einen sicheren Bildschirmablauf erstellen kann."},{"question":"Warum ist es riskant, als einzigen Bestellstatus einfach „Bestellung abgeschlossen“ zu verwenden?","answer":"Weil es bei tatsächlichen Zahlungen viele Ausnahmeabläufe wie Fehlschläge, Stornierungen, Rückerstattungen und Abläufe gibt. Wenn die Status zu einfach gehalten sind, kann es passieren, dass eine Zahlung erfolgt ist, aber keine Bestelldaten vorhanden sind, oder dass eine Rückerstattung abgeschlossen ist, die Zahlung auf der Kundenseite jedoch weiterhin als abgeschlossen angezeigt wird."},{"question":"Gilt die 7-Tage-Regel für den Widerruf im koreanischen elektronischen Geschäftsverkehr immer?","answer":"Grundsätzlich können Verbraucher innerhalb von 7 Tagen ab dem gesetzlich festgelegten Stichtag ihren Widerruf erklären. Für digitale Inhalte, maßgefertigte Waren oder Waren, deren Wert durch die Nutzung gemindert wird, können jedoch Ausnahmen gelten. Daher ist eine Einzelfallprüfung erforderlich, die auch die Anforderungen an eine vorherige Information und Zustimmung umfasst."},{"question":"Bis wann muss eine Rückerstattung bearbeitet werden?","answer":"Im koreanischen E-Commerce muss der Unternehmer den Betrag innerhalb der gesetzlichen Frist zurückerstatten, nachdem ein Erstattungsgrund eingetreten ist. In der Praxis ist es sicher, die Frist von 3 Werktagen in der Verwaltungsoberfläche und in Benachrichtigungen zu berücksichtigen. Da es bei Verzögerungen zu Problemen mit Verzugsentschädigungen kommen kann, empfiehlt sich eine automatische Warnfunktion."},{"question":"Welche Punkte führen bei Teilrückerstattungen am häufigsten zu Problemen?","answer":"Häufig problematisch sind Gutscheine für die gesamte Bestellung, die Bedingungen für kostenlosen Versand, die Rücksendekosten, der verwendete Punktebetrag und die Verteilung von Rabatten auf einzelne Artikel. Damit der Betreiber nicht nach jedem Erstattungsantrag erneut eine Entscheidung treffen muss, sollten Regeln wie die Berechnung anhand des tatsächlich gezahlten Betrags pro Artikel oder eine anteilige Verteilung im Voraus festgelegt werden."},{"question":"Kann eine Doppelzahlung verhindert werden, indem im Frontend lediglich die Schaltfläche deaktiviert wird?","answer":"Das Deaktivieren der Schaltfläche ist hilfreich, reicht aber nicht aus. Da es zu erneuten Netzwerkversuchen, einem Neuladen der Seite und dem mehrfachen Empfang von Webhooks kommen kann, sind zusätzlich eine Bestellsperre auf Serverseite, ein Idempotenzschlüssel, eine Eindeutigkeitsbedingung für die Transaktionsnummer und eine statusbasierte Validierung erforderlich."},{"question":"Welche Informationen sollte ein Hinweis zu einer fehlgeschlagenen Zahlung enthalten?","answer":"Er sollte darauf hinweisen, dass die Zahlung nicht abgeschlossen wurde, aus welchem Grund sie fehlgeschlagen ist, ob ein erneuter Versuch möglich ist, wie lange die Bestellung aufrechterhalten wird und welche Bestellnummer bei einer Anfrage benötigt wird. Wird lediglich angezeigt, dass ein Fehler aufgetreten ist, führt dies zu mehr Kaufabbrüchen und Anfragen."},{"question":"Warum ist eine Seite mit dem Zahlungsverlauf unverzichtbar?","answer":"Weil Kunden selbst überprüfen können müssen, wann sie wie viel bezahlt haben und wie weit die Rückerstattung bearbeitet wurde. Ohne eine Seite mit dem Zahlungsverlauf gehen alle Überprüfungsanfragen beim Kundenservice ein, und Kunden könnten den Eindruck gewinnen, dass der Dienst den Geldfluss nicht ordnungsgemäß verwaltet."},{"question":"Reicht es aus, wenn die Rückerstattungsrichtlinien nur auf der Seite mit den Geschäftsbedingungen stehen?","answer":"Nein, das reicht nicht aus. Kunden müssen den Zeitraum, in dem eine Rückerstattung möglich ist, und die geltenden Einschränkungen auf der Produktdetailseite, im Bestellformular und in der Nähe der Zahlungsschaltfläche, wo sie ihre Kaufentscheidung treffen, leicht einsehen können. Wenn die Rückerstattungsrichtlinien versteckt werden oder die Schaltfläche zum Stornieren schwer zu finden ist, kann dies zu Kontroversen über Dark Patterns führen."},{"question":"Welchen Satz sollte man unbedingt in einen AI-Prompt aufnehmen?","answer":"Es empfiehlt sich, einen Satz aufzunehmen, der darum bittet, bei noch nicht festgelegten Richtlinien zuerst nachzufragen, bevor Code geschrieben wird. Dieser Satz dient als Sicherheitsvorkehrung, die die AI dazu veranlasst, bei leicht zu übersehenden Richtlinien wie dem Verfahren zur Genehmigung von Rückerstattungen, den Kriterien für den Abzug von Versandkosten und Ausnahmen bei Statusübergängen nachzufragen."},{"question":"Welche Erstattungsfunktionen werden in der Verwaltungsoberfläche benötigt?","answer":"Benötigt werden eine Liste der ausstehenden Erstattungen, das Antragsdatum, die Bearbeitungsfrist, Benachrichtigungen bei nahender Frist, eine Vorschau der Berechnung von Teilerstattungen, der Erstattungsgrund, ein Protokoll der Bearbeiter und eine Berechtigungsverwaltung. Da Erstattungen zu den wiederkehrenden betrieblichen Aufgaben gehören, ist es bei einer unzureichenden Verwaltungsoberfläche schwierig, die gesetzlichen Fristen einzuhalten und die Qualität des Kundenservice zu gewährleisten."},{"question":"Können bei Zahlungen für digitale Inhalte dieselben Erstattungsregelungen angewendet werden?","answer":"Bei digitalen Inhalten kann die Einschränkung des Widerrufsrechts davon abhängen, ob die Bereitstellung bereits begonnen hat, ob vorab darauf hingewiesen wurde und ob der Kunde zugestimmt hat. Daher müssen die Bedingungen für eine eingeschränkte Erstattung auf dem Bildschirm vor der Zahlung klar mitgeteilt und der Zeitpunkt der Zustimmung sowie die Version der Geschäftsbedingungen protokolliert werden."}],"sources":[{"url":"https://www.law.go.kr/법령/전자상거래등에서의소비자보호에관한법률","title":"Nationales Rechtsinformationszentrum: Gesetz über den Verbraucherschutz im elektronischen Geschäftsverkehr und Ähnlichem","type":"source"},{"url":"https://www.law.go.kr/법령/전자상거래등에서의소비자보호에관한법률시행령","title":"Nationales Rechtsinformationszentrum: Durchführungsverordnung zum Gesetz über den Verbraucherschutz im elektronischen Geschäftsverkehr usw.","type":"source"},{"url":"https://stripe.com/docs/idempotency","title":"Stripe-Dokumentation: Idempotente Anfragen","type":"source"},{"url":"https://docs.tosspayments.com/guides/v2/get-started/payment-flow","title":"Toss Payments Docs: Ablauf der Zahlungsintegration","type":"source"},{"url":"https://www.ftc.go.kr/","title":"Kommission für fairen Handel","type":"source"}],"images":[{"id":252,"url":"https://injoys.com/rails/active_storage/blobs/proxy/eyJfcmFpbHMiOnsiZGF0YSI6MjQ5NCwicHVyIjoiYmxvYl9pZCJ9fQ==--29af039afe5bc5fc5481b1fee11ed2dbd406a900/ai-bac80653.webp","is_representative":true,"generation_method":"ai_image","license":"ai_generated","mime_type":"image/webp","translations":{"ko":{"alt":"결제·배송·보안 아이콘과 연결된 중앙의 AI 두뇌 일러스트","caption":"AI 두뇌가 쇼핑, 카드 결제, 배송, 보안 등 결제 흐름의 요소와 연결되어 있다.","description":null},"en":{"alt":"Central AI brain connected to payment, shopping, delivery, security, and support icons","caption":"The illustration links an AI brain to key parts of an online payment flow.","description":null},"ja":{"alt":"決済、買い物、配送、セキュリティのアイコンにつながる中央のAI脳","caption":"AIの脳がオンライン決済フローの主要な要素につながっている。","description":null},"es":{"alt":"Cerebro de IA central conectado a iconos de pago, compras, entrega, seguridad y soporte","caption":"La ilustración conecta un cerebro de IA con partes clave del flujo de pago en línea.","description":null},"id":{"alt":"Otak AI di tengah terhubung ke ikon pembayaran, belanja, pengiriman, keamanan, dan dukungan","caption":"Ilustrasi ini menghubungkan otak AI dengan bagian penting dalam alur pembayaran online.","description":null},"pt":{"alt":"Cérebro de IA central conectado a ícones de pagamento, compras, entrega, segurança e suporte","caption":"A ilustração liga um cérebro de IA a etapas importantes do fluxo de pagamento online.","description":null},"zh-hant":{"alt":"中央 AI 大腦連接付款、購物、配送、安全與客服圖示","caption":"插圖呈現 AI 大腦與線上付款流程中的關鍵元素相連。","description":null}}},{"id":253,"url":"https://injoys.com/rails/active_storage/blobs/proxy/eyJfcmFpbHMiOnsiZGF0YSI6MjUwMCwicHVyIjoiYmxvYl9pZCJ9fQ==--a75febd0315285ecae10a5682f4409174d119e4c/ai-363d820f.webp","is_representative":false,"generation_method":"ai_image","license":"ai_generated","mime_type":"image/webp","translations":{"ko":{"alt":"결제 화면을 중심으로 보안, 분석, 구독, 배송, 오류 흐름이 연결된 일러스트","caption":"AI로 결제 기능을 설계할 때 고려할 핵심 요소들을 한눈에 보여준다.","description":null},"en":{"alt":"Checkout screen connected to panels for security, analytics, subscriptions, delivery, and errors","caption":"The illustration summarizes key areas to decide before building AI-powered payments.","description":null},"ja":{"alt":"決済画面を中心に、セキュリティ、分析、定期課金、配送、エラーがつながるイラスト","caption":"AIで決済機能を作る前に決めるべき要素を整理して示している。","description":null},"es":{"alt":"Pantalla de pago conectada con paneles de seguridad, análisis, suscripción, envío y errores","caption":"La ilustración resume aspectos clave antes de crear pagos con IA.","description":null},"id":{"alt":"Layar checkout terhubung ke panel keamanan, analitik, langganan, pengiriman, dan kesalahan","caption":"Ilustrasi ini merangkum hal penting sebelum membangun pembayaran dengan AI.","description":null},"pt":{"alt":"Tela de checkout conectada a painéis de segurança, análise, assinatura, entrega e erros","caption":"A ilustração resume decisões importantes antes de criar pagamentos com IA.","description":null},"zh-hant":{"alt":"結帳畫面連接安全、分析、訂閱、配送與錯誤流程面板的插圖","caption":"這張插圖概述用 AI 建立付款功能前需先決定的重點。","description":null}}}],"published_at":"2026-07-22T08:42:09+09:00","updated_at":"2026-07-22T08:42:09+09:00","license":"cc_by","translation_status":"reviewed","available_locales":["ko","en","ja","es"],"data_locales":["ko","en","ja","es","id","pt","zh-hant","de"],"url":"https://injoys.com/en/articles/ai-payment-feature-7-core-decisions"}