Page tree

Search

Skip to end of metadata
Go to start of metadata


Über Kreditkartenzahlungen

Allgemeines zu Kreditkartenzahlungen

Das Computop Paygate verarbeitet alle weltweit wichtigen Kreditkarten und Währungen. Kreditkartendaten werden dabei durch TLS-Verschlüsselung vor unbefugtem Zugriff geschützt. Zusätzliche Funktionen für die Sicherheit sind integrierte Betrugsprävention und Risikomanagement. Unsere standardisierten Settlement Files gewährleisten einfache Reconcilation-Prozesse in Ihrer Buchhaltung.

Verified by Visa und MasterCard SecureCode sichern Ihren Zahlungsanspruch durch ein Passwort, falls ein Kunde die Zahlung später bestreitet. Auch American Express SafeKey nutzt diese 3D Secure-Technologie, bei der der Karteninhaber seine Identität zusätzlich per Kennwort bestätigen muss.

Die Abwicklung von Transaktionen kann per Standardformular vom Paygate, per individuell gestaltetem Formular, per Server-zu-Server-Kommunikation oder per Batch-Übertragung erfolgen. Ebenso kann das Paygate Transaktionen von stationären Terminals verarbeiten.

Die Nutzung des Kreditkartenformulars bringt folgende Vorteile:

  1. Sie können die aufwendige PCI-Sicherheitszertifizierung umgehen
  2. Die Programmierung von 3DSecure ist mit Formularen viel einfacher und schneller als per Server-zu-Server-Verbindung.


Logo336803
Info

Das Computop Paygate verarbeitet alle weltweit wichtigen Kreditkarten und Währungen. Die Abwicklung von Transaktionen kann per Standardformular vom Paygate, per individuell gestaltetem Formular, per Server-zu-Server-Kommunikation oder per Batch-Übertragung erfolgen. Ebenso kann das Paygate Transaktionen von stationären Terminals verarbeiten.

TypZahlungen per Kreditkarte

Ablauf von 3D-Secure-Zahlungen

Bei MasterCard SecureCode (UCAF), Verified by Visa (3D Secure), Diners ProtectBuy, JCB-Card J/Secure und American Express SafeKey handelt es sich um Authentisierungsmethoden, die vor der Zahlung die Identität der Karteninhaber prüfen. Der unter Technikern bekannte Name 3D Secure bezeichnet nur das Protokoll. Korrekte Markennamen sind Verified by Visa, MasterCard SecureCode, Safekey, ProtectBuy und J/Secure.

Für Händler hat die Authentisierung mit 3D Secure den Vorteil, dass die Kartengesellschaften eine Haftungsverschiebung (englisch: lia-bility shift) verfügt haben: Wenn Sie Verified by Visa, MasterCard SecureCode, Diners ProtectBuy, JCB-Card J/Secure oder American Express SafeKey einsetzen, verschiebt sich die Beweislast und somit i.d.R. auch die Haftung vom Händler zur kartenausgebenden Bank (englisch: Issuer), falls der Kunde die Zahlung bestreitet. Unabhängig davon, ob der Karteninhaber die Authentisierung tatsächlich nutzt, erhalten Sie einen sehr hohen Schutz vor Zahlungsausfällen / Chagebacks für den Fall, dass der Kunde behauptet, die Kreditkartenzahlung nicht selbst durchgeführt zu haben. Ihr Kreditkartenacquirer klärt Sie gern über die Vorteile und Bedingungen von 3D Secure auf.

Aus technischer Sicht sind die Systeme von 3D Secure keine Zahlungsmethoden, sondern eine der Zahlung vorgelagerte Authentisierung: Nach der Eingabe der Kreditkartendaten prüft das Paygate die Identität des Karteninhabers und wickelt dann erst nach der Authentisierung die Zahlung ab.

Für den weiteren Ablauf ist entscheidend, ob die Kreditkartenanbindung über die Formular-Schnittstelle oder per Server-zu-Server-Kommunikation erfolgt. Im ersten Fall des Paygate-Formulars übernimmt das Paygate den weiteren Ablauf der Authentisierung, bei der Server-zu-Server-Anbindung muss hingegen der Händler selbst for die Authentisierung über eine separate Schnittstelle sorgen.

Hinweis: Bitte beachten Sie auch unsere EMV 3D Secure Spezifikation, um gemäß neuester Standards zu integrieren.

Bitte beachten Sie, dass der Aufruf der URLSuccess oder URLFailure bei einem Fallback zu 3-D Secure 1.0 mit GET stattfindet. Ihre Systeme sollten daher Parameter sowohl per GET als auch per POST entgegennehmen können.

Ablauf einer Transaktion mit 3D Secure über Formular-Schnittstelle

Der Kunde wählt im Shop die Zahlungsmethode Kreditkarte und gibt Kartennummer und Ablaufdatum ein. Das Paygate nimmt die Kartennummer entgegen und prüft durch eine Verbindung zu Visa, MasterCard, Diners, JCB oder American Express, ob diese Kreditkarte für Verified by Visa, SecureCode, Diners ProtectBuy, JCB-Card J/Secure oder SafeKey registriert ist. Falls die Kreditkarte nicht registriert ist, wird eine Kreditkartenzahlung mit TLS ausgeführt. Dabei erhält die Transaktion eine Markierung, die Zahlungen mit 3D Secure kennzeichnet. Dadurch erfährt der Acquirer, dass Sie die Authentisierung nutzen und aufgrund des Liability Shifts einen gesicherten Zahlungsanspruch erhalten, sofern der Karteninhaber die Zahlung bestreitet.

Kommunikation für Kreditkartenzahlungen mit 3D Secure mit Paygate-Formularen


Falls die Kreditkarte des Kunden von der kartenausgebenden Bank für Verified by Visa, MasterCard SecureCode, Diners ProtectBuy, JCB-Card J/Secure oder American Express SafeKey registriert wurde, beginnt der Authentisierungsprozess: Das Paygate öffnet ein neues Browser-Fenster, dass den Kunden mit seiner Bank verbindet. In diesem Fenster gibt der Kunde nun sein Passwort ein, das er von seiner Bank erhalten hat.

Beispiel einer Passwortabfrage für 3D Secure bei Formular-Anbindung


Wenn das Passwort korrekt ist, erhält das Paygate eine Bestätigung in Form einer Signatur. Erst nach dieser Bestätigung startet das Paygate die Zahlung und sendet die Transaktion mit Signatur an den Acquirer.


Ablauf einer Transaktion mit 3D Secure über Server-zu-Server-Verbindung

Um die Authentisierung durchzuführen, verbindet das Paygate den Karteninhaber mit seiner Bank, die seine Identität bestätigt. Ein Zahlungsvorgang mit Verified by Visa oder MasterCard SecureCode, Diners ProtectBuy, JCB-Card J/Secure oder American Express SafeKey besteht also aus zwei Schritten: Authentisierung und Zahlung.

Folgendes Schema veranschaulicht die grundsätzlichen Abläufe einer Server-zu-Server-Zahlung mit 3D Secure.

Kommunikation für Kreditkartenzahlungen mit 3D Secure über Socket-Verbindungen


Für den weiteren Ablauf sind drei Fälle zu unterscheiden, bei denen sich die Antwort des Computop Paygate etwas unterscheidet. Die einzelnen Parameter der Anbindung finden Sie im Kapitel zu den Kreditkartenzahlungen.


Fall 1: Kreditkarte nicht für ein System von 3D Secure registriert

Das Computop Paygate kontaktiert zunächst den Directory Server von Visa oder MasterCard, Diners, JCB oder American Express um festzustellen, ob die Kreditkarte des Käufers für Verified oder SecureCode oder SafeKey registriert ist.

Fall 2 mit Popup: Kreditkarte ist für ein System von 3D Secure registriert

WICHTIGER HINWEIS: Wir raten dringend zur Nutzung der iFrame-Lösung, da MasterCard die Regularien geändert hat. Eine Popup-Nutzung ist von MasterCard untersagt. Hierzu ein Ausschnitt aus den Regularien (Excerpt from: MasterCard® SecureCode™ Merchant Implementation):

“Inline window implementations, which have proven to virtually eliminate the issues caused by pop-up authentication windows, are required for all new merchant implementations and existing pop-up implementations must convert to inline windows.”

Sofern die Kreditkarte für Verified oder SecureCode, ProtectBuy, J/Secure oder SafeKey registriert ist, sendet das Paygate über die Socket-Verbindung HTML-Quellcode mit einer JavaScript-Funktion zurück. Diese JavaScript-Funktion stellt die Verbindung zur Bank her, bei der sich der Käufer mit Hilfe eines Popup-Fensters mit seinem Passwort authentisiert. Der HTML-Quellcode mit der JavaScript-Funktion Initiate3DSec(), die das Computop Paygate an den Shop sendet, muss in die Antwort-Seite eingebettet werden, die der Shop im Browser des Käufers anzeigt.

Hinweis: Beachten Sie bitte, dass die Nutzung eines Popup-Fensters zu Problemen mit Popup-Blockern im Browser des Kunden führen kann. Daher wird nachfolgend in Fall 3 alternativ dazu auch eine Inframe-Variante beschrieben.

Das folgende Listing zeigt eine Antwortseite, in die der HTML-Code eingebettet wird:

<HTML>

<HEAD>

<META http-equiv=Content-Type content="text/html; charset=unicode">

       <SCRIPT language="javascript">

<!--

<Antwort vom Request: HTML mit JavaScript>

       //-->

       </script>

       </HEAD>");

       <BODY onload="javascript:Initiate3DSec();">

<table><tr>

<td align="center"><font face="Verdana" size="-1"><b>Bitte authentifizieren Sie sich bei 3D Secure!</b></font></td>

</tr></table>");

</BODY>

</HTML>


Hinweis: Sie können diesen Code auch nutzen, wenn Sie nur die Identität des Karteninhabers prüfen wollen, ohne eine Kreditkartenzahlung auszuführen. Unser Support kann Ihre Kasse so konfigurieren, dass das Paygate nur die Authentisierung mit Verified oder SecureCode, ProtectBuy, J/Secure oder SafeKey ohne Zahlung durchführt (Authentication Hosting).

Nachdem sich der Käufer bei seiner Bank authentisiert hat, ruft der Access Control Server (ACS) der Bank die TermURL im Shop auf. Bei diesem Request übergibt der ACS folgende Parameter per GET (QueryString) an die TermURL des Shops: MID, PayID und TransID. Der Parameter PARes wird per POST übergeben.

Hinweis: Der Parameter PAResponse muss URL-encoded aber nicht Blowfish-verschlüsselt sein, da der Inhalt Sonderzeichen enthalten kann.

Die Parameter müssen komplett per POST an die folgende URL übergeben werden:


Hinweis: Wenn Sie die Parameter PARes und MID des ACS weiterleiten, verwenden Sie für die Seite direct3d.aspx bitte unbedingt die ausgeschriebenen Parameternamen MerchantID, PAResponse.

Fall 3 ohne Popup: Kreditkarte ist für ein System von 3D Secure registriert

Alternativ zum Popup-Fenster kann der Karteninhaber die Authentisierung gegenüber der Bank auch in einer Inframe-Variante durchführen; dies vermeidet Schwierigkeiten mit Popup-Blockern im Browser des Kunden. Sofern die Karte am Directory Server registriert ist, sendet das Paygate über die Socket-Verbindung folgende Parameter zurück, die zur weiteren Verarbeitung der Authentisierung nötig sind.

Parameter

Format

CND

Beschreibung

ACSURL

ans..

C

Nur bei registrierten Kreditkarten: URL des Access Control Servers des Kartenausstellers mit angehängten Request-Parametern (nicht URL-codiert!) Es ist möglich, dass ACS-Server Ampersand und Fragezeichen in der URL als Value zu verwenden; alles bis zum Parameter PAReq ist Teil der ACSURL.

PaReq

ans..

M

Payer Authentication Request, der URL-encoded sein muss

MD


M

Merchant Data ist ein leerer Wert, der aus Kompatibilitätsgründen übergeben werden muss

TermURL

ans..

M

Rücksprungadresse des Shops. Das Paygate hängt an die inital gesendete TermURL die Parameter PayID, TransID und MID als Requestparameter mit einem Fragezeichen als Trennzeichen an.

Ergebnis-Parameter der Socket-Verbindung für die Authentisierungs-Anfrage


Beispiel für die korrekte Verarbeitung von ACSURL und TermURL:

acsurl=a?b=c&d=e&pareq=f&termurl=g?PayID=h&TransID=i&MID=j
ACSURL: a?b=c&d=e
TermURL: g?PayID=h&TransID=i&MID=j

Hinweis: Bitte beachten Sie, dass bei diesem Verfahren teilweise Daten direkt aus dem Bankennetzwerk übertragen werden müssen. Deshalb ist z.B. der Parameter ACSURL nicht URL-codiert, obwohl das Paygate sonst URL-codierte Daten verwendet.

Diese Parameter sind als HIDDEN-Fields in eine HTML–Seite einzubauen, die sich selbst an die ACS–URL postet. Das folgende Listing zeigt eine solche HTML-Seite, in die die Rückgabeparameter eingebettet werden:

<HTML>

<HEAD>

<META http-equiv=Content-Type content="text/html;charset=unicode">

<A content="MSHTML 6.00.2800.1106" name=GENERATOR>

</HEAD>

<BODY onload="sendpareq.submit();">

<FORM action="[ACSURL]" method="POST" name="sendpareq">

<input type="hidden" name="MD" value="">

<input type="hidden" name="PaReq" value="[PaReq]">

<input type="hidden" name="TermUrl" value="[TermUrl]">

</FORM>

</BODY>

</HTML>


Hinweis: Sie können diesen Code auch nutzen, wenn Sie nur die Identität des Karteninhabers prüfen wollen, ohne sofort eine Kreditkartenzahlung auszuführen (Authentication Hosting). Der Computop Support kann Ihre Kasse so konfigurieren, dass das Paygate Verified by Visa ohne eine Zahlung ausführt.

Nachdem sich der Käufer bei seiner Bank authentisiert hat, ruft der Access Control Server (ACS) der Bank die TermURL im Shop auf. Bei diesem Request übergibt das ACS folgende Parameter per GET (QueryString) an die TermURL des Shops: MID, PayID und TransID (unverschlüsselt). Der Parameter PARes wird per POST unverschlüsselt übergeben.

Hinweis: Der Parameter PAResponse muss URL encoded aber nicht Blowfish-verschlüsselt sein, da der Inhalt Sonderzeichen enthalten kann.

Die Parameter müssen komplett per POST an die folgende URL übergeben werden:


Hinweis: Wenn Sie die Parameter PARes und MID des ACS weiterleiten, verwenden Sie für die Seite direct3d.aspx bitte unbedingt die ausgeschriebenen Parameternamen MerchantID, PAResponse.


Kreditkartenmarken

Kreditkartenmarke, korrekte Schreibweise für CCBrand

MasterCard

VISA

AMEX

DINERS

CBN

JCB

Dankort

Maestro

Cartes Bancaires

Discover

Bancontact

Hipercard

Elo

Aura

Carte 4Etoiles

AirPlus

CUP

NARANJA

SHOPPING

CABAL

ARGENCARD

CENCOSUD

KOOKMIN

KEB

BC

SHINHAN

SAMSUNG

HYUNDAI

LOTTE

1euro

echequevacances

cofidis3xcb

cofidis4xcb

facilypay-3x

facilypay-3xsansfrais

facilypay-4x

facilypay-4xsansfrais

RuPay


Definitionen

Datenformate:

Format

Beschreibung

a

alphabetisch

as

alphabetisch mit Sonderzeichen

n

numerisch

an

alphanumerisch

ans

alphanumerisch mit Sonderzeichen

ns

numerisch mit Sonderzeichen

bool

Bool’scher Ausdruck (true oder false)

3

feste Länge mit 3 Stellen/Zeichen

..3

variable Länge mit maximal 3 Stellen/Zeichen

enum

Aufzählung erlaubter Werte

dttm

ISODateTime (JJJJ-MM-TTThh:mm:ss)


Abkürzungen:

Abkürzung

Beschreibung

CND

Bedingung (condition)

M

Pflicht (mandatory)

O

optional

C

bedingt (conditional)


Hinweis: Bitte beachten Sie, dass die Bezeichnungen der Parameter in Groß- oder Kleinbuchstaben zurückgegeben werden können.


Integration

Hier finden Sie weitere Informationen zur Integration:

Kreditkarten - Schnittstelle per Formular

Detaillierte Informationen zur Integration über Zahlungsformulare

Kreditkarten - Schnittstelle Server-zu-Server

Detaillierte Informationen zur Integration über die Server-zu-Server API

Kreditkarten - Buchung / Gutschrift / Storno / PayNow / Batch

Detaillierte Informationen zur Integration weiterer Prozesse

EMV 3-D Secure

Information and integration of EMV 3-D Secure / 3-D Secure 2.x