Micropayment

Micropayment bündelt mehrere eigenständige Zahlungsarten. Die Parent-Seite ordnet die Varianten, gemeinsame Einrichtung, Zahlungsweiterleitung, Rückmeldungen, Bestelllogs und den Direktkauf-Bezug ein.

Einordnung

Diese Seite ist die Übersicht für die Micropayment-Gruppe. Die konkreten Formularfelder der einzelnen Zahlungsarten liegen auf den Unterseiten, weil jede Variante ein eigenes Zahlungsmodul, eine eigene Projektkennung und eine eigene Logtabelle nutzt.

• Micropayment CreditCard: Kreditkartenzahlung mit Projektfeld mp_cc_projectidentifer.
• Micropayment Call2Pay: telefonbasierte Zahlung mit Projektfeld mp_cp_projectidentifer und optionalem Direktkauf.
• Micropayment Vorkasse: vorauszahlungsnaher Ablauf mit Projektfeld mp_ep_projectidentifer.
• Micropayment HandyPay: mobile Zahlung mit Projektfeld mp_hp_projectidentifer und optionalem Direktkauf.
• Micropayment Lastschrift: Lastschriftzahlung mit Projektfeld mp_ls_projectidentifer.
• Micropayment SOFORT Überweisung: Sofortüberweisung mit Projektfeld mp_cc_projectidentifer in der SOFORT-Konfiguration.

Gemeinsame Einrichtung

Alle Varianten verwenden dieselbe Grundstruktur für die Verbindung zum Anbieter.

• mp_kdnr: Kundennummer des Micropayment-Kontos.
• Projektkennung: zahlartbezogenes Projektfeld, das die Anfrage dem richtigen Micropayment-Projekt zuordnet.
• mp_accesskey: Schlüssel zur Signatur der Zahlungsparameter.
• sandbox: schaltet bei den Varianten mit Testmodus-Unterstützung den Testbetrieb ein.
• order_status_ok: Bestellstatus für erfolgreich gemeldete Zahlungen.
• status_ok_createBill: erstellt bei erfolgreicher Zahlung eine Rechnung; im neuen Backend vom aktiven FiBu-Modul abhängig.
• status_ok_sendBill: sendet die erzeugte Rechnung; ebenfalls vom aktiven FiBu-Modul abhängig.
• order_status_error: Bestellstatus für Storno, Abbruch oder Fehler.
• mp_theme, mp_bgcolor, mp_gfx und mp_projectcampaign: Darstellungs- und Kampagnenwerte für das Micropayment-Zahlfenster.

Jede Unterseite bietet zusätzlich einen Infodialog zur Projekteinrichtung. Dieser Dialog unterstützt die Einrichtung, ersetzt aber nicht die zahlartbezogene Konfiguration.

Zahlungsweiterleitung

Beim Checkout erzeugt das jeweilige Micropayment-Modul eine signierte Anfrage und leitet zur passenden Micropayment-Zahlseite weiter.

• project: Projektkennung der gewählten Zahlart.
• title: Bestellnummer oder Produktname als Bezeichnung der Zahlung.
• amount: Betrag in kleinster Währungseinheit.
• account: Kundennummer aus mp_kdnr.
• country und currency: Land und Währung der Bestellung.
• orderid: Bestell-ID oder beim Direktkauf die Artikel-ID.
• modul: technischer Micropayment-Zahlweg, zum Beispiel Kreditkarte, Call2Pay, Vorkasse, HandyPay, Lastschrift oder SOFORT.
• seal: MD5-Signatur aus den übertragenen Parametern und mp_accesskey.

Kundendaten wie E-Mail, Name und Adresse werden bei den Checkout-Zahlungen ebenfalls an die Zahlungsanfrage gehängt, soweit die jeweilige Variante diese Daten befüllt.

Rückmeldungen und Bestellstatus

Die Varianten speichern empfangene Zahlungsereignisse je Bestellung in eigenen Micropayment-Tabellen. Der gespeicherte Datensatz enthält Bestellbezug, Status, Zeitpunkt, Transaktions- oder Identnummer und den Logtext.

• billing: markiert die Zahlung als erfolgreich.
• storno: markiert die Zahlung als storniert.
• backpay: markiert eine Zahlung nach vorherigem Storno wieder als erfolgreich.
• init: kann als initiales Ereignis protokolliert werden; die Statusanzeige bewertet nicht jeden technischen Zwischenstatus als Erfolg.

Bei erfolgreicher Browser-Rückkehr werden Gutscheincodes aktualisiert, der Warenkorb wird geleert und der Umsatz der Kundschaft wird erhöht. Bei Abbruch wird die noch nicht abgeschlossene Bestellung gelöscht.

Bestellanzeige und Logs

In der Bestellansicht zeigt jede Micropayment-Variante den aktuellen Status und eine chronologische Logtabelle.

• Datum/Zeit: Zeitpunkt des gespeicherten Ereignisses.
• Type: übersetzter Status, zum Beispiel erfolgreich, storniert oder erfolgreich nach Storno.
• Auth/Ident-Nummer: gespeicherte Transaktionskennung.
• ServerLogs: einklappbarer Bereich mit den gespeicherten Rückmeldeparametern.

Die Loganzeige ist keine konfigurierbare BsTable, sondern eine feste Bestelldetailanzeige aus den Micropayment-Logtabellen.

Direktkauf für virtuelle Produkte

Call2Pay und HandyPay enthalten zusätzlich mp_directbuy. Bei aktivem Schalter und aktiver Zahlungsart erzeugt die Produktanzeige Direktkauf-Buttons für virtuelle Produkte.

• Der Direktkauf wird nur für die Module Call2Pay und HandyPay erzeugt.
• Die Produktanzeige fragt den Aktivstatus der jeweiligen Zahlungsart ab.
• Der Direktkauf nutzt die Artikel-ID als Bestellbezug für die Micropayment-Anfrage.
• Die Anzeige erfolgt über die Direct-Buy-Templates des aktiven Themes.

Filter, Tabellen und Optionen

Die Parent-Seite enthält keine eigene filterbare Liste, keinen DataFilter, keine Optionsspalte und keine konfigurierbare BsTable. Deshalb wird kein Spalten-Snippet verwendet.

• Die sichtbaren Unterseiten werden über die Handbuch-Struktur angezeigt.
• Formularfelder werden auf den Unterseiten der sechs Zahlungsarten gepflegt.
• Bestelllogs entstehen erst in der jeweiligen Bestelldetailansicht.
• Rückzahlungs- oder Stornoaktionen sind auf dieser Parent-Seite nicht vorhanden.

Prüfung nach Änderungen

• Für Änderungen immer die konkrete Unterseite der betroffenen Zahlungsart öffnen.
• Nach Änderung von Kundennummer, Projektkennung oder AccessKey eine Testzahlung der jeweiligen Variante durchführen.
• Nach Statusänderungen erfolgreiche Zahlung, Storno und Rückkehr in der Bestellung prüfen.
• Bei Call2Pay und HandyPay zusätzlich den Direktkauf mit einem virtuellen Produkt testen.
• In der Bestellansicht kontrollieren, ob Status, Transaktionskennung und ServerLog plausibel gespeichert werden.