Das Anbinden eines Payment-Dienstes zum Validieren der Zahlungsdaten ist eine Aktion, die bei jedem Onlineshop früher oder später ansteht. Mittlerweile gebiet es eine Vielzahl guter Payment-Anbieter, die je nach Größe Ihres Shops passende Produkte anbieten.
Die meisten Payment-Dienste kommunizieren über XML-Schnittstellen. Man schickt ein gefülltes XML-Dokument an einen Webservice oder via HTTP-Request an eine definierte Adresse. Als Antwort bekommt man letztendlich eine Transaktions-Nummer oder eine Rücksprung-Adresse auf eine Erfolgsseite zurück. Die Transaktions-Nummer wird in der Commerce Server Rechnung hinterlegt und ist somit für die spätere Abrechnung einsehbar. Um den kompletten Zahlungsverkehr kümmert sich allerdings in der Regel der Payment-Anbieter. Durch die Nutzung eines Payment-Service liegen keine Benutzereingaben direkt im Shop vor, was rechtlichte Konsequenzen hätte.
Um die Zahlungsdaten in das entsprechende XML-Format zu bringen, ist fast immer Eigenentwicklung erforderlich. Man benötigt ein „Payment-Control“, das die Benutzereingaben in das XML-Format verpackt, dieses an den Payment-Dienst schickt und die Antwort verarbeitet.
Als Beispiel für die Anbindung eines Payment-Service möchte ich hier kurz pago vorstellen. Bei pago werden die Zahlungsdaten in XML-Form per HTTP-Request an einen lokalen „pago“- Server geschickt. Dieser wiederum kommuniziert mit dem pago Server der Pago eTransaction Services GmbH.
Das pago XML-Dokument, das der pago Server erwartet ist wie folgt aufgebaut:
<?xml version="1.0" encoding="UTF-8" ?>
<!DOCTYPE PAGOxml SYSTEM "http://xml.pago.de/2.0/PAGOxml.dtd">
<PAGOxml version="2.0" timeStamp="Wed Jun 25 12:44:15 2000">
<header>
<communicationId></communicationId>
<Client>
<ClientName></ClientName>
<SalesChannel></SalesChannel>
<Branch></Branch>
</Client>
<retry>false</retry>
<inReplyTo></inReplyTo>
</header>
<request>
<MultipayInitGuiPaymentRequest>
<Person>
<FirstName></FirstName>
<MiddleName></MiddleName>
<LastName></LastName>
<Salutation></Salutation>
<Title></Title>
<CompanyOrPerson>P</CompanyOrPerson>
<DateOfBirth></DateOfBirth>
<Gender></Gender>
<AddressAddition></AddressAddition>
</Person>
<Address>
<Street></Street>
<HouseNumber></HouseNumber>
<CountryCode></CountryCode>
<COField></COField>
<ZipCode></ZipCode>
<City></City>
<State></State>
</Address>
<ContactData>
<Phone></Phone>
<WorkPhone></WorkPhone>
<Fax></Fax>
<EMail></EMail>
</ContactData>
<InAddressOk>false</InAddressOk>
<CustomerReference></CustomerReference>
<CustomerId></CustomerId>
<Amount Currency=""></Amount>
<LanguageCode></LanguageCode>
<OrderInformationText>Reserviert</OrderInformationText>
<MallURLSet>
<MerchantURL>http://<meine Shop-URL>/merchand</MerchantURL>
<SuccessURL>http://<meine Shop-URL>/success</SuccessURL>
<FailURL>http://<meine Shop-URL>/faild</FailURL>
<ErrorURL>http://<meine Shop-URL>/error</ErrorURL>
</MallURLSet>
<PaymentMethod></PaymentMethod>
</MultipayInitGuiPaymentRequest>
</request>
</PAGOxml>
Diese Vielzahl an Zahlungsdaten kann man an den pago Payment Service schicken und erhält dann eine Antwort, die auch wiederum einem definierten XML entspricht.
Bevor man den Request abschickt, müssen die Benutzer- und Händler-Daten in das XML-Format gebracht werden. Dazu kann man das oben dargestellte pago-XML als Template laden und dann dynamisch mit Daten bestücken.
…

…
Das Absenden und Auswerten des gefüllten pago XML-Dokumentes kann dann mit Standard-.Net-Mitteln wie folgt realisiert werden.
…

…
Nach erfolgreicher Validierung der Zahlungsdaten wird der Anwender auf eine definierte Seite im Shop weitergeleitet. Diese Seite zeigt in den meisten Shop-Lösungen die Zusammenfassung der Bestellung an und beendet den Bestellprozess.
Fazit:
Für die Anbindung eines Payment-Dienstes ist es in der Regel immer erforderlich eigenen Code zu schreiben, um den individuellen Ansprüchen des Bestellprozesses gerecht zu werden. Da der Microsoft Commerce Server 2009 auf dem .Net-Framework basiert und eine API für Entwickler bereitstellt, lassen sich eigene Komponenten mit überschaubarem Aufwand erstellen und integrieren. Durch diese Flexibilität kann der Commerce Server mit jedem Payment-Dienstleister kommunizieren.
Lassen Sie sich nicht von Shop-Lösungen in Prozesse zwängen, sondern realisieren Sie Ihre!