Zusatzdokumentation für die Integration der Billpay-Zahlartensteuerung. (Technische Dokumentation) (Version 0.3.0)

Transkript

1 Zusatzdokumentation für die Integration der Billpay-Zahlartensteuerung (Technische Dokumentation) (Version 0.3.0) 1

2 Inhaltsverzeichnis 1 Änderungshistorie Was ist die Billpay-Zahlartensteuerung? Inhalt dieses Dokuments Zielgruppe Anzeigen der Datenschutzbestimmungen Prozessdiagramm FRONTEND - Zusätzliche Requests Anfrage zur Zahlartensteuerung (prescore) REQUEST prescore RESPONSE prescore FRONTEND - Erweiterung der Standard-Requests Authorisierungsanfrage (preauthorize) REQUEST preauthorize RESPONSE preauthorize XML-Beispiele Kontakt für Rückfragen

3 1 Änderungshistorie Version Datum Bemerkungen Februar initiale Version März Korrekturen eingearbeitet März Neues Diagramm eingefügt 3

4 2 Was ist die Billpay-Zahlartensteuerung? Mit der Zahlartensteuerung von Billpay können Onlinehändler vor Anzeige der Zahlarten- Auswahlseite in ihrem Onlineshop eine Vorauswahl der Billpay-Zahlarten treffen, die für einen bestimmten Endkunden eingeblendet werden sollen. Mit dieser Vorauswahl wird ermöglicht, dass Zahlarten, für die der Kunde nicht zugelassen ist, gar nicht erst eingeblendet werden. Dadurch sinkt die Kaufabbruchquote und die Konversionsrate steigt drastisch. Der Einsatz der Zahlartensteuerung impliziert, dass die Prüfung des Endkunden auf Identität und Bonität bereits vor Auswahl der Zahlart stattfindet. Die Billpay-Zahlartensteuerung ist damit als Alternative zur Prüfung der Endkundenanfrage nach Auswahl einer Billpay-Zahlart zu sehen. Ein Händlerportal bei Billpay kann entweder mit Zahlartensteuerung oder ohne Zahlartensteuerung arbeiten, aber nicht beides zur gleichen Zeit. Hinweis: Es ist zu beachten, dass die Nutzung der entsprechenden XML-Service-Requests für die Zahlartensteuerung nur möglich ist, wenn der Händler-Account bei Billpay dafür freigeschaltet wurde. Voraussetzung für die Freischaltung ist, dass ein entsprechender Vertrag mit Billpay abgeschlossen wurde. 3 Inhalt dieses Dokuments Dieses Dokument ist eine Erweiterung des Dokuments Dokumentation der Billpay XML-API. In dem vorliegenden Dokument werden in erster Linie ein zusätzlicher XML-Service-Request sowie die sich ergebenden Änderungen der Parameter der übrigen XML-Service-Requests beschrieben. 4 Zielgruppe Diese technische Dokumentation richtet sich an Softwareentwickler und -architekten, die eine Anbindung an die XML-Zahlungsschnittstelle von Billpay realisieren wollen. Für das Verständnis aller technischen Details ist eine fundierte Kenntnis von XML und vom HTTP-Protokoll erforderlich. 5 Anzeigen der Datenschutzbestimmungen Bei Verwendung der Zahlartensteuerung von Billpay müssen die AGB- und Datenschutzbestimmungen im Vergleich zur Prüfung nach Auswahl der Zahlart nicht bestätigt werden. Stattdessen müssen die shopeigenen AGB- und Datenschutzbestimmungen des Händlers um alle rechtlich relevanten Informationen erweitert werden. Hierzu lassen wir Ihnen die nötigen Textbausteine gerne zukommen. 4

5 6 Prozessdiagramm Technischer Ablauf eines Einkaufs bei Verwendung der Billpay-Zahlartensteuerung. Ihr Onlineshop XML API Kunde geht zur Kasse Eingabe der Kundendaten Vor Anzeige der Zahlungsarten Anzeige der Billpay- Zahlarten entsprechend der prescore-response a) Rechnungs-/Lieferadresse b) sonstige Kundendaten c) Warenkorb d) Bestellhistorie a) Transaktions-ID b) Rechnung B2C erlaubt c) Rechnung B2B erlaubt d) ELV erlaubt e) Ratenkauf erlaubt f) alle verfügbaren Ratenpläne für die ZA Ratenkauf (*) XML API prescore-request Kunde wählt "Kauf auf Rechnung" Kunde wählt "Kauf per Lastschrift" Kunde wählt "Ratenkauf" Anzeige Ratenberechnungsdetails Eingabe (**): - Geburtsdatum - Anrede Eingabe (**): - Geburtsdatum - Anrede - Bankverbindung Eingabe (**): - Geburtsdatum - Anrede - Bankverbindung - Ratenzahl (**) Falls Eingabe der Daten an diesem Punkt noch nicht geschehen ist Fortsetzung auf der nächsten Seite 5

6 Ihr Onlineshop XML API Anzeige der abschließenden Übersicht Abschluß der Bestellung a) Transaktions-ID b) Rechnungs-/Lieferadresse c) sonstige Kundendaten d) Warenkorb e) Bestellhistorie f) gewählte Zahlart g) ggf. Bankverbedingung h) ggf. gewählte Ratenzahl XML API preauthorize-request (Auto-Capture) Validierung der Zahlart-spezifischen Daten (z.b. Bankverbindung) Nein Validierung OK? 1% - "Kauf auf Rechnung": Bankverbindung - "Ratenkauf": Berechnungsdetails für gew. Ratenzahl Ja 99% Bestellung wird finalisiert Wie auf dem Schaubild zu sehen ist, wird die prescore-anfrage nach Eingabe der Kundendaten und vor Anzeige der Zahlartenseite an die Billpay-Zahlungsschnittstelle gesendet. Als Antwort wird eine Liste aller erlaubten Billpay-Zahlarten zurückgegeben. Im Shop werden anschließend nur diejenigen Billpay-Zahlarten angezeigt, die für den Kunden freigegeben wurden. Ist eine bestimmte Billpay- Zahlart nicht in der prescore-response enthalten, so darf diese Zahlart diesem Endkunden nicht angeboten werden. So bald sich einige der übergebenen Daten ändern (z.b. weil der Kunde nach Ausführung der prescore-anfrage entschieden hat, seine personenbezogenen Daten oder seinen Warenkorb zu ändern), muss die prescore-anfrage mit den geänderten Daten erneut gesendet werden. Die Antwortdaten der ursprünglichen Anfrage sind damit ungültig und müssen verworfen werden. 6

7 Mit der preauthorize-anfrage wird die Bestellung im Falle der Zahlartensteuerung bei Billpay finalisiert. Im Falle der Zahlartensteuerung muss die preauthorize -Anfrage unmittelbar nach abschließender Bestätigung der Bestellung durch den Endkunden im Auto-Capture Modus (siehe Dokument Dokumentation der Billpay XML-API ) gesendet werden. 7 FRONTEND - Zusätzliche Requests In diesem Abschnitt werden die Datenformate der XML-Service-Requests und der XML-Service- Responses spezifiziert, die zusätzlich für die Zahlartensteuerung implementiert werden müssen. Zu beachten sind dabei ebenfalls die generellen Parameter für alle XML-Service-Requests und der XML- Service-Responses, die in den Abschnitten 8.4 und 8.5 des Dokuments Dokumentation der Billpay XML-API beschrieben sind. XML-Service Bedeutung Zeitpunkt des Aufrufs Service-URL Pflic ht Backoffice Rückgabe Anfrage zur Zahlartensteuerung Prüfung, welche der Billpay-Zahlarten dem Endkunden angeboten werden dürfen Im Checkout vor Anzeige der Zahlartenauswahl [Basis-Url]/ prescore Ja Nein Liste aller erlaubten Zahlarten / zahlartenspezifische Informationen Hinweis: Der moduleconfig-request (vgl. Dokumentation der Billpay XML-API ) kommt bei Verwendung der Zahlartensteuerung nicht mehr zum Einsatz. 7.1 Anfrage zur Zahlartensteuerung (prescore) Die prescore-anfrage ist vom Aufbau her der preauthorize-anfrage (vgl. Dokumentation der Billpay XML-API ) sehr ähnlich. Lediglich einige Pflichtparameter aus der preauthorize-anfrage entfallen für die prescore-anfrage: paymenttype: Die Zahlart tcaccepted: AGB- und Datenschutzbestimmungen von Billpay akzeptiert? capturerequestnecessary: Wird capture-request erwartet oder nicht? reference: Die händlerseitige Referenznummer der Bestellung Zahlartenspezifische Zusatzinformationen: Bankverbindung bei Lastschrift oder Ratenkauf, gewählte Ratenzahl und Prüfsumme beim Ratenkauf Einige andere Parameter sind im Vergleich zum preauthorize-request keine Pflichtparameter, da sie ggf. noch nicht vom Endkunden in Ihrem Shop abgefragt wurden: birthday: Das Geburtsdatum des Endkunden phone: Die Telefonnummer des Endkunden 7

8 Die prescore-antwort enthält eine Liste der erlaubten Zahlarten und einige zahlartenspezifische Zusatzinformationen. Wichtig! Die Antwort-Parameter sind nur solange gültig, solange alle Eingabeparameter des prescore-request unverändert bleiben. Sobald der Kunde seine personenbezogenen Daten oder den Warenkorb ändert, muss der prescore-request erneut gesendet werden REQUEST prescore Nicht-optionale Liste 1..n Artikel Pflicht Format Kommentar (Bestelldaten Artikel) articleid + AN 20 Eindeutige Artikel-ID/Item-ID für die Warenkorbposition Wichtig! IDs dürfen in einer Anfrage nicht mehrfach auftreten. articlequantity + N 7 Menge dieses Artikels im Warenkorb articlename + AN 50 Name des Artikels articledescription - AN 50 Beschreibung des Artikels articleprice + N 7 Nettopreis des Artikels (In kleinster Währungseinheit! Z.B. 100,00 Euro = 10000) articlepricegross + N 7 Bruttopreis des Artikels (In kleinster Währungseinheit! Z.B. 100,00 Euro = 10000) Parameter Pflicht Format Kommentar (Bestelldaten Total) shippingname + AN 50 Versandkosten-Name (z.b. Express- Versand ) shippingprice + N 7 Nettowert aller warenkorbspez. Kosten (z.b. Lieferkosten, Zuschläge,...). (In kleinster Währungseinheit! Z.B. 100,00 Euro = 10000) shippingpricegross + N 7 Bruttowert aller warenkorbspez. Kosten (z.b. Lieferkosten, Zuschläge,...). (In kleinster Währungseinheit! Z.B. 100,00 Euro = 10000) rebate + N..7 Positiver Nettowert aller Rabatte, Coupons und sonstiger betragsmindernder Posten (In kleinster Währungseinheit! Z.B. 100,00 Euro = 10000) rebategross + N..7 Positiver Bruttowert aller Rabatte, 8

9 Coupons und sonstiger betragsmindernder Posten (In kleinster Währungseinheit! Z.B. 100,00 Euro = 10000) carttotalprice + N 7 Nettowert der Bestellung (In kleinster Währungseinheit! Z.B. 100,00 Euro = 10000) carttotalpricegross + N 7 Bruttowert der Bestellung (In kleinster Währungseinheit! Z.B. 100,00 Euro = 10000) currency + Vorgabe ISO 4217 Währung der Bestellung (z.b. EUR ) Parameter Pflicht Format Kommentar (Persondendaten) customerid - AN 20 Kundennummer beim Händler (Erlaubte Zeichen: 0-9, a- customertype + Vorgabe g: Guest n: New e: Existing salutation + Vorgabe (siehe Dokumentation 9 z, A-Z,.,-,_,/) - Guest - New Customer - Existing Customer Anrede der Billpay XML-API ) title - AN 20 Titel (z.b. Dr. ) firstname + AN 50 Vorname lastname + AN 50 Nachnahme street + AN 50 Straße streetno - AN 15 Hausnummer (Falls nicht von der Straße trennbar, im Feld street mitübergeben) addressaddition - AN 50 Adresszusatz / c/o zip + AN 5 Postleitzahl city + AN 50 Ort country + Vorgabe Land (z.b. DEU ) ISO3166 alpha-3 + AN 50 phone - AN 15 Telefonnummer cellphone - AN 50 Handynummer birthday - N8 Geburtsdatum (YYYYMMDD) language + Vorgabe ISO ip + Vorgabe IPv4 Sprachkennzeichen (z.b. de ) IP-Adresse des Kunden

10 customergroup + Vorgabe p : Privatkunde (B2C) b : Geschäftskunde (B2B) Kundengruppe Wichtig! Das B2B Produkt muss separat freigeschaltet werden Parameter (Lieferdaten) usebillingaddress + Vorgabe 0: Nein 1: Ja shipping - salutation Pflicht Format Kommentar + (falls usebillingaddress = 0 ) Vorgabe (siehe Doku- mentation der Billpay XML-API ) 10 Rechnungsadresse = Lieferadresse? (Falls Ja müssen sämtliche Parameter für die Lieferdaten leer bleiben.) Wichtig! Sobald der Endkunde eine abweichende Lieferadresse eingibt MUSS diese an Billpay übergeben werden! Anrede Versandadresse shipping - title - AN 20 Titel Versandadresse (z.b. Dr. ) shipping - firstname + (falls usebillingaddress = 0 ) AN 50 Vorname Versandadresse shipping - lastname shipping - street + (falls usebillingaddress = 0 ) + (falls usebillingaddress = 0 ) AN 50 AN 50 Nachname Versandadresse Straße Versandadresse shipping - streetno - AN 15 Hausnummer Versandadresse (Falls nicht von der Straße trennbar, bitte alles im Feld shipping_street übergeben) Shipping - addressaddition - AN 50 Adresszusatz / c/o Versandadresse shipping - zip shipping - city shipping - country + (falls usebillingaddress = 0 ) + (falls usebillingaddress = 0 ) + (falls usebillingaddress = 0 ) AN 5 AN 50 Vorgabe ISO3166 alpha-3 Postleitzahl Versandadresse Ort Versandadresse Land Versandadresse (z.b. DEU )

11 shipping - phone - AN 15 Telefonnummer Versandadresse shipping - cellphone - AN 50 Handynummer Versandadresse (Firmendaten) Pflicht Format Kommentar name + (falls customergroup = b ) AN 200 Name der Firma legalform + (falls customergroup = b ) Vorgabe Rechtsform der Firma (siehe Doku- mentation der Billpay XML- API ) registernumber + (falls customergroup = b ) (siehe Dokumentation der Billpay XML-API ) AN 20 Handelsregisternummer/Firmenbuch Wichtig! Das Feld ist erst ab API-Version ein Pflichtfeld. Bitte beachten Sie, dass das Fehlen dieses Wertes die Annah- holdername + (falls customergroup = b ) (siehe Dokumentation der Billpay XML-API ) AN..100 taxnumber - gültige USt- IdNr. (DEXXXXXXXXX) mequote erheblich senkt. Name eines Inhabers der Firma Wichtig! Das Feld ist erst ab API-Version ein Pflichtfeld. Bitte beachten Sie, dass das Fehlen dieses Wertes die Annahmequote erheblich senkt. Umsatzsteueridentifikationsnummer Hinweis: Das Vorhandensein der USt-IdNr. erhöht die Trefferwahrscheinlichkeit. 11

12 Optionale Liste Bestellungen Pflicht Format Kommentar (Bestellhistorie) horderid + AN 20 Historische Bestellnummer des Händlers hdate + (YYYYMMDD hh:mm:ss) Bestelldatum hamount + N 7 Gesamtpreis (In kleinster Währungseinheit! Z.B. 100,00 Euro = 10000) hcurrency + Vorgabe Währung (z.b. EUR ) ISO 4217 hpaymenttype + Vorgabe 0: Lastschrift 1: Kreditkarte 2: Vorkasse 3: Nachnahme 4: Paypal 5: Sofortüberweisung/Giropay 6: Rechnung 7: Billpay (Rechnung) 100: Other hstatus + Vorgabe 0: Bezahlt 1: Offen 2: Mahnwesen 3: Inkasso 4: Überbezahlt 5: Unterbezahlt 6: Geplatzt Zahlungsart: - Lastschrift - Kreditkarte - Vorkasse - Nachnahme - Paypal - Sofortüberweisung/Giropay - Rechnung - Billpay (Rechnung) - Other Status der Bestellung Hinweis: Bitte senden Sie maximal die letzten 20 Bestellungen des jeweiligen Kunden RESPONSE prescore Parameter Pflicht Format Kommentar bptid + (falls mind. 1 ZA von Billpay angeboten werden darf) AN...50 BILLPAY-Transaktionsnummer. Die Transaktionsnummer muss als Eingabeparameter mit dem anschließenden preauthorize-request übergeben werden. status + Vorgabe APPROVED / DENIED Status der Identitäts- und Bonitätsprüfung 12

13 Parameter Pflicht Format Kommentar (korrigierte Addressdaten) street +(falls status = APPROVED ) AN 50 Korrigierte Straße streetno +(falls status = APPROVED ) AN 15 Korrigierte Hausnummer zip +(falls status = APPROVED ) AN 5 Korrigierte Postleitzahl city +(falls status = APPROVED ) AN 50 Korrigierter Ort country +(falls status = APPROVED ) Vorgabe ISO3166 alpha-3 Korrigiertes Land (z.b. DEU ) Optionale Liste Erlaubte Zahlarten Pflicht Format Kommentar name + AN 50 Bezeichnung der erlaubten Zahlart. Aktuell mögliche Werte: INVOICE_B2C INVOICE_B2B DIRECT_DEBIT_B2C customer_group + Vorgabe p : Privatkunde (B2C) b : Geschäftskunde (B2B) payment_type + Vorgabe 1: Rechnungskauf 2: Lastschrift 3: Ratenkauf TRANSACTION_CREDIT_B2C Kundengruppe Wichtig! Das B2B Produkt muss separat freigeschaltet werden ID der Zahlart additional_data - XML Fragment Zusätzliche, zahlartenspezifische Daten (Bsp.: Berechnungsdetails für alle möglichen Ratenpläne beim Ratenkauf. Siehe XML- Beispiele weiter unten) 13

14 8 FRONTEND - Erweiterung der Standard-Requests In diesem Abschnitt wird die Erweiterung des preauthorize-requests beschrieben, die bei Verwendung der Zahlartensteuerung von Billpay notwendig ist. 8.1 Authorisierungsanfrage (preauthorize) Mit der Authorisierungsanfrage werden im Fall der Zahlartensteuerung dieselben Daten wie bei der Prüfung der Endkundenanfrage ohne Zahlartensteuerung übergeben. Zusätzlich zum prescore- Request werden einige zahlartspezifische Daten übergeben, die im Normalfall erst nach Auswahl der jeweiligen Zahlart durch den Endkunden eingegeben werden. Zu den zahlartspezifischen Daten zählen: Die gewählte Zahlart Das Geburtsdatum Die Telefonnummer (nur Ratenkauf) Bankverbindung des Endkunden (für Zahlarten Lastschrift und Ratenkauf) Gewählte Ratenzahl und Prüfsumme (nur Ratenkauf) REQUEST preauthorize Zusätzlich zu den im Dokument Dokumentation der Billpay XML-API beschriebenen Parametern müssen mit dem preauthorize-request für die Zahlartensteuerung die folgenden Parameter übergeben werden: Parameter spezifisch für die Zahlartensteuerung Pflicht Format Kommentar is_prescored + Vorgabe 0: Nein 1: Ja Wert gibt an, ob eine vorherige prescore-anfrage abgesetzt wurde. Hinweis: Sollte für das aktuelle Portal die Zahlartensteuerung aktiviert sein, muss der Wert 1 übergeben werden. bptid + AN...50 BILLPAY-Transaktionsnummer. Die Transaktionsnummer wird mit der erfolgreichen Antwort auf eine prescore-anfrage zurückgesendet. Sie dient der Zuordnung von prescore- und preauthorize-request RESPONSE preauthorize Der Aufbau der preauthorize-response bei Verwendung der Zahlartensteuerung ist sowohl im positiven Fall (Akzeptanz der Kundenanfrage) als auch im negativen Fall (Ablehnung der Kundenanfrage) identisch mit der Response des preauthorize-response bei Einsatz ohne Zahlartensteuerung (vgl. Dokumentation der Billpay XML-API ). 14

15 9 XML-Beispiele <?xml version="1.0" encoding="utf-8"?> <data api_version="1.5.1"> <default_params mid="2" pid="3" bpsecure="0d48732f425b6df88c58244d e" /> <customer_details customerid="" customertype="g" salutation="herr" title="" firstname="billpay Demo" lastname="tester" street="saarbrücker Str. 21" streetno="" addressaddition="" zip="14098" city="berlin" country="deu" phone=" " cellphone="" birthday="" language="de" ip=" " customergroup="p" /> <shipping_details usebillingaddress="1" salutation="" title="" firstname="" lastname="" street="" streetno="" addressaddition="" zip="" city="" country="" phone="" cellphone="" /> <total shippingname="dhl" shippingprice="1000" shippingpricegross="1190" rebate="0" rebategross="0" carttotalprice="27998" carttotalpricegross="33318" currency="eur" /> <article_data> <article articleid="343" articlequantity="2" articlename="produkt XYZ" articleprice="13499" articlepricegross="16064" /> </article_data> <order_history_data> <order_history horderid=" " hdate=" :23:30" hamount="12300" hcurrency="eur" hpaymenttype="4" hstatus="0" /> </order_history_data> </data> XML-Beispiel 1: Beispiel und XML-Struktur eines prescore-requests <?xml version="1.0" encoding="utf-8"?> <data error_code="0" bptid="5ff78f4c-cdd8-440c-974f-5a7cfbf3870d" customer_message="" merchant_message="" status="approved"> <corrected_address city="berlin" country="deu" street="saarbrücker Str." streetno="21" zip="14098" /> <allowed_methods> <payment_method> <name>invoice_b2c</name> <customer_group>p</customer_group> <payment_type>1</payment_type> <additional_data /> </payment_method> <payment_method> <name>invoice_b2b</name> <customer_group>b</customer_group> <payment_type>1</payment_type> <additional_data /> </payment_method> <payment_method> <name>direct_debit_b2c</name> <customer_group>p</customer_group> <payment_type>2</payment_type> <additional_data /> </payment_method> Fortsetzung des Requests auf der nächsten Seite 15

16 <payment_method> <name>transaction_credit_b2c</name> <customer_group>p</customer_group> <payment_type>3</payment_type> <additional_data> <rate_options> <option term="6"> <calculation> <base>33318</base> <cart>32128</cart> <surcharge>1179</surcharge> <intermediate>34497</intermediate> <total>33502</total> <interest>59</interest> <anual>1414</anual> <fee>195</fee> </calculation> <dues> <due date="" type="first">4757</due> <due date="" type="following">5749</due> <due date="" type="date">5749</due> <due date="" type="date">5749</due> <due date="" type="date">5749</due> <due date="" type="date">5749</due> </dues> </option> <option term="9"> <calculation> <base>33318</base> <cart>32128</cart> <surcharge>1679</surcharge> <intermediate>34997</intermediate> <total>34002</total> <interest>56</interest> <anual>1350</anual> <fee>195</fee> </calculation> <dues> <due date="" type="first">2898</due> <due date="" type="following">3888</due> <due date="" type="date">3888</due> <due date="" type="date">3888</due> <due date="" type="date">3888</due> <due date="" type="date">3888</due> <due date="" type="date">3888</due> <due date="" type="date">3888</due> <due date="" type="date">3888</due> </dues> </option> <!--... Ein option-knoten pro erlaubte Ratenzahl... --> </rate_options> </additional_data> </payment_method> </allowed_methods> </data> XML-Beispiel 2: Beispiel für eine mögliche prescore-response für den prescore-request aus XML-Beispiel 1 (alle möglichen Zahlarten sind erlaubt) 16

17 <?xml version="1.0" encoding="utf-8"?> <data api_version="1.5.1" tcaccepted="1" capturerequestnecessary="0" paymenttype="2"> <default_params mid="2" pid="3" bpsecure="0d48732f425b6df88c58244d e" /> <preauth_params is_prescored="1" bptid="5ff78f4c-cdd8-440c-974f-5a7cfbf3870d" /> <customer_details customerid="" customertype="g" salutation="herr" title="" firstname="billpay Demo" lastname="tester" street="saarbrücker Str. 21" streetno="" addressaddition="" zip="14098" city="berlin" country="deu" phone=" " cellphone="" birthday=" " language="de" ip=" " customergroup="p" /> <shipping_details usebillingaddress="1" salutation="" title="" firstname="" lastname="" street="" streetno="" addressaddition="" zip="" city="" country="" phone="" cellphone="" /> <total shippingname="dhl" shippingprice="1000" shippingpricegross="1190" rebate="0" rebategross="0" carttotalprice="27998" carttotalpricegross="33318" currency="eur" reference="oid "/> <bank_account accountholder="max Mustermann" accountnumber=" " sortcode=" " /> <article_data> <article articleid="343" articlequantity="2" articlename="produkt XYZ" articleprice="13499" articlepricegross="16064" /> </article_data> <order_history_data> <order_history horderid=" " hdate=" :23:30" hamount="12300" hcurrency="eur" hpaymenttype="4" hstatus="0" /> </order_history_data> </data> XML-Beispiel 3: Beispiel für einen preauthorize-request im Auto-Capture Modus, der nach Auswahl der Zahlart Kauf per Lastschrift für die vorherige prescore-anfrage aus XML-Beispiel 1 gesendet wird <?xml version="1.0" encoding="utf-8" standalone="no"?> <data bptid="5ff78f4c-cdd8-440c-974f-5a7cfbf3870d" customer_message="" error_code="0" merchant_message="" status="approved"> <corrected_address city="berlin" country="deu" street="saarbrücker Str. 22" streetno="" zip="14098" /> <invoice_bank_account account_holder="" account_number="" activation_performed="" bank_code="" bank_name="" invoice_duedate="" invoice_reference="" /> </data> XML-Beispiel 4: preauthorize-response (Auto-capture, Zahlart Kauf per Lastschrift, Erfolgsfall) für den preauthorize-request in XML-Beispiel 3 und den prescore-request in XML-Beispiel 1 (Keine Änderung zur preauthorize-response ohne Zahlartensteuerung) 17

18 <?xml version="1.0" encoding="utf-8" standalone="no"?> <data bptid="353f8429-8f a4e6-d14d9d951911" customer_message="" error_code="0" merchant_message="" status="approved"> <corrected_address city="berlin" country="deu" street="saarbrücker Str. 22" streetno="" zip="14098" /> <invoice_bank_account account_holder="billpay GmbH" account_number="kto-test " activation_performed="" bank_code=" " bank_name="berliner Sparkasse" invoice_duedate="" invoice_reference="bpoid /2" /> </data> XML-Beispiel 5: preauthorize-response (Auto-Capture, Zahlart "Kauf auf Rechnung", Erfolgsfall). Der zugehörige preauthorize-request ist nicht abgebildet. (Keine Änderung zur preauthorize-response ohne Zahlartensteuerung) <?xml version="1.0" encoding="utf-8" standalone="no"?> <data customer_message="bitte wählen Sie eine andere Zahlart. Leider können wir Ihnen für diese Transaktion die ausgewählte Zahlart von Billpay nicht anbieten." error_code="42" merchant_message="fehler: Der Kunde hat offene Forderungen" status="denied" /> XML-Beispiel 6: preauthorize-response (Auto-Capture, alle Zahlarten, Fehlerfall). (Keine Änderung zur preauthorize-response ohne Zahlartensteuerung) 18

19 10 Kontakt für Rückfragen Bei technischen Fragen zur Schnittstelle wenden Sie sich bitte an: Billpay GmbH Saarbrücker Straße 21/22 D Berlin Telefon: +49 (0)