Einführung in Standardzahlungen von Google für Mobilfunkanbieter

In der Welt der Google-Standardzahlungen wird die Abrechnung über den Mobilfunkanbieter als tokenisiertes Zahlungsmittel betrachtet. Das bedeutet, dass Google und der Zahlungsintegrator einmalig Anmeldedaten zur Kontoidentität austauschen, um ein Token zu erstellen. Später wird dieses Token dem Zahlungsintegrator zurückgegeben, um das zu belastende Konto zu identifizieren.

Auch bei anderen Zahlungsmitteln wird die Tokenisierung genutzt. Aus diesem Grund haben wir eine allgemeine Übersicht über tokenisierte Zahlungsmittel erstellt, die für die Abrechnung über den Mobilfunkanbieter relevant ist. Die Ablaufdaten für Authentifizierung, Verknüpfung, Kauf und Remittance werden in dieser Übersicht ausführlicher beschrieben. Diese Seite enthält weitere Details im Kontext der Abrechnung über den Mobilfunkanbieter.

Mobilfunkanbieter implementieren Google Standard Payments durch die Implementierung der APIs, die die folgenden Abläufe umfassen:

Fluss Beschreibung Entsprechung der DCB3-Spezifikation
Authentifizierung Er identifiziert und authentifiziert das Konto des Nutzers im System des Zahlungsintegrators, das für Zahlungen mit direkter Abrechnung über den Mobilfunkanbieter verwendet wird. SMS-MO mit GoogleUserToken
Verknüpfungen Tausch ein langlebiges Token aus, mit dem Google und der Zahlungsintegrator sich einverstanden erklären, Zahlungen über das Zahlungsintegratorkonto des Nutzers auszuführen. Genehmigung des Nutzer-Callbacks mit OperatorUserToken und GetProvisioning()
FundsTransfer Verschiebt Geld synchron aus dem Payment Integrator-Konto des Nutzers. Überträgt die Haftung an den Zahlungsintegrator. Auth()- und CHARGE-Zeilen in Batch-Anfragedateien
Erstattung Gibt synchron einen Teil oder alle Geldmittel zurück, die mit einer früheren FundsTransfer-Funktion verknüpft waren, auf das Zahlungsintegrator-Konto des Nutzers. Überträgt die Haftung an Google, REFUND-Zeilen in Batch-Anfragedateien
Überweisung API-basierte Abrechnung, vorzugsweise täglich Monatliche Rechnung als PDF-Datei, monatliche Rechnungsdetails Datei mit Details, tägliche Berichtsdatei
UpdateAssociatedAccount Informiert Google über Änderungen am Zahlungsintegratorkonto eines Nutzers (z.B. Transaktionslimits oder Bereitstellungsstatus) GetProvisioning()-Umfrage
Betrug Informiert Google über Transaktionen, die aufgrund eines Einspruchs eines Nutzers rückgängig gemacht wurden. Sie dient der Verbesserung der Risiko-Engine von Google, wirkt sich jedoch nicht auf die Geldhaftung aus. Keine

Gesamtvergleich mit DCB3-Spezifikationen

Die Google Standard Payments-Spezifikation löst die gleichen Probleme, die mit der Spezifikation für die direkte Abrechnung über den Mobilfunkanbieter gelöst werden. Es werden jedoch andere Technologien und API-Designs verwendet, die die Lösung verbessern. Hier sind die wichtigsten Unterschiede:

Stack-Technologievergleich

Die gesamte API-Kommunikation erfolgt über HTTPS POSTs mit PGP-verschlüsseltem und signiertem JSON. Das bedeutet, dass Google und der Zahlungsintegrator jeweils nur einen PGP-Schlüssel rotieren können. Diese Technologien werden auch besser unterstützt als SOAP. Weitere Informationen zum Kommunikationspaket finden Sie hier.

Vergleich der API-Philosophie

Die direkte Abrechnung über den Mobilfunkanbieter ist für den Abgleich des Zahlungsstatus stark auf Dateien angewiesen. Google Standard Payments enthält keine Dateien. API-Aufrufe werden idempotent und unbegrenzt wiederholt, bis ein endgültiger Zustand festgestellt wurde.

Endgültige Zustände sind für einen bestimmten Idempotenzschlüssel wirklich endgültig. Fehler und unbestimmte Status werden nicht als Ablehnungen modelliert, sondern als Nicht-200-HTTP-Antworten. Auf diese Weise können wir Fehler schneller erkennen und vermeiden, sie als Ablehnung zu maskieren.

Neue Funktionen

Google Standard Payments unterstützt neue Funktionen, darunter:

  • Betrugs-API zur Information der Risiko-Engine von Google für Betrugsversuche
  • Aktualisieren Sie die Associated Account API, um Google über Nutzerverwaltung, Transaktionslimits und Änderungen des Kontostatus zu informieren.
  • Mehr Unterstützung bei der Authentifizierung bei Käufen, z. B. USSD-PINs
  • Täglicher Überweisungszyklus

DCB3 zu Google – Standardkarte für Zahlungen – Terminologie

In dieser Dokumentation und in der Spezifikation selbst finden Sie Begriffe, die neu erscheinen, aber eigentlich unterschiedliche Begriffe für bestehende Konzepte sind.

  • Mobilfunkanbieter -> Zahlungsintegrator

WARNUNG: Um Verwechslungen mit dem Konzept des DCB-Integrators zu vermeiden, versucht dieses Dokument, "Zahlungsintegrator" und "DCB-Integrator" anstelle von "Integrator" zu verwenden. In der allgemeinen Google-Dokumentation zu Standardzahlungen wird jedoch das Wort „integrator“ als Abkürzung für „Payment Integrator“ verwendet

  • ID der Abrechnungsvereinbarung -> Konto-ID des Zahlungsintegrators
  • OperatorUserToken (OUT) -> GooglePaymentToken (GPT)
  • Korrelations-ID -> Anfrage-ID
  • Umsatzbeteiligung -> Gebühr

Authentifizierungsablauf

Einen allgemeinen Überblick über den Authentifizierungsablauf für tokenisierte Zahlungsmittel finden Sie auf dieser Seite.

Einzelheiten zur Abrechnung über den Mobilfunkanbieter

Bei der Abrechnung über den Mobilfunkanbieter besteht das Ziel des Authentifizierungsvorgangs darin, nachzuweisen, dass der Nutzer die Kontrolle über die SIM-Karte hat, die mit seinem Konto bei dem Mobilfunkanbieter verknüpft ist. Nutzer, die die Abrechnung über den Mobilfunkanbieter nutzen, können mit einem der folgenden drei Mechanismen authentifiziert werden:

Zahlungsintegratoren können mit Google zusammenarbeiten, um die Authentifizierungsmechanismen auszuwählen, die am besten zu ihrem Produkt passen.

Vergleich mit der direkten Abrechnung über den Mobilfunkanbieter 3

Beim Authentifizierungsvorgang wird der approveuser-Callback an Google durch AUSSERHALB der DCB3-Spezifikation ersetzt.

Bei der direkten Abrechnung über den Mobilfunkanbieter wurden Authentifizierung und Verknüpfung zu einem einzigen Ablauf kombiniert. Bei Google Standard Payments ist die Authentifizierung und die Kontoverknüpfung getrennt.

Verknüpfungsablauf

Einen allgemeinen Überblick über den Verknüpfungsablauf für tokenisierte Zahlungsmittel finden Sie auf dieser Seite.

Der Hauptunterschied zwischen dem Verknüpfungsablauf, der für Zahlungsmittel für die Abrechnung über den Mobilfunkanbieter verwendet wird, und dem allgemeinen Ablauf für tokenisierte Zahlungsmittel besteht darin, dass der Authentifizierungsnachweis mit der associateAccount-Methode davon abhängt, ob der Zahlungsintegrator eine zusätzliche Identitätsbestätigung angefordert hat.

Wenn der Zahlungsintegrator antwortet, dass er eine zusätzliche Nutzeraufforderung wünscht, ist der Authentifizierungsnachweis der Identitätsnachweis, der von dem Authentifizierungsmechanismus vorgelegt wird, den Google für die zusätzliche Identitätsbestätigung verwendet hat. Der Authentifizierungsnachweis des OTP-Mechanismus SMS-MT ist beispielsweise die requestId einer sendOtp-Methode plus das OTP selbst.

Instrumentenattribute

Im Abschnitt zu den Zahlungsmittelattributen der allgemeinen Übersicht über tokenisierte Zahlungsmittel wird das Konzept von accountAlias, accountNickname und fullAccountNickname erläutert.

Einzelheiten zur Abrechnung über den Mobilfunkanbieter

  • accountAlias sollte die Telefonnummer des Nutzers sein. Sie wird verwendet, um das Zahlungsmittel für den Fall zu identifizieren, dass der Nutzer den Google-Support bezüglich seines Kontos anruft.
  • accountNickname und fullAccountNickname sind Anzeigenamen, mit denen das Instrument in der UI identifiziert wird.

Vergleich mit der DCB3-Spezifikation

Der Verknüpfungsablauf ersetzt die folgenden Komponenten der DCB3-Spezifikation:

  • GetProvisioning SOAP-Aufruf
  • GetSubscriberAddress SOAP-Aufruf
  • Vom Mobilfunkanbieter generiertes OUT

Ein großer Unterschied besteht darin, dass Google das Google Payment Token (GPT) während des Verknüpfungsablaufs generiert und nicht vom Mobilfunkanbieter.

Beachten Sie auch, dass im Gegensatz zu DCB3, bei dem OUTs auf eine bestimmte BillingAgreementId bezogen sind, das GPT nicht einer bestimmten PaymentIntegratorAccountID zugeordnet ist.

Ablauf des Aktualisierungstokens

Einen allgemeinen Überblick über den Vorgang für Aktualisierungstokens für tokenisierte Zahlungsmittel finden Sie auf dieser Seite.

Einzelheiten zur Abrechnung über den Mobilfunkanbieter

Bei Zahlungsmitteln für die Abrechnung über den Mobilfunkanbieter raten wir dringend davon ab, Google-Zahlungstokens zu verfallen, da diese zur Stornierung von Abobestellungen führen. Anstatt Tokens ablaufen zu lassen und die Probleme durch den Vorgang für Aktualisierungstokens zu beheben, können Sie Ihren Anwendungsfall häufig mit dem unten beschriebenen Vorgang zur Kontoaktualisierung erreichen.

Ablauf der Kontoaktualisierung

Der Kontoaktualisierungsablauf ermöglicht es dem Zahlungsintegrator, Google über Aktualisierungen des Integratorkontos des Nutzers zu informieren. Diese Felder werden Google ursprünglich während des Verknüpfungsablaufs zur Verfügung gestellt. Hier einige Beispiele für Kontodaten, die der Zahlungsintegrator aktualisieren möchte:

  • die monatlichen, täglichen und Transaktionslimits des Nutzers
  • Bereitstellungsstatus des Integratorkontos des Nutzers
  • Art des Integratorkontos des Nutzers (Prepaid, Postpaid, Enterprise usw.)
  • „accountAlias“, „accountAlias“ oder „fullAccountAlias“ des Nutzers
  • Ein Nutzer hat eine vorinstallierte statische PIN eingerichtet, entfernt oder geändert.
  • ob der Nutzer sein Konto geschlossen oder seine Telefonnummer geändert hat. Das Zahlungsmittel des Nutzers wird dadurch im Google-System entwertet.
  • Vorgang zum Löschen von Tokens

Vergleich mit der DCB3-Spezifikation

Der Ablauf zur Kontoaktualisierung ersetzt die folgenden Komponenten der DCB3-Spezifikation:

  • Abfrage eines GetProvisioning-SOAP-Aufrufs
  • Regelmäßige Entwertung von Tokens

Kaufvorgang

Einen allgemeinen Überblick über den Kaufvorgang für tokenisierte Zahlungsmittel finden Sie auf dieser Seite.

Einzelheiten zur Abrechnung über den Mobilfunkanbieter

Einige Mobilfunkanbieter verwenden die USSD oder eine andere Technologie, um bei jedem Kauf eine PIN von ihren Nutzern einzuholen. Bei diesen Mobilfunkanbietern rufen wir nicht „Capture()“ auf, sondern „asynchronousCapture()“. Der Mobilfunkanbieter benötigt dann 30 Sekunden, um den Nutzer zur Eingabe seiner PIN aufzufordern und die Erfassung abzuschließen. Sobald der endgültige Status der Zahlung ermittelt wurde, informiert der Netzbetreiber Google über das Ergebnis durch Aufrufen von „CaptureResultNotification()“.

Vergleich mit der DCB3-Spezifikation

Hier gibt es größere Änderungen.

  • Einzelner synchroner Methodenaufruf --Capture() anstelle von auth() + Batch-Datei
  • Überhaupt keine Batch-Dateien
  • Keine cancel()-Methode (Erfassung + Erstattung statt Autorisierung + Abbruch)
  • Kein Feld „user_message“ in der Antwort – Ablehnungscodes werden Google-eigenen Nachrichten zugeordnet, die in die Sprache des Nutzerkontos übersetzt sind.
  • Wichtige Terminologieänderungen:
    • CorrelationId -> requestId
    • BillingAgreementId -> paymentIntegratorAccountId
    • OperatorUserToken -> googlePaymentToken

Schwieriger Kaufvorgang

Die Entwicklung ist andauernd, um einen Kaufvorgang zu unterstützen, der vor jedem Kauf eine Authentifizierungsaufforderung für den Nutzer umfasst. Die meisten Authentifizierungsmethoden, die vor dem Zuordnungsvorgang verwendet werden können, können auch vor dem Kaufvorgang mit Identitätsbestätigung genutzt werden, um eine zusätzliche Nutzerauthentifizierung zu ermöglichen.

Erstattungsablauf

Einen allgemeinen Überblick über den Erstattungsablauf für tokenisierte Zahlungsmittel findest du auf dieser Seite.

Das tokenisierte Zahlungsmittel unterstützt den Erstattungsablauf mit einer Nachricht. Die Erstattungsmethode ermöglicht die Erstattung eines vollständigen Kaufs oder die Erstattung eines Teils eines Kaufs. Durch mehrere teilweise Erstattungen kann ein einzelner Kauf erstattet werden.

Einzelheiten zur Abrechnung über den Mobilfunkanbieter

Erstattungen sind keine besonderen Instrumente für die Abrechnung über den Mobilfunkanbieter.

Vergleich mit der DCB3-Spezifikation

Erstattungen werden durch einen synchronen API-Aufruf und nicht durch eine Datei ausgelöst. Außerdem können für eine einzige ursprüngliche Zahlung mehrere Teilerstattungen vorgenommen werden, anstatt nur eine Erstattung des vollen Werts zu unterstützen.

Überweisungsfluss

Eine allgemeine Übersicht über den Zahlungsfluss für tokenisierte Zahlungsmittel finden Sie auf dieser Seite.

Der Zahlungsvorgang bestimmt, wie Google und der Zahlungsintegrator die Abrechnung durchführen. Google ist das Abrechnungssystem für die Erfassung von Überweisungen. Google sendet regelmäßig einen Überweisungsbericht an den Zahlungsintegrator. Der Kontoauszug enthält eine Zusammenfassung des Betrags, den der Zahlungsintegrator Google schuldet, sowie Anweisungen zur Bezahlung von Google. Damit der Zahlungsintegrator den Abgleich vornehmen kann, kann der Zahlungsintegrator bei Google die Details auf Transaktionsebene abfragen, aus denen die Überweisungsübersicht besteht.

Einzelheiten zur Abrechnung über den Mobilfunkanbieter

Die Abrechnung über den Mobilfunkanbieter (remittanceStatementDetails) enthält zusätzliche Felder, die noch nicht in den API-Definitionen des Zahlungsvorgangs aufgeführt sind. Dazu gehören:

  • revshareCategory
  • itemPrice
  • tax
  • timestamp

Bei Mobilfunkanbietern, die mit Google eine Aufteilung der Umsatzbeteiligung von 50/50 abgeschlossen haben, werden die im remittanceStatementDetails aufgeführten Gebühren nach revshareCategory zusammengefasst und nicht pro Ereignis aufgeführt.

Vergleich mit der DCB3-Spezifikation

Der Zahlungsfluss ersetzt die folgenden Konzepte in der DCB3-Spezifikation:

  • Monatlicher ChargeReport/PaymentReport PDF
  • CSV-Datei mit monatlichen Rechnungsdetails
  • CSV-Dateien mit täglichen Abgleichen

Die Hauptunterschiede hier sind die Entfernung von Dateien und die Unterstützung für tägliche Überweisungen. Anstelle von Dateien wird der zu überweisende Betrag über eine synchrone API bereitgestellt. Eine andere API unterstützt das Abfragen von Details zur Überweisungsanweisung.

Betrugsmeldevorgang

Mit dem Ablauf zum Melden von Betrug kann ein Zahlungsintegrator Google durch Aufrufen der Methode fraudNotification über eine potenziell betrügerische Transaktion informieren. Dieser Ablauf wird zur Aktualisierung der internen Risiko-Engine von Google verwendet und löst keine Geldbewegungen aus.

Einzelheiten zur Abrechnung über den Mobilfunkanbieter

Bei der Benachrichtigung über die Rückbuchung einer Zahlung gibt es keine besonderen Instrumente für die Abrechnung über den Mobilfunkanbieter.