Konto-ID
Die Konto-ID wird während des Verknüpfungsvorgangs vom Server des Integrators zurückgesendet. Sie hilft Google dabei, das zugrunde liegende Konto auf zwei Arten zu identifizieren. Erstens: Mehrere Instrumente identifizieren, die dasselbe zugrunde liegende Nutzerkonto verwenden, um Risiken und Betrug zu bewerten. Diese Nummer wird auch von den Kundenservicemitarbeitern von Google verwendet, um dieses Konto zu identifizieren. Mit diesem Wert muss das Nutzerkonto in Verknüpfungsanfragen eindeutig identifiziert werden. Außerdem muss er für das jeweilige Konto unveränderlich und für den Nutzer identifizierbar sein.
Wenn ein Integrator beispielsweise eine E-Mail-Adresse zur Identität verwendet, kann dies die E-Mail-Adresse sein. Wenn der Integrator jedoch eine E-Mail-Adresse für die Anmeldung verwendet, diese aber geändert werden kann, ist die E-Mail-Adresse eine schlechte Wahl für die Konto-ID. In beiden Fällen muss der Wert für mehrere Verknüpfungsversuche mit derselben Nutzeridentität des Zahlungsintegrators gleich sein.
Android Application Package (APK)
Das Paketdateiformat, das vom Android-Betriebssystem für die Bereitstellung und Installation von mobilen Apps verwendet wird.
API-Versionen
Diese Spezifikation unterstützt die Versionsverwaltung. Unterstützte Versionen werden auf dem Google-Server konfiguriert. Beim Wechsel von Version N nach M (wobei M eine Hauptversion größer als N ist), muss der Integrator sowohl N als auch M unterstützen, bis Google überprüft, ob der gesamte Traffic zu M migriert wurde. Die Versionen werden je nach Kontext unterschiedlich identifiziert. Android APIs und Webredirect APIs übergeben die API-Version als Parameter an die Anfrage. Bei den Server-zu-Server-Aufrufen wird die Version als Teil des URL-Pfads übergeben.
Versionen werden nicht nach Ablauf korrigiert. Daher sieht ein Integrator während der Migration von N nach M möglicherweise eine Erfassung mit Version M und eine Erstattung mit Version N für dieselbe Transaktion. Während der Verknüpfung erhält der Integrator möglicherweise eine Authentifizierungsanfrage der Version M mit einer Verknüpfungsanfrage der Version N.
Verknüpfungs-ID
Die associationID identifiziert die Verknüpfung zwischen dem Konto des Kunden und dem Google-Instrument. associationId ist dem GPT sehr ähnlich. Tatsächlich hat es dieselbe Lebensdauer wie ein GPT und hat eine Kardinalität von 1:1 mit einem GPT. associationId unterscheidet sich in seiner Empfindlichkeit vom GPT. Das GPT ist ein vertrauliches Token, das für Zahlungen verwendet wird. Die associationId ist eine öffentliche Kennung, die dieselbe Beziehung repräsentiert, jedoch nicht so vertraulich ist.
Die associationId wird während associateAccount an den Zahlungsintegrator übergeben. Derselbe Wert wird während der erneuten Authentifizierung an den Integrator übergeben. Auf diese Weise kann der Integrator Kontext darüber haben, welches Konto authentifiziert werden muss. Wenn die Verknüpfungs-ID übergeben wird, muss das Konto, das während der ursprünglichen Verknüpfung identifiziert wurde, vorausgefüllt und für die Authentifizierung authentifiziert werden.
Der Zahlungsintegrator muss alle Verknüpfungs-IDs speichern und während der Laufzeit des Vertrags zwischen dem Integrator und Google einem bestimmten Integratorkonto zuordnen.
Authentifizierungsanfrage-ID
Die Methoden refreshToken, associateAccount und (optional) Capture verwenden einen Verweis auf eine Authentifizierung. Dieser Verweis hat das Format requestId der Authentifizierung, auf die sich Google bezieht. Mit diesem Feld kann der Zahlungsintegrator überprüfen, ob die Methode tatsächlich von einer erfolgreichen Authentifizierung durchgeführt wurde.
Für Erfassungsmethoden kann das Feld requestId für die Authentifizierung ausgefüllt sein. Das passiert in zwei Fällen. Wenn Google den Nutzer unmittelbar vor einer Erfassung authentifiziert, füllt Google das Feld requestId für die Authentifizierung aus. Außerdem authentifiziert Google den Nutzer häufig bei der Einrichtung, wenn ein automatischer Zahlungsablauf eingerichtet wird. Google schreibt die Authentifizierungs-requestId nach diesem Zeitplan auf und sendet die requestId zusammen mit jeder Erfassung, die diesem bestimmten Zeitplan zugeordnet ist.
Von Zahlungsintegratoren wird erwartet, dass alle Authentifizierungs-requestIds 30 Tage lang gespeichert werden. Wenn ein Zahlungsintegrator die Authentifizierungs-requestIds prüfen möchte, die bei einer Erfassungsanfrage vorhanden sein kann, einschließlich jener, die in Zahlungsablaufen enthalten sind, muss der Integrator alle Authentifizierungs-requestIds für die Lebensdauer des Vertrags zwischen dem Integrator und Google speichern.
Unternehmen
Ein Unternehmen ist ein Konzept, das in der Konfiguration und im Vertrag von Google definiert ist. Ein Unternehmen definiert die Beziehung zwischen dem Integrator und Google. Dem Unternehmen sind PGP-Schlüssel und (optional) SSL-Root-Zertifizierungsstellen zugeordnet. Am wichtigsten ist, dass ein Unternehmen mit einer oder mehreren Zahlungsintegrations-Konto-IDs verknüpft ist. In einem Unternehmen erstellte GPTs funktionieren in der Regel für alle Zahlungsintegrations-Konto-IDs innerhalb des Unternehmens. Es gelten jedoch einige Ausnahmen. Beispiel: Das GPT ist mit einem Konto verknüpft, das in einer bestimmten Währung geführt wird (und keine Devisengebühren unterstützt), und versucht, mit einer Zahlungsintegrator-Konto-ID in einer anderen Währung etwas zu kaufen.
Zahlungsmittel
Alle Transaktionen umfassen ein oder mehrere Zahlungsmittel, z. B. eine Kreditkarte oder Überweisung. Diese werden entweder von Nutzern verwendet, um Produkte oder Dienste an Google zu bezahlen, oder von Google im Fall von AdSense-Nutzern und Google Play-Entwicklern für Zahlungen an Nutzer. Zahlungsmittel werden oft auch als Zahlungsmittel, Zahlungsmittel oder Zahlungsmethoden bezeichnet.
Google Payment Token (GPT)
GPT ist ein zufälliger, websicherer base64-codierter Wert, der vom Google-Server bei der Verknüpfung generiert und an den Integratorserver weitergeleitet wird. GPT ist eine private Kennung, die die Verknüpfung zwischen dem Konto des Nutzers mit dem Integrator und dem Google-Instrument darstellt. Ein GPT ist ein Token, das die Anmeldedaten eines Nutzers oder eine Konto-ID ersetzt. Dieses Token wird während des Kaufvorgangs verwendet, um das Konto zu identifizieren, dem Guthaben gutgeschrieben oder belastet werden soll. Es ist für beide Parteien geheim. GPT darf nie im Klartext gesendet werden und muss aus Datenschutzgründen verschlüsselt werden.
GPT unterscheidet sich von associationId, weil associationId nicht geschützt und frei über öffentliche Wege (URLs, unsichere Verbindungen) weitergegeben wird. GPT ist nur Google und dem Integrator bekannt.
Der Zahlungsintegrator muss alle GPTs speichern und für die gesamte Laufzeit des Vertrags zwischen dem Integrator und Google mit einem bestimmten Integratorkonto verknüpfen.
Idempotenz
Ein idempotenter Vorgang kann mehrmals angewendet werden, ohne dass das Ergebnis geändert wird oder neue Nebenwirkungen über die anfängliche Anwendung des Vorgangs hinausgehen. In der Regel verwendet die Idempotenz einen „Schlüssel“, um dieselbe Anfrage zu identifizieren. Alle Anfragen, die zwischen den beiden Servern definiert werden, verwenden einen im Anfrageheader definierten Idempotenzschlüssel. Der Anfrageheader enthält eine Anfrage-ID, die als Idempotenzschlüssel verwendet wird. Die Anfrage-ID ist global eindeutig. Idempotente Anfragen müssen genau der gleiche JSON-Text mit einer Ausnahme sein. Der requestTimestamp ist für jede Anfrage anders. Das ist eine wichtige
Unterscheidung. requestTimestamp ist die Zeit, zu der der Server diese Anfrage gesendet hat. und ist pro Versuch eindeutig. Dies trägt dazu bei, die Möglichkeit für Replay-Angriffe zu reduzieren.
Ebenso muss eine idempotente Antwort genau der gleiche JSON-Text sein, außer dass sich responseTimestamp für jede Antwort unterscheidet.
Alle Server-zu-Server-Methoden außer der Echo-Methode müssen idempotent sein. Authentifizierungsanfragen an die UI des Integrators (Android oder Web) sind nicht idempotent.
Beispiele für idempotentes Verhalten finden Sie in der Referenzdokumentation.
Kennzeichnung (ID)
Kennungen stellen eine Transaktion oder Kommunikation zwischen dem Zahlungsintegrator und Google dar.
Zahlungsmittel
Das Zahlungsmittel repräsentiert eine gespeicherte Zahlungsmethode, die mit einem einzelnen Google-Kunden verknüpft ist. Beispiele für Instrumente:
- Eine hinterlegte Kreditkartennummer
- Bankkonto und Bankleitzahl
Nutzer können mehrere Instrumente mit ihrer Google-Identität verknüpfen.
Millionstel Einheiten
Geldwerte in dieser API werden mithilfe eines Formats dargestellt, das als „micros“ bezeichnet wird, einem Standard von Google. Mikros sind ein ganzzahliges Format mit fester Genauigkeit. Wenn Sie einen Geldwert in Mikroeinheiten darstellen möchten, multiplizieren Sie die Standardwährung mit 1.000.000.
Beispiel:
- 1,23 US-Dollar = 1230000 Mikro-USD
- 0,01 Euro = 10.000 Mikro-USD
Zahlungsintegrator
Der externe Integrator, der Zahlungen für eine Nutzertransaktion verarbeitet.
Konto-ID des Zahlungsintegrators
Diese Kennung stellt Einschränkungen in Bezug auf den Vertrag zwischen Google und dem Integrator dar. Die Integratorkonto-ID wird von Google generiert und dem Integrator während der Einrichtung zugewiesen. In der Regel wird dies als „MID“ bezeichnet. Alle Anfragen und Antworten müssen diese ID enthalten. Diese Kennung ist intransparent und darf nicht geparst werden. Das Format dieser Kennung ist möglicherweise nicht für alle ausgestellten IDs gleich.
Diese Kennung ändert sich während der Lebensdauer einer Transaktion nie. Im Fall einer Erfassung und Erstattung wird dieselbe Kennung verwendet.
Die Einschränkungen der Integrationskonto-ID werden im Vertrag selbst definiert. Im Allgemeinen bestehen die Einschränkungen bei der Rechnungsstellung. Ein Integrator unterstützt beispielsweise die Rechnungsstellung für CAD und MXN in US-Dollar, verlangt jedoch, dass Transaktionen in Euro in Euro abgerechnet werden. In diesem Fall werden zwei verschiedene Konto-IDs für die Zahlungsintegration verwendet: eine für die Rechnungsstellung in US-Dollar und eine für die Rechnungsstellung in Euro.
Die Kennung kann durch neue Kennungen ersetzt werden. Falls eine Kennung verworfen wird, initiiert Google keine Erfassungen mehr für diese Kennung. Der Integrator muss jedoch Erstattungen für Transaktionen für diese Kennung für ein Jahr ab der letzten Erfassungsinitiierung akzeptieren (die Aufnahmeinitiierung ist definiert als requestTimestamp in requestHeader).
Personenidentifizierbare Informationen
Persönlich identifizierbare Informationen (PII) sind Informationen, die eine Person identifizieren, sowie andere Daten, die von Google mit diesen Informationen in Verbindung gebracht werden können. Dazu gehören beispielsweise Name, E-Mail-Adresse, Postanschrift oder Telefonnummer eines Nutzers, entweder allein oder in Kombination.
Antragsnummer
Die requestId identifiziert die gesamte Kommunikation zwischen Google und dem Zahlungsintegrator.
vertrauliche personenbezogene Daten
Vertrauliche personenidentifizierbare Informationen sind eine Teilmenge von personenidentifizierbaren Informationen, die für den Nutzer ein hohes Risiko darstellen, wenn sie manipuliert oder missbraucht werden. Vertrauliche Informationen unterliegen häufig restriktiven Bearbeitungs- und Speicheranforderungen, die von rechtlichen, aufsichtsbehördlichen oder Compliance-Organisationen auferlegt werden.
Token
Tokens sorgen für eine zusätzliche Sicherheitsebene, wenn vertrauliche Anmeldedaten wie personenidentifizierbare Informationen zwischen Google und dem Integrator ausgetauscht werden.
Nutzeradresse
Bei der Erstellung des Zahlungsmittels prüft Google, ob der Nutzer ein Google Payments-Kunde ist. Dies ist unabhängig davon, ob Sie Google-Kunde sind. Um Google Payments-Kunde zu sein, benötigen wir die Rechnungsadresse des Nutzers. Einige Aufsichtsbehörden verlangen, dass wir die vollständige Adresse des Nutzers kennen, während andere nur einen Teil dieser Adresse benötigen.
Wenn der Zahlungsintegrator eine Adresse für diesen Nutzer hinterlegt hat, möchte Google diese Adresse während des Verknüpfungsvorgangs abrufen, um das Adressformular für den Nutzer vorab auszufüllen. Der Nutzer kann die vorausgefüllte Adresse ändern. Wenn Sie die Nutzeradresse vorab ausfüllen, wird das Hinzufügen eines Instruments einfacher und die Conversion-Rate steigt, wenn Nutzer diese Instrumente hinzufügen.
Wenn die Adresse geteilt wird, verwendet Google sie auch als Berechnung in das Risikomodell. So kann die Risiko-Engine von Google die Adresse verstehen, für die dem Nutzer Kosten in Rechnung gestellt werden, während sie mit dem IP-Standort verglichen wird, an dem sich der Nutzer derzeit befindet.
Die Adressenfreigabe ist eine reine Optimierung. Es ist in Ordnung und erwartet, dass einige Integratoren keine Rechnungsadresse für den Nutzer haben oder diese Adresse nicht teilen können.
Websichere Base64-Codierung
Der in RFC 4648, Abschnitt 5, Base 64-Codierung mit URL und Dateiname Safe Alphabet angegebene Codierungsstandard, auch als „websichere Base64-“ oder „base64url“-Codierung bezeichnet. Dies entspricht der base64-Codierung mit dem sicheren Alphabet für URL und Dateinamen aus RFC 3548, Abschnitt 4. Alle verschlüsselten und signierten Werte müssen nach diesem Standard codiert werden.