---
title: "7 Entscheidungen vor der Entwicklung einer Bezahlfunktion mit KI"
locale: de
category: how_to
category_name: "Anleitungen"
translation_status: reviewed
license: cc_by
author: "injoys"
source_url: https://injoys.com/en/articles/ai-payment-feature-7-core-decisions
published_at: 2026-07-22T08:42:09+09:00
---

# 7 Entscheidungen vor der Entwicklung einer Bezahlfunktion mit KI

> 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.

## 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.

## Kernaussagen

Der 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.

Technisch 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.

| Entscheidungsbereich | Vorab zu klärende Frage | Risiko bei Fehlern |
|---|---|---|
| Bestellstatus | Welche Status durchläuft eine Bestellung in welcher Reihenfolge? | Es entstehen Geisterbestellungen, bei denen bezahlt wurde, aber keine Bestellung vorhanden ist |
| Erstattungsfrist | Wie werden Widerruf und Bearbeitungsfristen für Erstattungen berücksichtigt? | Verletzung gesetzlicher Fristen, Verzugszinsen und Streitrisiken |
| Teilerstattung | Wie werden die Rückgabe einzelner Artikel, Gutscheine und Versandkosten berechnet? | Jedes Mal manuelle Berechnung durch das Betriebsteam, Misstrauen der Kunden |
| Doppelzahlung | Wie wird verhindert, dass dieselbe Bestellung zweimal abgerechnet wird? | Kundenbeschwerden aufgrund der Kartenabrechnung, Vertrauensverlust |
| Fehlermeldung | Wie werden Überschreitung des Limits, unzureichendes Guthaben und fehlgeschlagene Authentifizierung kommuniziert? | Sinkende Konversionsrate bei erneuten Versuchen, mehr unnötige Anfragen |
| Zahlungsverlauf | Wo können Kunden den Zahlungs- und Erstattungsstatus prüfen? | Mehr Kundendienstanfragen, intransparenter Status |
| Erstattungshinweis | Wo werden Erstattungsregeln und die Schaltfläche zum Stornieren platziert? | Diskussionen über Dark Patterns, regulatorische Risiken |

## 1. Gestaltung der Bestellstatus: Der Status ist die Sprache des Betriebs

Bei 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.

### Beispiel für empfohlene Status

| Beispiel für Statuscode | Für Kunden sichtbarer Status | Bedeutung |
|---|---|---|
| `payment_pending` | Zahlung ausstehend | Die Bestellung wurde erstellt, aber die Zahlung ist noch nicht abgeschlossen |
| `paid` | Zahlung abgeschlossen | Die Zahlung wurde autorisiert und die Bestellung ist gültig |
| `payment_failed` | Zahlung fehlgeschlagen | Der Zahlungsversuch ist fehlgeschlagen und es muss geprüft werden, ob ein erneuter Versuch möglich ist |
| `cancel_requested` | Stornierung beantragt | Der Kunde hat eine Stornierung beantragt, die noch bearbeitet werden muss |
| `cancelled` | Stornierung abgeschlossen | Die Stornierung der Bestellung vor der Zahlung oder die Aufhebung der Autorisierung ist abgeschlossen |
| `refund_requested` | Erstattung beantragt | Nach der Zahlung ist ein Erstattungsantrag eingegangen |
| `refund_processing` | Erstattung wird bearbeitet | Die Erstattung wird genehmigt oder über das Zahlungsmittel abgewickelt |
| `partially_refunded` | Teilerstattung abgeschlossen | Nur ein Teil des Bestellbetrags wurde erstattet |
| `refunded` | Erstattung abgeschlossen | Die Erstattung ist abgeschlossen |
| `expired` | Bestellung abgelaufen | Die Wartezeit für die Zahlung ist abgelaufen und die Bestellung wurde ungültig |

### Grundsätze für die Statusgestaltung

- 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.
- Bei jeder Statusänderung werden Zeitpunkt, Bearbeiter, Grund, Kennung der Zahlungstransaktion und Kennung der Erstattungstransaktion protokolliert.
- Kundenansicht, Administrationsansicht und Formulierungen des Kundendienstes müssen dieselben Statusdefinitionen verwenden.
- Statusübergänge werden unidirektional gestaltet. Die Wiederherstellung nach Ausnahmen erfolgt mit gesonderten Administratorrechten und wird protokolliert.

## 2. Widerruf und gesetzliche Erstattungsfrist: keine Richtlinie, sondern eine rechtliche Anforderung

Wer 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.

In der Praxis sind insbesondere die folgenden Kriterien wichtig.

- Verbraucher können grundsätzlich innerhalb von 7 Tagen ab dem gesetzlich festgelegten Stichtag, etwa dem Tag des Erhalts der Waren, widerrufen.
- 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.
- 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.
- Die konkrete Anwendung kann je nach Produkttyp, Vertragsform, den Verbrauchern erteilten Hinweisen und Beginn der Nutzung variieren. Daher ist eine rechtliche Prüfung erforderlich.

### Umwandlung in Entwicklungsanforderungen

Es reicht nicht aus, gesetzliche Vorgaben nur in den AGB festzuhalten. Sie müssen auch in Systemanforderungen umgesetzt werden.

| Gesetzliche oder richtlinienbezogene Anforderung | Systemanforderung |
|---|---|
| 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 |
| Erstattung innerhalb von 3 Werktagen erforderlich | Anzeige des Erstattungsantragsdatums und der Bearbeitungsfrist in der Administrationsansicht |
| Risiko einer verzögerten Erstattung | Hinweise bei nahendem und überschrittenem Fristende |
| 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 |
| Vorbereitung auf Streitfälle erforderlich | AGB-Version, Zeitpunkt des Hinweises, Zeitpunkt der Zustimmung sowie Kunden-IP oder Kontoprotokolle aufbewahren |

## 3. Regeln für Teilerstattungen: Gutscheine, Versandkosten und Steuern vorab definieren

Teilerstattungen 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.

### Unbedingt festzulegende Punkte

- Wie der Zahlungsbetrag pro Artikel zugeordnet wird
- Ob ein Gutschein für die gesamte Bestellung proportional auf die einzelnen Artikel verteilt wird
- Ob ein Gutschein für einen bestimmten Artikel nur auf diesen Artikel angewendet wird
- Ob Versandkosten abgezogen werden, wenn die Bedingung für kostenlosen Versand nachträglich nicht mehr erfüllt ist
- Wie Rücksendekosten bei bloßem Meinungswechsel von Rücksendekosten wegen eines Produktmangels unterschieden werden
- In welcher Reihenfolge mit Punkten, Guthaben und Geschenkkarten bezahlte Beträge erstattet werden
- Wie Rechnungen, Barzahlungsbelege und Quittungen nach einer Teilerstattung angepasst werden

### Beispiel für die Berechnung einer Teilerstattung

| Posten | Betrag |
|---|---:|
| Artikel A | 30,000원 |
| Artikel B | 70,000원 |
| Gutschein für die gesamte Bestellung | -10,000원 |
| Tatsächlicher Zahlungsbetrag | 90,000원 |

Wird 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.

Es 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.

## 4. Verhinderung von Doppelzahlungen: Das Deaktivieren der Schaltfläche reicht nicht aus

Doppelzahlungen 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.

### Ursachen

- Der Kunde klickt mehrmals hintereinander auf die Zahlungsschaltfläche
- Der Kunde aktualisiert die Seite unmittelbar nach der Zahlung oder klickt auf „Zurück“
- Aufgrund einer Verzögerung im Mobilfunknetz wird dieselbe Anfrage erneut gesendet
- Die Antwort auf die Zahlungsautorisierung ist erfolgreich, aber die Speicherung auf dem Dienstserver schlägt fehl
- Webhook und Client-Weiterleitung ändern den Bestellstatus gleichzeitig

### Schutzmechanismen

| Schutzmaßnahme | Beschreibung |
|---|---|
| Sperrung der Client-Schaltfläche | Verhindert erneutes Klicken nach dem Klick auf die Zahlungsschaltfläche, wird aber nur als ergänzende Maßnahme verwendet |
| Serverseitige Bestellsperre | Verhindert, dass für dieselbe Bestell-ID gleichzeitig mehrere Anfragen zur Zahlungsautorisierung ausgeführt werden |
| Idempotenzschlüssel | Verwendet eine Kennung, durch die auch bei mehrmaligem Senden derselben Zahlungsanfrage nur ein Ergebnis erzeugt wird |
| Eindeutige Transaktionsnummer | Verhindert durch Datenbank-Constraints die doppelte Speicherung von Bestellnummer und Zahlungstransaktionsnummer |
| Statusbasierte Prüfung | Verhindert zusätzliche Autorisierungsanfragen für Bestellungen, die bereits den Status `paid` haben |
| Deduplizierung von Webhooks | Stellt sicher, dass eine Statusänderung nur einmal erfolgt, auch wenn dasselbe Webhook-Ereignis mehrfach eingeht |

Wenn 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.

## 5. Hinweise bei Zahlungsfehlern: Ein Fehlschlag ist kein Vorfall, sondern ein normaler Ablauf

Zahlungsfehler 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.

Ein 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.

### Beispiele für Hinweise

| Situation | Empfohlener Hinweis |
|---|---|
| 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. |
| 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. |
| 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. |
| Netzwerkfehler | Die Bestätigung des Zahlungsergebnisses verzögert sich. Um eine Doppelzahlung zu vermeiden, prüfen Sie bitte nach kurzer Zeit den Zahlungsverlauf. |
| 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. |

### Kernelemente eines Hinweises bei Fehlern

- Es wird eindeutig mitgeteilt, ob die Zahlung tatsächlich nicht abgeschlossen wurde.
- Es wird angegeben, wie lange die Bestellung bestehen bleibt.
- Es wird erklärt, ob ein erneuter Versuch möglich ist oder ein anderes Zahlungsmittel verwendet werden muss.
- Die für eine Anfrage beim Kundendienst erforderliche Bestellnummer wird angezeigt.
- Wenn das Zahlungsergebnis unklar ist, darf nicht bedingungslos zu einer erneuten Zahlung aufgefordert werden. Stattdessen muss der Status „Wird geprüft“ angeboten werden.

## 6. Seite mit dem Zahlungsverlauf: die zentrale Ansicht zur Entlastung des Kundendienstes

Ohne 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.

### Informationen auf der Seite mit dem Zahlungsverlauf

- Bestellnummer
- Bestellzeitpunkt und Zahlungszeitpunkt
- Produktname, Menge und Optionen
- Zahlungsmittel und Autorisierungsnummer oder Transaktionskennung
- Warenwert, Rabatt, Versandkosten, verwendete Punkte und endgültiger Zahlungsbetrag
- Aktueller Bestellstatus und Erstattungsstatus
- Datum des Erstattungsantrags, Datum der Erstattungsgenehmigung und voraussichtliches Abschlussdatum der Erstattung
- Angabe, ob eine Stornierung oder Erstattung möglich ist
- Links zu Beleg, Transaktionsübersicht und Barzahlungsbeleg
- Für Anfragen beim Kundendienst benötigte Informationen

### Verknüpfung mit der Betreiberansicht

Kundenansicht 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.

## 7. Platzierung der Erstattungsregeln: Versteckte Regeln werden zum Risiko

Es 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.

### Geeignete Stellen für Hinweise

- In der Nähe des Preises oder der Kaufschaltfläche auf der Produktdetailseite
- Im Warenkorb oder auf der Bestellseite
- Im Bereich zur Zustimmung zu AGB und Erstattungsregeln direkt oberhalb der Zahlungsschaltfläche
- Auf der Zahlungsbestätigungsseite
- In der Bestelldetailansicht des persönlichen Bereichs
- Auf der Seite für Erstattungsanträge

### Zu vermeidende Gestaltungen

- 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
- Eine Gestaltung, bei der die Schaltfläche zum Stornieren tief in mehreren Schritten verborgen ist
- Eine Gestaltung, bei der Einschränkungen der Erstattung erst nach der Zahlung angezeigt werden
- Eine Gestaltung, bei der Farbe, Formulierung und Reihenfolge der Schaltflächen so angeordnet sind, dass Kunden irregeführt werden
- Eine Gestaltung, bei der nicht klar auf die automatische Zahlung nach Ende eines kostenlosen Testzeitraums hingewiesen wird

Solche 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.

## Checkliste für einen Prompt an eine AI

Wenn ein AI-Entwicklungstool mit der Implementierung einer Zahlungsfunktion beauftragt wird, müssen zunächst die Richtlinien wie folgt übermittelt werden.

### Beispiel für einen Prompt zur Zahlungsfunktion

```text
Implementiere die Zahlungsfunktion eines koreanischen E-Commerce-Dienstes für Verbraucher.
Berücksichtige dabei unbedingt die folgenden Richtlinien.

1. Verwende für den Bestellstatus payment_pending, paid, payment_failed, cancel_requested, cancelled, refund_requested, refund_processing, partially_refunded, refunded und expired.
2. Ändere Bestellungen mit ausstehender Zahlung nach 30 Minuten in expired.
3. Erlaube für dieselbe Bestellung nur 1 Zahlungsautorisierung und verwende eine serverseitige Bestellsperre sowie einen Idempotenzschlüssel.
4. Da Zahlungs-Webhooks mehrfach empfangen werden können, darf dieselbe Ereignis-ID nur einmal verarbeitet werden.
5. Speichere das Datum des Erstattungsantrags, die Bearbeitungsfrist für die Erstattung, den Bearbeiter, den Grund und die Erstattungstransaktionsnummer.
6. Berechne Teilerstattungen anhand des tatsächlich gezahlten Betrags je Artikel und verteile einen Gutschein für die gesamte Bestellung proportional zum Warenwert.
7. Gib bei einem Zahlungsfehler je nach Fehlergrund einen entsprechenden Kundenhinweis zurück.
8. Ermögliche Kunden, im persönlichen Bereich ihren Zahlungsverlauf und Erstattungsstatus zu prüfen.
9. 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.
10. Wenn Richtlinien nicht festgelegt sind, stelle zuerst Fragen, bevor du Code schreibst.
```

Der 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.

## Erforderliche Funktionen der Betreiberansicht

Eine Zahlungsfunktion ist nicht allein mit der Kundenansicht vollständig. Da Erstattungen und Stornierungen täglich anfallende Betriebsaufgaben sind, ist eine Administrationsansicht zwingend erforderlich.

| Administratorfunktion | Grund |
|---|---|
| Liste ausstehender Erstattungen | Erforderlich, damit zu bearbeitende Erstattungen nicht übersehen werden |
| Anzeige der gesetzlichen Bearbeitungsfrist | Erforderlich, um das Risiko verzögerter Erstattungen zu verringern |
| Warnung bei nahendem oder überschrittenem Fristende | Erforderlich, damit Betreiber interne Vorgaben wie 3 Werktage sofort erkennen |
| Auswahl des Erstattungsgrunds | Erforderlich für Statistiken und Kostenverteilung, etwa bei Meinungswechsel, Produktmängeln oder Falschlieferungen |
| Vorschau der Teilerstattungsberechnung | Erforderlich, um manuelle Berechnungsfehler der Betreiber zu reduzieren |
| Bearbeitungsprotokoll | Erforderlich für Streitfälle und Prüfungen |
| Rechteverwaltung | Erforderlich, um die Genehmigung von Erstattungen und erzwungene Statusänderungen einzuschränken |

## Mindestumfang des Zahlungsdatenmodells

Die Datenstruktur unterscheidet sich je nach Dienst. Mindestens die folgenden Daten sollten jedoch getrennt gehalten werden.

| Tabelle oder Objekt | Zentrale Felder |
|---|---|
| Bestellung | Bestell-ID, Kunden-ID, Bestellstatus, Bestellbetrag, Rabattbetrag, Versandkosten, Erstellungszeitpunkt, Ablaufzeitpunkt |
| Bestellartikel | Produkt-ID, Produktname, Optionen, Menge, Betrag je Artikel, zugeordneter Rabattbetrag je Artikel |
| Zahlung | Zahlungs-ID, Bestell-ID, Zahlungsmittel, Autorisierungsnummer, autorisierter Betrag, Zahlungsstatus, Autorisierungszeitpunkt |
| Erstattung | Erstattungs-ID, Bestell-ID, Erstattungsbetrag, Erstattungsgrund, Erstattungsstatus, Antragszeitpunkt, Abschlusszeitpunkt |
| Statusverlauf | Ziel-ID, vorheriger Status, neuer Status, Ändernder, Änderungsgrund, Änderungszeitpunkt |
| Zustimmung zu AGB | Art der AGB, AGB-Version, Zustimmungsstatus, Zustimmungszeitpunkt, Kunden-ID |

Wichtig 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.

## Checkliste vor der Veröffentlichung

- Wird die Zahlung für dieselbe Bestellung nur 1-mal autorisiert, auch wenn die Zahlungsschaltfläche 10-mal gedrückt wird?
- Ist eine Wiederherstellung möglich, wenn die Speicherung auf dem Server nach der Zahlungsautorisierung fehlschlägt?
- Wird ein Zahlungs-Webhook nicht doppelt verarbeitet, auch wenn dasselbe Ereignis mehrfach gesendet wird?
- Können Kunden den Grund für einen Zahlungsfehler und die Methode für einen erneuten Versuch verstehen?
- Laufen Bestellungen mit ausstehender Zahlung nach einer bestimmten Zeit automatisch ab?
- Entspricht der Teilerstattungsbetrag den Richtlinien für Gutscheine, Punkte und Versandkosten?
- Werden der Zeitraum vom Erstattungsantrag bis zur Bearbeitungsfrist und das Fristende in der Administrationsansicht angezeigt?
- Sind die Erstattungsregeln vor der Zahlung leicht einsehbar?
- Gibt es bei digitalen Inhalten oder Produkten mit eingeschränkter Erstattung vorherige Hinweise und Zustimmungsprotokolle?
- Können Kunden ihren Zahlungsverlauf und Erstattungsstatus im persönlichen Bereich selbst prüfen?

## Fazit

Eine 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.

Wenn 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.

## FAQ

### Was muss zuerst festgelegt werden, wenn man eine KI anweist, eine Zahlungsfunktion zu erstellen?
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.

### Warum ist es riskant, als einzigen Bestellstatus einfach „Bestellung abgeschlossen“ zu verwenden?
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.

### Gilt die 7-Tage-Regel für den Widerruf im koreanischen elektronischen Geschäftsverkehr immer?
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.

### Bis wann muss eine Rückerstattung bearbeitet werden?
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.

### Welche Punkte führen bei Teilrückerstattungen am häufigsten zu Problemen?
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.

### Kann eine Doppelzahlung verhindert werden, indem im Frontend lediglich die Schaltfläche deaktiviert wird?
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.

### Welche Informationen sollte ein Hinweis zu einer fehlgeschlagenen Zahlung enthalten?
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.

### Warum ist eine Seite mit dem Zahlungsverlauf unverzichtbar?
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.

### Reicht es aus, wenn die Rückerstattungsrichtlinien nur auf der Seite mit den Geschäftsbedingungen stehen?
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.

### Welchen Satz sollte man unbedingt in einen AI-Prompt aufnehmen?
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.

### Welche Erstattungsfunktionen werden in der Verwaltungsoberfläche benötigt?
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.

### Können bei Zahlungen für digitale Inhalte dieselben Erstattungsregelungen angewendet werden?
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

- [Nationales Rechtsinformationszentrum: Gesetz über den Verbraucherschutz im elektronischen Geschäftsverkehr und Ähnlichem](https://www.law.go.kr/법령/전자상거래등에서의소비자보호에관한법률)
- [Nationales Rechtsinformationszentrum: Durchführungsverordnung zum Gesetz über den Verbraucherschutz im elektronischen Geschäftsverkehr usw.](https://www.law.go.kr/법령/전자상거래등에서의소비자보호에관한법률시행령)
- [Stripe-Dokumentation: Idempotente Anfragen](https://stripe.com/docs/idempotency)
- [Toss Payments Docs: Ablauf der Zahlungsintegration](https://docs.tosspayments.com/guides/v2/get-started/payment-flow)
- [Kommission für fairen Handel](https://www.ftc.go.kr/)

## Images

![결제·배송·보안 아이콘과 연결된 중앙의 AI 두뇌 일러스트](https://injoys.com/rails/active_storage/blobs/proxy/eyJfcmFpbHMiOnsiZGF0YSI6MjQ5NCwicHVyIjoiYmxvYl9pZCJ9fQ==--29af039afe5bc5fc5481b1fee11ed2dbd406a900/ai-bac80653.webp)
![결제 화면을 중심으로 보안, 분석, 구독, 배송, 오류 흐름이 연결된 일러스트](https://injoys.com/rails/active_storage/blobs/proxy/eyJfcmFpbHMiOnsiZGF0YSI6MjUwMCwicHVyIjoiYmxvYl9pZCJ9fQ==--a75febd0315285ecae10a5682f4409174d119e4c/ai-363d820f.webp)