Implementieren eines P2P-Gateways von Karte zu Karte

Für mein Projekt musste ich die Fähigkeit erkennen, von Karte zu Karte zu übertragen. Für eine offizielle Verbindung zur Schnittstelle einer Bank ist es erforderlich, eine Vereinbarung abzuschließen und eine Reihe von Bedingungen zu erfüllen. Daher wurde beschlossen, ein Tor zur öffentlichen Seite der Bank zu schaffen. Zu diesem Zweck wurden zwei Banken Tinkoff und BIN Bank ausgewählt, die die Möglichkeit bieten, ohne Provision auf „ihre“ Karten zu überweisen. Weitere Informationen zu Tarifen und Beschränkungen für Überweisungen finden Sie auf den entsprechenden Seiten der Banken. Dieser Artikel beschreibt kurz den Betrieb eines Gateways, das die Funktionalität zum Akzeptieren von Zahlungen auf eine Karte implementiert.

Es ist erforderlich, eine Übertragung von einer beliebigen Karte auf eine vorausgewählte Karte mit Unterstützung des 3DSecure-Autorisierungsverfahrens durchzuführen. 3DSecure ist ein sicheres Benutzerautorisierungsprotokoll für CNP-Vorgänge (ohne Karte). Weitere Informationen finden Sie auf speziellen Websites. Das folgende Diagramm zeigt ein vereinfachtes Diagramm, wie dies aus Sicht des Benutzers funktioniert.

Bild

Das Bild zeigt einen vereinfachten Mechanismus zum Autorisieren einer Transaktion, was „unter der Haube“ passiert, wenn Sie einen Zahlungs- oder Überweisungsvorgang von Karte zu Karte ausführen und einen SMS-Code eingeben, um dies zu bestätigen.

Betrachten wir Schritt für Schritt:

  1. Geben Sie die Kartendetails und den Betrag ein und senden Sie diese an die Website der Bank.
  2. Die Bank verwendet einen speziellen Dienst (Merchant Plug-In MPI), der eine spezielle PaReq-Anforderung generiert, bei der es sich um XML mit digitaler Signatur handelt, die Transaktionsparameter sowie Daten enthält, an die diese Anforderung gesendet werden soll (Access Control Server ACS) und wohin sie gesendet werden soll Autorisierungsantwort (PaRes).
  3. Die Bank gibt dem Benutzer eine Seite mit Informationen von MPI zurück und leitet den Browser automatisch zur ACS-Seite der Bank weiter, die die Karte des Benutzers ausgestellt hat. Dem Benutzer wird eine Seite zur Eingabe eines SMS-Codes angezeigt, und eine SMS wird an die in der ausstellenden Bank registrierte Telefonnummer gesendet.
  4. Nach Eingabe des SMS-Codes generiert der ACS-Server eine Seite mit einer Autorisierungsantwort (PaRes), die den Benutzer auf die MPI-Seite umleitet, um den Vorgang abzuschließen oder die Ausführung zu verweigern.

Um ein tieferes Verständnis des Prozesses zu erhalten, lesen Sie die entsprechenden Visa oder Mastercard-Dokumente. Diese Stufe reicht aus, um dieses Problem zu lösen.

Um einen nahtlosen Betrieb des Gateways zu gewährleisten, damit die Ohren der Website, durch die die Übersetzung nicht hervorsteht, in den Browser-Umleitungsprozess zwischen MPI und ACS integriert werden müssen. Ersetzen Sie dazu die vom MPI empfangene Adresse (TermUrl). Dies ist die Adresse, an die PaRes umgeleitet wird, nachdem der Benutzer die Autorisierung abgeschlossen hat. Als TermUrl wird die Gateway-Adresse in die Anforderung eingegeben. Auf diese Weise kann das Gateway eine Antwort (RaRes) empfangen, um sie an den MPI-Server zu senden, und den Benutzer nach der Verarbeitung der MPI-Antwort auf die Seite mit dem erfolgreichen oder erfolglosen Abschluss der Transaktion weiterleiten.

Das Gateway arbeitet zwischen dem Browser des Benutzers und der Bankseite, implementiert Eingabe- / Ausgabefunktionen, die die Bankseite emulieren, ergänzt und ändert Daten und verarbeitet Antworten und Fehler von den Bankdiensten.

Das Protokoll der Interaktion mit jeder der Banken wurde manuell durch Back-Engineering-Interaktion zwischen dem Browser und der Website der Bank geklärt. Im Allgemeinen ist die Logik dieselbe, der Unterschied zwischen Variablen und Übertragungsmethoden. Im Allgemeinen ist dies ein Engpass, und die Funktionalität der Software hängt von der Unveränderlichkeit der API ab. Sobald die Bank den Betrieb des Dienstes ändert, muss auch die Logik des Gateways geändert werden.

Lassen Sie uns die Logik der Arbeit genauer betrachten.

Um den Betrieb im Gateway sicherzustellen, wird eine Zahlungsseite implementiert, deren Aufruf an folgende Adresse erfolgt:

http://< >/pay/page?payid=123456&sum=100&text=Test 

Die URL enthält die folgenden Variablen:

payid - Transaktions-ID, die erforderlich ist, um die Ergebnisse der Zahlungsanforderung nach Abschluss der Transaktion zu identifizieren;
Summe - der Betrag der Transaktion;
Text - Informationsfeld „Zahlungszweck“.



Nach dem Ausfüllen der Kartendaten unter Zustimmung zu den Ausführungsbedingungen wird eine Provisionsanfrage für den Vorgang gestellt. Die Höhe der Provision und der Bank (eine der beiden Tinkoff und BIN), über die die Überweisung erfolgt, hängt von der in den Gateway-Einstellungen als Überweisungsempfänger angegebenen Karte und der Verfügbarkeit des Bankdienstes ab. Ein einfacher Mechanismus für das Routing und die Fehlerbehandlung ist im Gateway implementiert: Tinkoff ist immer ausgewählt. Wenn die Bankseite nicht verfügbar ist, wird die Seite BIN Bank ausgewählt.

Nach dem Klicken auf die Schaltfläche Überweisung wird das System auf die Seite der ausstellenden Bank umgeleitet, die die Karte (ACS) ausgestellt hat, von der aus der Abbuchungsvorgang ausgeführt wird. Das Gateway fordert PaReq-Parameter von MPI an, ersetzt TermUrl und sendet die Daten an den Benutzer, nachdem die Transaktionsparameter im Cache (Redis) gespeichert wurden.

Nach Abschluss der Autorisierung werden die PaRes zum Gateway geleitet und basierend auf den Cache-Daten an das entsprechende MPI weitergeleitet, die Antwort verarbeitet und der Benutzer auf eine der in den Gateway-Einstellungen angegebenen Seiten (ERROR_PAGE, SUCCESS_PAGE) umgeleitet.

Die URL zur Seite für den erfolgreichen Abschluss des Vorgangs enthält die Variable payid, die die Ergebnisse des Vorgangs in Form eines JWT mit digitaler Signatur überträgt.

JWT-Beispiel:

 eyJhbGciOiJIUzUxMiJ9.eyJqdGkiOiI2Njk2NzFlYi1mYmZlLTVlMTMtYTdkZi05NDEwZjg1N2U5ODkiLCJpYXQiOjE1NzE5MDg5MjgsInN1YiI6ImZpeGVkIiwiaXNzIjoicnUucGhvbmU0cGF5IiwicGF5X2lkIjoiMTIzNDUiLCJzdW0iOiIxMDAuMCIsInRyYW5zYWN0aW9uX2lkIjoiODY4MTE5ODYzIn0.c-IK3FowoR_tVe3-cpT7-rmA4EQhYy8rZkWrWASHZlc0ZzzpQont5XriCSzuDaY7jf7iIC8ZAxknAMwmTNmAHg 



Durch Überprüfen des Inhalts des JWT erhalten Sie zuverlässige Informationen über den Erfolg des Vorgangs. Das JWT-Token führt eine ähnliche Funktion wie PaReq aus und bietet die Möglichkeit, sich in ein externes System zu integrieren.

Diese Lösung ist ein Prototyp eines Zahlungsgateways, mit dem Sie die Internet-Erfassung (Akzeptieren von Zahlungen per Karte) auf Ihrer Website oder auf Ihrer Seite in sozialen Netzwerken implementieren können. Sie können Ihre Zahlungsseite parametrisieren oder Ihre eigene schreiben, die Software kreativ ändern. Die Hauptsache ist, den Betrag und die ID des Vorgangs auf die Eingabe zu übertragen und an der Ausgabe zu überprüfen, ob nichts von einer anderen Person kreativ geändert wurde. Quellen und Arbeitsbeispiele finden Sie auf github .

Es gibt auch ein Gateway zum Auffüllen Ihrer VK.pay-Brieftasche, das auch als Zahlungsgateway verwendet werden kann. Im Allgemeinen werden dieselben Prinzipien implementiert. Selen wurde verwendet, um einen Teil der Funktionalität zu implementieren, mit deren Hilfe die Autorisierung auf der Site und die Autorisierung für den Zugriff auf die Brieftasche implementiert werden.

WICHTIG! Alle Internet-Transaktionen sind potenziell gefährlich. Ihre Daten können gestohlen werden. Bei der Durchführung von Internet-Transaktionen müssen Sie Vorsichtsmaßnahmen treffen.

WICHTIG! Für den Diebstahl von Geldern von Bankkarten eines anderen ist eine strafrechtliche Haftung vorgesehen (Artikel 159.3, 159.6 des Strafgesetzbuchs der Russischen Föderation) .

Source: https://habr.com/ru/post/de474298/


All Articles