Identyfikator konta
Podczas tworzenia powiązania identyfikator konta jest wysyłany z powrotem z serwera integratora flow; Jest on potrzebny Google do identyfikacji konta użytkownika na 2 sposoby. Po pierwsze, aby zidentyfikować wiele instrumentów, które korzystają z tego samego konta użytkownika konta w celu oceny ryzyka i oszustw. Po drugie, ten model jest używany przez Google, obsługi klienta, aby zidentyfikować to konto. Wartość musi być unikalna identyfikować konto użytkownika w prośbach o powiązanie i nie można go zmienić; na danym koncie i musi być możliwe do zidentyfikowania przez użytkownika.
Jeśli na przykład integrator używa do tożsamości adresu e-mail, może to być adres e-mail. Jeśli jednak integrator używa do logowania adresu e-mail ale można go zmienić, adres e-mail nie będzie najlepszym wyborem identyfikatora konta. Cokolwiek zostanie wybrane, jego wartość musi być taka sama dla wielu próby powiązania z tą samą tożsamością użytkownika integratora płatności.
Android Application Package (APK)
Format pliku pakietu używany przez system operacyjny Android do dystrybucji i instalowanie aplikacji mobilnych.
Obsługa wersji interfejsu API
Ta specyfikacja obsługuje obsługę wersji. Obsługiwane wersje są skonfigurowane na na serwerze Google. Przy przejściu z wersji N na M (gdzie M to wersja główna większe niż N) do czasu zweryfikowania przez Google integratora musi obsługiwać zarówno N, jak i M że cały ruch został przeniesiony do M. Wersje są identyfikowane w różny sposób w zależności od kontekstu. Interfejsy API Androida oraz WebRedirect API będą przekazywać ten interfejs API. jako parametr do żądania. Wywołania serwer-serwer przekazywane jako części ścieżki adresu URL.
Wersje nie są naprawiane przez proces. Podczas migracji z N do M integrator może zobaczyć zapis w wersji M i zwrot środków w wersji N transakcji. Podczas tworzenia powiązania integrator może otrzymać żądanie uwierzytelnienia wersji M z prośbą o powiązanie wersji N.
Identyfikator powiązania
associationID określa powiązanie między kontem klienta.
i instrumentu Google. Element associationId jest bardzo podobny do GPT. W
ma taki sam czas działania jak GPT i ma moc zbioru 1:1.
Działanie associationId różni się od tagu GPT pod względem czułości. Tag GPT ma wrażliwy charakter
który jest używany do płatności. associationId to publiczny identyfikator, który
reprezentuje tę samą relację, ale nie jest
tak wrażliwy.
Płatność associationId jest przekazywana do integratora płatności podczas
associateAccount Ta sama wartość jest przekazywana podczas ponownego uwierzytelniania do
z integratorem zabezpieczeń. Dzięki temu integrator ma dostęp do informacji o tym, jakie konto musi
być uwierzytelniony. Jeśli zostanie przekazany identyfikator powiązania, to samo konto, które zostało użyte do
zidentyfikowane podczas pierwotnego powiązania musi być wstępnie wypełnione i uwierzytelnione
przeciwko Google.
Integrator płatności powinien przechowywać wszystkie identyfikatory powiązań i powiązywać z określonym kontem integratora na cały okres obowiązywania umowy między integratorem a Google.
Identyfikator żądania uwierzytelnienia
Metody refreshToken, associateAccount i (opcjonalnie) przechwytywanie
odniesienia do uwierzytelniania. Ten plik referencyjny ma postać requestId
konkretnego uwierzytelniania, do którego odnosi się Google. To pole ma
użyte przez integratora płatności w celu potwierdzenia, że faktycznie wybrana metoda została użyta przez
pomyślne uwierzytelnienie.
Metody przechwytywania mogą mieć wypełnione pole uwierzytelniania requestId. Dzieje się tak
w dwóch przypadkach. Jeśli Google uwierzytelni użytkownika tuż przed rozpoczęciem przechwytywania,
wypełni pole requestId uwierzytelniania. Poza tym Google często uwierzytelnia się
użytkownika w momencie konfiguracji harmonogramu płatności automatycznych. Google
zapisuje w tym harmonogramie funkcję uwierzytelniania requestId i wysyła
requestId wraz z każdym zapisem powiązanym z tym harmonogramem.
Integratorzy płatności powinni przechowywać całe uwierzytelnianie requestIds przez 30 dni
dni. Jeśli integrator płatności chce sprawdzić uwierzytelnianie requestIds
które mogą być uwzględnione w żądaniu przechwytywania, w tym te uwzględnione w płatności
harmonogramy, integrator musi przechowywać wszystkie requestId uwierzytelniania dla
okres obowiązywania umowy między integratorem a Google.
Firma
Firma to pojęcie zdefiniowane w konfiguracji i umowie Google. O definiuje relację między integratorem a Google. Klucze PGP (Opcjonalnie) Główne certyfikaty SSL są powiązane z firmą. Przede wszystkim Firma jest powiązana z co najmniej 1 identyfikatorem konta integratora płatności. Tagi GPT tworzone w firmie dotyczą głównie wszystkich identyfikatorów kont integratora płatności w firmie. Istnieje kilka wyjątków. Jeśli np. tag GPT to powiązane z kontem denominowanym w jednej walucie (i nie obsługują walut opłaty) i próbuje dokonać zakupu za pomocą identyfikatora konta integratora płatności w zmienić walutę.
Forma płatności
Wszystkie transakcje obejmują co najmniej jedną formę płatności, taką jak przyznanie karty lub elektronicznego transferu środków (EFT), których użytkownicy używają do dokonywania płatności na rzecz Google. za produkty lub usługi albo przez firmę Google w celu płacenia użytkownikom w przypadku użytkowników AdSense. i deweloperów Google Play. Formy płatności często nazywane są również płatnościami. Instrumenty, instrumenty i formy płatności.
Token płatności Google (GPT)
GPT to losowa, bezpiecznie zakodowana w internecie wartość zakodowana w formacie base64, generowana przez serwer Google czasu powiązania i są przekazywane do serwera integratora. Tag GPT to plik prywatny identyfikator określający połączenie konta użytkownika z integratorem i instrumentem Google. GPT to token zastępujący użytkownika dane logowania lub identyfikator konta. Ten token jest używany podczas procesów zakupu do identyfikowania konta, które zostanie obciążone lub rozliczone w ramach kredytu, i jest tajne dla obu stron. Tag GPT nie może nigdy być wysyłane w formie zwykłego tekstu i muszą być zaszyfrowane ze względu na ochronę prywatności.
Tag GPT różni się od tagu associationId, ponieważ element associationId nie jest chroniony
i są przekazywane drogą publiczną (adresy URL, niezabezpieczone połączenia). Obecny tag GPT:
znane tylko Google i integratorowi.
Oczekuje się, że integrator płatności będzie przechowywać wszystkie tagi GPTS i powiązać je z tagiem danego konta integratora w okresie obowiązywania umowy z integratorem Google i Google.
Idempotentność
Operacja idempotentna może zostać zastosowana wiele razy bez
zmiana wyniku lub pojawienie się nowych efektów ubocznych poza początkowym zastosowaniem
operacji. Zwykle idempotentność używa „klucza” do identyfikacji
użytkownika. Wszystkie żądania zdefiniowane między dwoma serwerami używają idempotentności
zdefiniowany w nagłówku żądania. Nagłówek żądania ma identyfikator żądania, który to
używany jako klucz idempotentności. Identyfikator żądania jest globalnie unikalny. Idempotentny
żądania muszą mieć dokładnie taką samą treść JSON, z jednym wyjątkiem.
requestTimestamp będzie inny w przypadku każdego żądania. To ważne,
przez Google. requestTimestamp to czas, kiedy serwer wysłał to żądanie. oraz
jest unikalna na każdą próbę. Pomaga to ograniczyć możliwość ataków typu replay.
Podobnie odpowiedź idempotentna musi mieć dokładnie taką samą treść JSON z wyjątkiem
responseTimestamp będzie inna dla każdej odpowiedzi.
Wszystkie metody między serwerami oprócz metody Echo muszą być idempotentne. Żądania uwierzytelniania wysyłane do interfejsu integratora (czy to na Androidzie, czy w przeglądarce) nie są idempotentny.
Przykłady działania idempotentnego znajdziesz w opisie dokumentu referencyjnego.
Identyfikator (ID)
Identyfikatory reprezentują transakcję lub komunikację między płatnościami z integratorem Google i Google.
Instrument
Instrument reprezentuje zapisaną formę płatności powiązaną z klientem Google. Przykłady instrumentów:
- Numer karty kredytowej w systemie
- konto bankowe; numer rozliczeniowy
Użytkownicy mogą mieć wiele instrumentów powiązanych z tożsamością Google.
Mikro
Wartości pieniężne w tym interfejsie API są przedstawiane za pomocą standardu Google o nazwie „micros”. Mikro to format oparty na liczbach całkowitych o stałej dokładności. Aby podać wartość pieniężną w mikro, pomnóż standardową wartość waluty przez 1 000 000.
Na przykład:
- 1,23 USD = 1230 000 mikroUSD
- 0,01 USD = 10 000 mikroUSD
Integrator płatności
Zewnętrzny integrator, który przetwarza płatności w ramach transakcji użytkownika.
Identyfikator konta integratora płatności
Ten identyfikator odzwierciedla ograniczenia dotyczące umowy między Google a z integratorem. Identyfikator konta integratora jest generowany przez Google i przypisywany do z integratora podczas konfiguracji. Zwykle jest to tzw. „MID”. Wszystkie żądania i odpowiedzi muszą zawierać ten identyfikator. Identyfikator jest nieprzezroczysty i musi nigdy nie zostaną przeanalizowane. Format tego identyfikatora może być niespójny wystawionych identyfikatorów.
Identyfikator nie zmienia się przez cały cykl życia transakcji. W przypadku zapisu i zwrotu środków, zastosowany został ten sam identyfikator.
Ograniczenia identyfikatora konta integratora są zdefiniowane w samej umowie. Ograniczenia dotyczą zwykle fakturowania. Na przykład integrator obsługuje CAD i MXN na fakturach w USD, ale wymaga transakcji w euro faktura w euro. W takim przypadku 2 różne identyfikatory kont integratora płatności jeden do fakturowania w USD, a drugi do fakturowania w EUR.
Identyfikator można wycofać i zastąpić nowymi. W przypadku, gdy
identyfikator jest wycofywany, Google przestanie inicjować dla niego przechwytywanie
Integrator musi jednak uwzględniać zwrot środków za dokonane transakcje
z tym identyfikatorem przez rok od ostatniego rozpoczęcia przechwytywania (rejestrowanie
inicjacja zdefiniowana jako requestTimestamp znaleziona w requestHeader).
Informacje umożliwiające identyfikację
Informacje umożliwiające identyfikację osoby to informacje, identyfikuje osobę fizyczną i wszelkie inne dane, które można w uzasadniony sposób powiązać takich jak imię i nazwisko użytkownika, jego adres e-mail, adresu lub numeru telefonu (pojedynczo lub razem)
Id żądania
requestId identyfikuje wszelką komunikację między Google a płatnością
z integratorem zabezpieczeń.
informacje poufne umożliwiające identyfikację
Poufne informacje umożliwiające identyfikację osoby to podzbiór danych informacje umożliwiające identyfikację, które stanowią duże ryzyko dla użytkownika, jeśli są przejętych lub niewłaściwie użytych. Obsługa takich informacji jest często ograniczona wymagania nałożone przez podmioty prawne, regulacyjne i zgodności z przepisami.
Token
Tokeny stanowią dodatkową warstwę zabezpieczeń, gdy dane uwierzytelniające, takie jak informacje umożliwiające identyfikację lub informacje umożliwiające identyfikację, Informacje umożliwiające identyfikację osoby są wymieniane między Google a integratorem.
Adres użytkownika
Podczas tworzenia instrumentu Google sprawdza, czy użytkownik jest Google Klient płatności. Nie zależy to od tego, czy jesteś klientem Google. Aby być klientem płatności Google, potrzebujemy adresu rozliczeniowego tego użytkownika. Niektóre organy regulacyjne wymagają od nas podania pełnego adresu użytkownika, inne wymagają części tego adresu.
Jeśli integrator płatności ma zapisany adres tego użytkownika, Google uzyskać go podczas procesu tworzenia powiązania, aby wstępnie wypełnić formularza adresowego. Użytkownik może zmienić wstępnie uzupełnione pole adresu. Wstępne wypełnienie adresu usprawnia dodawanie i zwiększa współczynnik konwersji użytkowników, którzy dodają te instrumenty.
Jeśli adres jest udostępniany, Google wykorzystuje go również jako oszacowanie ryzyka. model atrybucji. Dzięki temu program wykrywający zagrożenia Google może rozpoznać adres, który mówi użytkownik. jest rozliczany przy porównywaniu tego adresu z lokalizacją adresu IP, z którego obecnie korzysta użytkownik; godz.
Udostępnianie adresów to czysta optymalizacja. W porządku i należy się spodziewać, że niektóre integrator nie będzie miał adresu rozliczeniowego użytkownika lub nie będzie mógł go udostępnić adresu.
Kodowanie Base64 (Web-Safe)
Standard kodowania określony w sekcji 5 RFC 4648, kodowanie Base64 z adresem URL i nazwy plików Safe Alphabet. lub „base64url” kodowanie. (jest to takie samo jak kodowanie base64 z URL-em i alfabetu bezpiecznego w nazwie pliku (dokument RFC 3548, sekcja 4). Wszystkie zaszyfrowane i podpisane wartości muszą być zakodowane przy użyciu tego standardu.