Micropayment Call2Pay

Micropayment Call2Pay richtet die telefonbasierte Zahlungsart der Micropayment-Gruppe ein. Die Seite erklärt Projektzugang, Status- und Rechnungseinstellungen, Gestaltung, normalen Checkout, Direktkauf für virtuelle Produkte und die Protokolle in der Bestellung.

Einordnung

Diese Unterseite gehört zur Micropayment-Gruppe und betrifft die Variante Call2Pay. Allgemeine Zahlungsart-Einstellungen wie Aktivierung, Kundengruppen, Versandarten, Versandzonen und Betragsgrenzen bleiben in der übergeordneten Zahlungsart gepflegt.

Zugangsdaten und Testmodus

• mp_kdnr: Kundennummer des Micropayment-Kontos. Der Wert wird im Zahlungsaufruf als Account übergeben.
• mp_cp_projectidentifer: Projektkürzel des Call2Pay-Projekts. Dieses Feld ist variantenbezogen und unterscheidet Call2Pay von den anderen Micropayment-Unterseiten.
• mp_accesskey: AccessKey für die Signatur. Der Shop bildet aus den versiegelten Parametern und diesem Schlüssel den seal.
• sandbox: vorhandene Konfigurationsvariable für den Testbetrieb. In der Call2Pay-Klasse wird dieser Wert gespeichert, im Zahlungsrequest aber nicht als eigener Parameter übergeben.

Status und Rechnungen

• order_status_ok: Bestellstatus nach erfolgreicher Zahlung.
• status_ok_createBill: steuert, ob bei erfolgreicher Zahlung eine Rechnung erzeugt wird. Im Bootstrap-Formular kann das Feld gesperrt sein, wenn die FiBu nicht aktiv ist.
• status_ok_sendBill: steuert, ob die erzeugte Rechnung nach erfolgreicher Zahlung versendet wird. Auch dieses Feld kann bei inaktiver FiBu gesperrt sein.
• order_status_error: Bestellstatus für fehlgeschlagene oder abgebrochene Zahlungsprozesse.

Die Statusfelder greifen auf die im Shop vorhandenen Bestellstatus zurück. Die Auswahl sollte zum Versand- und Rechnungslauf passen, damit erfolgreiche Telefonzahlungen nicht manuell nachbearbeitet werden müssen.

Layout, Kampagne und Direktkauf

• mp_theme: Layoutname für die Micropayment-Zahlungsseite.
• mp_bgcolor: Hintergrundfarbe für die externe Zahlungsseite.
• mp_gfx: Logo- oder Grafikwert für die externe Zahlungsseite.
• mp_projectcampaign: Kampagne des Projektinhabers, die zusätzlich an Micropayment übertragen wird.
• mp_directbuy: aktiviert den Direktkauf für virtuelle Produkte. Bei aktivem Wert kann am virtuellen Produkt ein Call2Pay-Direktkaufbutton erscheinen.

Speichern und Projekthinweis

Beim Speichern übernimmt das Backend die Formularwerte in die Konfiguration der Call2Pay-Zahlart. Die Infobox im Formular verweist auf die Micropayment-Projekteinrichtung und unterstützt beim Abgleich von Kundennummer, Projektkürzel und AccessKey.

1. Kundennummer, Call2Pay-Projektkürzel und AccessKey eintragen.
2. Status- und Rechnungseinstellungen mit dem gewünschten Bestellablauf abstimmen.
3. Layoutwerte nur setzen, wenn das Micropayment-Projekt eine angepasste Darstellung nutzt.
4. Direktkauf nur aktivieren, wenn virtuelle Produkte diesen Zahlungsweg nutzen sollen.
5. Speichern und danach normalen Checkout sowie Direktkauf getrennt testen.

Normaler Checkout

Beim normalen Zahlungsaufruf baut der Shop die Call2Pay-Anfrage aus Bestell- und Kundendaten auf. Übertragen werden Projekt, Kundennummer, Betrag in Cent, Bestellnummer, Lieferland, Währung, Modul, Layoutwerte, Kampagne und Kundendaten wie Name, E-Mail, Adresse, Postleitzahl, Ort und Land.

Aus den Parametern entsteht eine versiegelte Parameterfolge. Zusammen mit mp_accesskey erzeugt der Shop den seal und leitet danach zur Micropayment-Zahlungsseite weiter.

Direktkauf für virtuelle Produkte

Wenn mp_directbuy aktiv ist, kann Call2Pay einen Direktkaufbutton für virtuelle Produkte ausgeben. Der Direktkaufpfad ist nur für aktivierte Micropayment-Varianten Call2Pay und HandyPay vorgesehen und bricht ab, wenn kein gültiges Modul, kein Produkt oder kein virtuelles Produkt erkannt wird.

• Der Betrag wird aus dem aktuellen Produktpreis berechnet und in Cent an Micropayment übergeben.
• Die Bestellung wird im Direktkaufkontext über die Produkt-ID referenziert.
• Für den Direktkauf wird die Call2Pay-DirectBuy-Variante verwendet.
• Der Zahlungsaufruf wird ebenfalls signiert und anschließend an Micropayment weitergeleitet.

Direktkauf sollte nach Änderungen immer an einem echten virtuellen Testprodukt geprüft werden, weil dieser Ablauf andere Daten als der normale Warenkorb-Checkout verwendet.

Rückkehr, Erfolg und Abbruch

• Erfolgreiche Rückkehr: Der Shop aktualisiert Gutschein- und Umsatzdaten, leert den Warenkorb und führt zur Abschlussseite.
• Abbruch: Der noch nicht abgeschlossene Auftrag wird entfernt und der Warenkorb wird wieder angesteuert.
• Serverrückmeldung: Zahlungsstatus, Transaktionsnummer und Logdaten werden in der Call2Pay-Protokolltabelle gespeichert.

Die Rückkehrlogik entspricht der Micropayment-Gruppe. Nach einer Änderung sollten erfolgreicher Abschluss, Abbruch und fehlerhafte Rückmeldung mit kleinen Beträgen geprüft werden.

Bestellansicht und Serverlogs

In der Bestellansicht zeigt das Modul den aktuellen Transaktionsstatus und darunter die gespeicherten Micropayment-Rückmeldungen. Die Logliste ist eine feste Tabelle und keine konfigurierbare Datentabelle.

• Datum/Zeit: Zeitstempel der gespeicherten Rückmeldung.
• Type: lesbarer Status. billing wird als erfolgreich, storno als storniert und backpay als erfolgreich nach Storno dargestellt. Andere Werte bleiben als unbekannt sichtbar.
• Auth/Ident-Nummer: gespeicherte Transaktions- oder Identnummer aus der Rückmeldung.
• ServerLogs: aufklappbarer Detailbereich mit dem gespeicherten Rückmeldeprotokoll.

Die Tabelle besitzt keine Optionsspalte, keine Sortierkonfiguration und keine Spaltenauswahl. Für diese feste Bestellansicht wird deshalb kein Spalten-Snippet verwendet.

Filter, Tabellen und Aktionen

• Die Konfigurationsseite besitzt keine Suche und keine Datenfilter.
• Es gibt keine Übersichtstabelle mit Zeilenaktionen.
• Die sichtbare Formularaktion ist das Speichern der Zahlungsartkonfiguration.
• Die Bestellansicht enthält nur die feste Logtabelle mit Status- und Protokolldaten.
• Der Direktkaufbutton ist eine Frontend-Aktion am virtuellen Produkt, keine Backend-Tabellenaktion.

Prüfung nach Änderungen

1. Normale Call2Pay-Zahlung mit kleinem Betrag starten.
2. Projektkürzel, Kundennummer und AccessKey prüfen, wenn Micropayment den Aufruf ablehnt.
3. Nach erfolgreicher Rückkehr Bestellstatus, Warenkorbabschluss und Rechnungsoptionen kontrollieren.
4. Abbruch testen und prüfen, ob der nicht abgeschlossene Auftrag entfernt wird.
5. Bei aktivem Direktkauf ein virtuelles Produkt testen und die Weiterleitung separat prüfen.
6. In der Bestellansicht Logtabelle, Statusanzeige und ServerLogs kontrollieren.