Identyfikator konta
Identyfikator konta jest wysyłany z serwera integratora podczas procesu powiązania. Pomaga on Google zidentyfikować konto na 2 sposoby. Po pierwsze, aby zidentyfikować wiele instrumentów korzystających z tego samego konta użytkownika do oceny ryzyka i oszustw. Po drugie, używane są przez pracowników obsługi klienta Google do identyfikowania tego konta. Ta wartość musi jednoznacznie identyfikować konto użytkownika w żądaniach powiązania. Musi też być stała na tym koncie i musi być rozpoznawalna dla użytkownika.
Jeśli na przykład integrator używa adresu e-mail do identyfikacji, może to być ten adres. Jeśli jednak integrator używa adresu e-mail do logowania, ale można go zmienić, adres e-mail nie jest dobrym rozwiązaniem dla identyfikatora konta. Niezależnie od wybranej opcji wartość musi być taka sama w wielu próbach powiązania z tą samą tożsamością użytkownika integratora płatności.
Pakiet aplikacji na Androida (APK)
Format pliku pakietu używany przez system operacyjny Android do dystrybucji i instalacji aplikacji mobilnych.
Obsługa wersji interfejsu API
Ta specyfikacja obsługuje obsługę wersji. Obsługiwane wersje są konfigurowane na serwerze Google. W przypadku przenoszenia z wersji N do M (gdzie M jest wersją główną większą niż N) integrator musi obsługiwać zarówno N, jak i M, dopóki Google nie potwierdzi, że cały ruch został przeniesiony do M. Wersje są identyfikowane w różny sposób zależnie od kontekstu. Interfejsy API dla interfejsów API Androida i WebRedirect będą przekazywać do wersji żądanie jako parametr. Połączenia między serwerami przekazują wersję jako część ścieżki adresu URL.
Wersje nie są naprawiane według przepływu. Dlatego podczas migracji z N do M integrator może zobaczyć przechwycony plik w wersji M i otrzymać zwrot środków za pomocą wersji N za tę samą transakcję. Podczas tworzenia powiązania integrator może otrzymać żądanie uwierzytelniania w wersji M z prośbą o powiązanie w wersji N.
Identyfikator powiązania
associationID określa powiązanie między kontem klienta a instrumentem Google. associationId jest bardzo podobny do tagu GPT. W rzeczywistości ma taki sam czas życia jak tag GPT i ma 1:1 moc zbioru do GPT. associationId różni się od tagu GPT jego czułością. GPT to wrażliwy token używany do płatności. associationId to publiczny identyfikator, który reprezentuje tę samą relację, ale nie jest aż tak wrażliwy.
associationId jest przekazywany do integratora płatności podczas associateAccount. Ta sama wartość jest przekazywana podczas ponownego uwierzytelniania do integratora. Dzięki temu integrator zyskuje kontekst dotyczący tego, które konto musi zostać uwierzytelnione. W przypadku przekazywania identyfikatora powiązania to samo konto, które zostało zidentyfikowane podczas pierwotnego powiązania, musi zostać wstępnie wypełnione i uwierzytelnione.
Integrator płatności powinien przechowywać wszystkie identyfikatory powiązań i wiązać je z konkretnym kontem przez cały okres obowiązywania umowy integratora z Google.
Identyfikator żądania uwierzytelniania
Metody refreshToken, associateAccount i (opcjonalnie) przechwytują odniesienia do uwierzytelniania. Odwołanie ma postać requestId konkretnego uwierzytelniania, do którego odwołuje się Google. Integrator płatności używa tego pola do sprawdzania, czy metoda została rzeczywiście uwierzytelniona.
Metody przechwytywania mogą być wypełnione wartością requestId. Dzieje się tak w dwóch przypadkach. Jeśli Google uwierzytelni użytkownika tuż przed przechwyceniem, Google wypełni pole uwierzytelniania requestId. Poza tym Google często uwierzytelnia użytkownika podczas konfigurowania automatycznych płatności. Google zapisuje uwierzytelnianie requestId w tym harmonogramie i wysyła requestId wraz ze wszystkimi zapisami powiązanymi z tym harmonogramem.
Integrator płatności powinien przechowywać wszystkie dane uwierzytelniające requestIds przez 30 dni. Jeśli integrator płatności chce sprawdzić uwierzytelnianie requestIds, które może być obecne w żądaniu przechwytywania, w tym w harmonogramach płatności, integrator musi przechowywać wszystkie requestId parametry uwierzytelniania przez cały okres obowiązywania umowy integratora z Google.
Firma
Firma to pojęcie zdefiniowane w konfiguracji i umowie Google. Firma definiuje relację między integratorem a Google. z firmą są powiązane klucze PGP i (opcjonalnie) główne urzędy certyfikacji SSL. Co najważniejsze, firma jest powiązana z co najmniej jednym identyfikatorem konta integratora płatności. Tagi GPT utworzone w firmie działają głównie w przypadku wszystkich identyfikatorów kont integratora płatności w jej obrębie. Obowiązują pewne wyjątki. Załóżmy np., że tag GPT jest powiązany z kontem wyrażonym w jednej walucie (i nie obsługuje opłat za kursów walutowych) i próbuje dokonać zakupu przy użyciu identyfikatora konta integratora płatności w innej walucie.
Forma płatności (FOP)
Wszystkie transakcje obejmują co najmniej jedną formę płatności, na przykład kartę kredytową lub elektroniczny transfer środków (EFT), które są wykorzystywane przez użytkowników do płacenia Google za produkty lub usługi albo płatności przez Google w przypadku użytkowników AdSense i deweloperów Google Play. Formy płatności są również nazywane instrumentami, formami płatności i formami płatności.
Token płatności Google (GPT)
GPT to losowa, zakodowana w internecie wartość zakodowana w base64, wygenerowana przez serwer Google w momencie powiązania i przekazana do serwera integratora. GPT to prywatny identyfikator łączący konto użytkownika z integratorem i instrumentem Google. GPT to token, który zastępuje dane logowania użytkownika lub jego identyfikator. Ten token jest używany podczas procesu zakupu do identyfikacji konta na karcie kredytowej lub debetowej i jest tajny dla obu stron. Aby zapewnić ochronę prywatności, tag GPT nie może być nigdy przesyłany w postaci zwykłego tekstu. Musi też być zaszyfrowany.
Tag GPT różni się od obiektu associationId, ponieważ domena associationId nie jest chroniona i może być przekazywana bezpłatnie w sposób publiczny (adresy URL, niezabezpieczone połączenia). Tag GPT jest znany tylko Google i integratorowi.
Integrator płatności powinien przechowywać wszystkie GPTS i wiązać je z konkretnym kontem integratora przez cały czas obowiązywania umowy między integratorem a Google.
Idempotentność
idempotentna operacja może zostać zastosowana wiele razy bez zmiany jej wyniku ani uzyskania nowych efektów ubocznych poza początkowym zastosowaniem. Zwykle idempotentność używa „klucza” do identyfikowania tego samego żądania. Wszystkie żądania zdefiniowane w ramach obu serwerów korzystają z klucza idempotentności zdefiniowanego w nagłówku żądania. Nagłówek żądania ma identyfikator żądania, który jest używany jako klucz idempotentności. Identyfikator żądania jest unikalny globalnie. Żądania idempotent muszą być dokładnie taką samą treścią JSON z jednym wyjątkiem. requestTimestamp będzie inny w przypadku każdego żądania. To ważne rozróżnienie. requestTimestamp to czas, w którym serwer wysłał to żądanie. i jest unikalna. Zmniejsza to możliwości ataków ponownego odtwarzania.
Wszystkie metody między serwerami z wyjątkiem Echa muszą być idempotentne. Żądania uwierzytelniania wysyłane do interfejsu integratora (w Androidzie i w internecie) nie są identyfikacji.
Przykłady zachowania idempotentnego znajdziesz w dokumentacji referencyjnej.
Identyfikator (ID)
Identyfikatory reprezentują transakcję lub komunikację między integratorem płatności a Google.
Instrument
Instrument określa zapisaną formę płatności powiązaną z jednym klientem Google. Przykłady instrumentów:
- Numer karty kredytowej zapisany w systemie
- numer konta bankowego i numer rozliczeniowy;
Użytkownicy mogą mieć wiele instrumentów powiązanych ze swoją tożsamością Google.
Mikro
Wartości pieniężne w tym interfejsie API są reprezentowane w formacie „mirosros” (standardem Google). Mikro – format liczb stałych oparty na liczbie całkowitej. Aby przedstawić wartość pieniężną w mikro, pomnóż standardową wartość waluty przez 1 000 000.
Na przykład:
- 1,23 USD = 123 0000 mikro USD
- 0,01 USD = 10 000 mikro USD
Integrator płatności
Zewnętrzny integrator przetwarzający płatności za transakcję użytkownika.
Identyfikator konta integratora płatności
Ten identyfikator określa ograniczenia dotyczące umowy między Google a integratorem. Identyfikator konta integratora jest generowany przez Google i przypisany do integratora podczas konfiguracji. Ta opcja jest zwykle określana jako „MID”. Wszystkie żądania i odpowiedzi muszą zawierać ten identyfikator. Ten identyfikator jest nieprzejrzysty i nigdy nie należy go analizować. Format tego identyfikatora może być niespójny we wszystkich wystawionych identyfikatorach.
Identyfikator ten nie zmienia się przez cały czas trwania transakcji. W przypadku przechwytywania i zwrotu kosztów jest używany ten sam identyfikator.
Ograniczenia identyfikatora konta integratora są określone w umowie. Ogólnie ograniczenia dotyczą fakturowania. Integrator obsługuje na przykład faktury CAD i MXN jako USD, ale transakcje w Europie wymagają fakturowania w EUR. W tym przypadku będą używane 2 różne identyfikatory konta integratora płatności – jeden do fakturowania w USD, a drugi do fakturowania w EUR.
Identyfikator może zostać wycofany i zastąpiony nowymi identyfikatorami. W przypadku wycofania identyfikatora Google przestanie przechwytywać ten identyfikator. Integrator musi jednak uwzględniać zwroty za transakcje dokonane z wykorzystaniem tego identyfikatora przez rok od ostatniego rozpoczęcia przechwytywania (inicjał zbierania danych określony jako requestTimestamp znaleziony w requestHeader).
Informacje umożliwiające identyfikację
Informacje umożliwiające identyfikację to informacje, które pozwalają na identyfikację osoby i innych danych, które można powiązać z użytkownikiem. Dotyczy to takich danych jak imię i nazwisko, adres e-mail, adres pocztowy czy numer telefonu użytkownika (samodzielnie lub w kombinacji).
Id żądania
requestId identyfikuje całą komunikację między Google a integratorem płatności.
informacje poufne umożliwiające identyfikację
Wrażliwe informacje umożliwiające identyfikację osób to podzbiór informacji umożliwiających identyfikację, który stwarza wysokie ryzyko dla użytkownika w przypadku, gdy zostanie przejęta lub nieodpowiednia. Tego typu informacje często podlegają restrykcyjnym wymaganiom dotyczącym obsługi i przechowywania danych, nałożonym przez podmioty prawne, regulacyjne lub zajmujące się zgodnością z przepisami.
Token
Tokeny stanowią dodatkową warstwę zabezpieczeń, gdy poufne dane logowania, takie jak informacje umożliwiające identyfikację lub informacje umożliwiające identyfikację użytkownika, są wymieniane między Google a integratorem.
Adres użytkownika
Podczas tworzenia instrumentu Google sprawdza, czy użytkownik jest klientem płatności Google. Jest to niezależne od klienta Google. Aby korzystać z Google Payments, potrzebujemy adresu rozliczeniowego użytkownika. Niektóre instytucje nadzoru wymagają od nas podania pełnego adresu użytkownika, podczas gdy inne wymagają podzbioru tego adresu.
Jeśli integrator płatności ma zarejestrowany adres tego użytkownika, Google chce go uzyskać podczas procesu powiązania, aby wstępnie wypełnić adres użytkownika. Użytkownik może zmienić wstępnie wypełniony adres. Wstępne wypełnianie adresu użytkownika upraszcza proces dodawania instrumentu i zwiększa współczynnik konwersji użytkowników korzystających z tych instrumentów.
Jeśli adres jest udostępniony, Google używa go również do obliczania jego modelu ryzyka. Dzięki temu mechanizm analizy ryzyka Google rozumie adres, pod którym użytkownik jest rozliczany, i porównuje go z lokalizacją IP użytkownika.
Udostępnianie adresów to tylko optymalizacja. Nie ma problemu. Niektórzy integratorzy nie mają adresu rozliczeniowego użytkownika lub nie mogą go udostępniać.
Bezpieczna sieć
Standard kodowania określony w sekcji 5 standardu RFC 4648, kodowanie Base 64 z adresem URL i bezpiecznym alfabetem Filename, nazywany też czasami „bezpiecznym plikiem web64” lub „base64url”. (jest to takie samo jak kodowanie base64 z bezpiecznym adresem URL i nazwą pliku z RFC 3548, sekcja 4). Wszystkie zaszyfrowane i podpisane wartości muszą być zakodowane przy użyciu tego standardu.