Zum Hauptinhalt springen

SDK

Für die Web-Nutzung ist die Verwendung des Unico-SDK aus folgenden Gründen der empfohlene Ansatz:

  • Höhere Sicherheit;
  • Integrierte Erfahrung mit Ihrem Ablauf;
  • Höhere Konversionsrate bei Verwendung des SDK;
  • Einfachere Implementierung.
Warnung

Die Verwendung von Integrationen, die nicht den in dieser Dokumentation festgelegten Standards entsprechen, kann zu unerwarteten Störungen der Systemfunktionalität führen, die von Verifizierung ohne physische Karte nicht abgedeckt oder unterstützt werden.

Zum Beispiel: Die Implementierung von Unico per iFrame innerhalb einer Webview, die Implementierung des iFrame über ein HTML-Tag usw.

Allgemeine Richtlinien​

Um die Leistung Ihres Betriebs zu optimieren, die Konversionsraten zu verbessern und ein reibungsloseres Nutzererlebnis zu bieten, ist es verpflichtend, das Unico-SDK im Vollbildmodus in Ihrer Anwendung zu implementieren.

Erste Schritte​

Um Verifizierung ohne physische Karte über das SDK von Verifizierung ohne physische Karte zu nutzen, besteht der erste Schritt darin, die Domains zu registrieren, die als Hosts zur Anzeige der Nutzererfahrung verwendet werden.

Gefahr

Benachrichtigen Sie die für Ihr Integrationsprojekt verantwortliche Person oder das Unico-Support-Team, um diese Konfiguration vorzunehmen.

Um mit der Verwendung des SDK zu beginnen, sollten wir mit der Installation des Unico-Web-SDK starten:

npm install idpay-b2b-sdk
Tipp

Wenn Sie das Unico-SDK-Paket installieren, verzichten Sie darauf, die verwendete Version anzugeben, damit Ihr Abhängigkeitsmanager Minor- und Patch-Versionen stets auf die neueste Version aktualisiert.

Um frühere Versionen einzusehen, gehen Sie zu npmjs.com/package/idpay-b2b-sdk.

Verfügbare Methoden​

init(options)​

Diese Methode ermöglicht es, das SDK unabhängig von einer Transaktions-ID zu initialisieren, wodurch die Erfahrung des Endbenutzers reibungsloser wird. Das liegt daran, dass die Anwendung bereits über diese Methode vorgeladen wurde, wenn die Transaktions-ID und der Token verfügbar werden. Wird diese Methode nicht direkt von der Anwendung aufgerufen, erlebt der Endbenutzer beim ersten Öffnen des SDK eine lange Ladezeit.

Parameter:

  • options — erhält ein Objekt mit Konfigurationseigenschaften:
    • type — der Typ des Ablaufs, der initialisiert wird. Derzeit bieten wir den Typ IFRAME an. Für neue Anwendungen empfehlen wir die Verwendung des Typs IFRAME, der die Erfahrung des Endbenutzers erheblich reibungsloser und mit weniger Reibung gestaltet, da er vermeidet, den Checkout-Bildschirm verlassen zu müssen, und die Erfahrung vorgeladen werden kann.
import { IDPaySDK } from "idpay-b2b-sdk";

IDPaySDK.init({
  type: 'IFRAME',
  env: 'uat' // Only needed for the test environment.
});

open({ transactionId, token, onFinish? })​

Diese Methode öffnet die Erfahrung mit Verifizierung ohne physische Karte entsprechend dem zuvor in der Initialisierungsfunktion gewählten Ablauftyp. Für den REDIRECT-Ablauf führt diese Funktion eine einfache Weiterleitung zur Erfassungsroute von Verifizierung ohne physische Karte durch. Für den IFRAME-Ablauf zeigt diese Funktion das vorgeladene iframe an und startet den Nachrichtenaustausch zwischen der Seite des Kunden und der Erfahrung mit Verifizierung ohne physische Karte.

Parameter:

  • options — erhält ein Objekt mit Konfigurationseigenschaften:
    • transactionId — erhält die ID der erstellten Transaktion. Diese ID ist wichtig, um die Transaktionsdetails abzurufen und den Ablauf korrekt abzuschließen (sie kann bei der Transaktionserstellung über die API abgerufen werden).
    • token — erhält den Token für die erstellte Transaktion. Dieser Token ist wichtig, um die Transaktion zu authentifizieren und sicherzustellen, dass nur autorisierte Domains ihn verwenden (er kann bei der Transaktionserstellung über die API abgerufen werden).
    • onFinish(transaction, type) (optional) — erhält eine Callback-Funktion, die am Ende des Erfassungsablaufs von Verifizierung ohne physische Karte ausgeführt wird und zwei Argumente übergibt: das Transaktionsobjekt ({ captureConcluded, concluded, id }) und den Antworttyp — FINISH für Fälle, in denen der Ablauf erfolgreich abgeschlossen wurde, oder ERROR für Fälle, in denen der Ablauf durch einen Fehler unterbrochen wurde. Im Falle eines Fehlers im Ablauf wird der Transaktionsstatus nicht geändert, und ein Callback über Webhook, falls konfiguriert, wird nicht ausgelöst.
const transactionId = '9bc22bac-1e64-49a5-94d6-9e4f8ec9a1bf';
const token = 'eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c';

const transaction = {
  id: '9bc22bac-1e64-49a5-94d6-9e4f8ec9a1bf',
  concluded: true,
  captureConcluded: true
};

const onFinish = (transaction, type) => {
  console.log('response', transaction, type);
}

IDPaySDK.open({
  transactionId,
  token,
  onFinish
});

// You can also close the SDK explicitly using the method below
IDPaySDK.close();

Sicherheit​

Nach sorgfältiger Analyse der Anforderungen und Herausforderungen, mit denen wir konfrontiert sind, haben wir uns entschieden, eine auf iFrames mit Authentifizierungstoken basierende Lösung zu übernehmen, anstatt eine Content Security Policy (CSP) zu implementieren. Diese Entscheidung wurde durch mehrere Überlegungen im Zusammenhang mit Sicherheit und der zur Erfüllung der Anforderungen unserer Kunden erforderlichen Flexibilität geleitet.

Kontext und Herausforderungen bei CSP​

Die Content Security Policy (CSP) ist ein leistungsstarkes Werkzeug zum Schutz von Webanwendungen vor verschiedenen Arten von Angriffen, wie Cross-Site Scripting (XSS) und Code-Injection. Bei der Konfiguration einer CSP-Richtlinie ist es jedoch erforderlich, eine strikte Liste vertrauenswürdiger Domains zu definieren. Dieser Ansatz funktioniert gut, wenn Domains fest und vorhersehbar sind. Für unsere Kunden, die häufig dynamische und variable Domains verwenden, stellt diese starre Konfiguration jedoch erhebliche Herausforderungen dar.

Schwachstelle bei dynamischen Domains​

Dynamische Domains stellen bei der Verwendung von CSP ein erhebliches Sicherheitsrisiko dar. Wenn ein Kunde Domains hat, die sich häufig ändern oder dynamisch erstellt werden, wäre es notwendig, die CSP-Richtlinie ständig zu aktualisieren, um diese neuen Domains einzuschließen. Dies erhöht nicht nur den Wartungsaufwand, sondern legt auch die Domains offen, für die die CSP-Richtlinie gilt. Jede zur CSP-Richtlinie hinzugefügte Domain stellt potenziell eine Schwachstelle dar, wenn sie nicht ordnungsgemäß verwaltet wird.

Lösung mit iFrame und Auth-Token​

Um diese Risiken zu mindern und die von unseren Kunden benötigte Flexibilität zu erfüllen, haben wir uns entschieden, iFrames in Kombination mit Authentifizierungstoken zu verwenden. Diese Lösung bietet eine zusätzliche Sicherheitsebene und macht es überflüssig, eine umfangreiche und dynamische Liste von Domains offenzulegen oder zu verwalten.

So funktioniert es​

  • Sichere Authentifizierung: Jedes iFrame wird mit einem für jede Transaktion eindeutigen Authentifizierungstoken geladen, sodass sichergestellt ist, dass nur autorisierte Benutzer auf den Inhalt zugreifen können. Dieser Token wird in Echtzeit überprüft und bietet eine zusätzliche Sicherheits- und Kontrollebene.
  • Inhaltsisolierung: Die Verwendung von iFrames ermöglicht es, Inhalte in einem separaten Kontext zu isolieren, wodurch das Risiko von Interferenzen zwischen verschiedenen Ursprüngen verringert und potenzielle Angriffe gemindert werden.
  • Flexibilität für dynamische Domains: Da unsere Lösung nicht auf einer statischen CSP-Richtlinie beruht, passt sie sich problemlos an die dynamischen Domains der Kunden an, ohne dass ständige Aktualisierungen der Sicherheitsrichtlinien erforderlich sind.
Zuletzt aktualisiert am