Wprowadzenie do standardowych płatności Google dla operatorów

W standardowych płatnościach Google Płatności przez operatora są uznawane za tokenizowaną formę płatności, co oznacza, że Google i integrator płatności przeprowadzają jednorazową wymianę danych uwierzytelniających konto w celu uzyskania tokena. Później token jest przedstawiany z powrotem integratorowi płatności, aby zidentyfikować konto, które ma zostać obciążone.

W przypadku innych form płatności także stosowana jest tokenizacja, dlatego zapoznaj się z ogólnym omówieniem tokenizowanych form płatności, które dotyczą przede wszystkim płatności przez operatora. Szczegółowe omówienie procedur uwierzytelniania, powiązania, zakupu i przelewu znajdziesz w tym omówieniu. Ta strona zawiera więcej informacji w kontekście dotyczącym płatności przez operatora.

Operatorzy rozpoczynają korzystanie ze standardowych płatności Google przez wdrożenie interfejsów API, które składają się z następujących procesów:

Płynięcie Opis Odpowiednik specyfikacji DCB3
Uwierzytelnianie Identyfikuje i uwierzytelnia konto użytkownika w systemie integratora płatności, które będzie używane do dokonywania płatności bezpośrednio u operatora SMS-MO z GoogleUserToken
Powiązanie Wymienia długoterminowy token, który może być używany przez Google i integratora płatności do dokonywania płatności za pomocą konta integratora płatności użytkownika. zatwierdzanie wywołania zwrotnego użytkownika za pomocą OperatorUserToken i GetProvisioning()
FundsTransfer Środki są synchronicznie przenoszone z konta integratora płatności użytkownika. Przenosi odpowiedzialność do integratora płatności Wiersze Auth() i OBCIĄŻENIE w plikach żądań zbiorczych
Zwrot środków Zwraca synchronicznie niektóre lub wszystkie środki powiązane z poprzednim transferem środków na konto integratora płatności użytkownika. Przenosi odpowiedzialność na Google Wiersze REFUND w plikach żądań zbiorczych
Przelew ugody oparte na interfejsach API, najlepiej codziennie, faktura miesięczna w formacie PDF, plik ze szczegółami faktury miesięcznej, plik z zestawieniem dziennym
UpdateAssociatedAccount Informuje Google o zmianach na koncie integratora płatności (np. o limitach transakcji lub stanie obsługi administracyjnej) Sonda GetProvisioning()
Oszustwo Informuje Google o transakcjach cofniętych w wyniku sporu użytkownika. Pozwala nam to ulepszać mechanizm oceny ryzyka Google, ale nie wpływa na odpowiedzialność finansową Brak

Ogólne porównanie ze specyfikacją DCB3

Specyfikacja płatności standardowych Google rozwiązuje te same problemy, które rozwiązuje specyfikacja DCB3. Wykorzystuje jednak inne technologie i projekty interfejsów API, które poprawiają działanie tego rozwiązania. Oto najważniejsze różnice:

Porównanie technologii stosu

Cała komunikacja przez interfejs API odbywa się za pomocą żądań HTTPS POST w formacie JSON szyfrowanym i podpisanym PGP. Oznacza to, że Google i integrator płatności mają tylko po jednym kluczu PGP do rotacji. Technologie te mają również lepszą obsługę niż protokół SOAP. Więcej informacji o stosie komunikacyjnym znajdziesz tutaj.

Porównanie filozofii interfejsów API

DCB3 w dużym stopniu opiera się na plikach do uzgadniania stanu płatności. Standardowe płatności Google nie mają plików. Wywołania interfejsu API są ponawiane idempotentnie i bezterminowo, aż do ustalenia ostatecznego stanu.

W przypadku danego klucza idempotentności stany końcowe są rzeczywiście ostateczne. Błędy i nieokreślone stany nie są modelowane jako odrzucenia, ale jako odpowiedzi HTTP inne niż 200. Dzięki temu możemy szybciej wychwytywać błędy i unikać maskowania ich jako odrzucenia.

Nowe funkcje

Google Standard Payments obsługuje nowe funkcje, takie jak:

  • interfejsu API oszustw, który informuje mechanizm wykrywający oszustwa
  • Zaktualizuj interfejs Associated Account API, aby informować Google o obsłudze administracyjnej, limitach transakcji i zmianach stanu konta
  • większa liczba testów zabezpieczających uwierzytelnianie podczas zakupów, np. kody PIN USSD.
  • Dzienny cykl realizacji

Przejście z DCB3 na mapę terminologii Google Standard Payments

W tej dokumentacji i w samej specyfikacji można znaleźć terminologię, która wygląda na nową, ale w rzeczywistości jest czymś innym niż używany wcześniej.

  • Operator -> Integrator płatności

OSTRZEŻENIE: aby uniknąć nieporozumień z pojęciem integratora płatności bezpośrednio u operatora, w tym dokumencie pojęto „Integrator płatności” i „integratora płatności bezpośrednio u operatora” zamiast po prostu „integratora”. Jednak w ogólnej dokumentacji płatności standardowych Google wyraz „integrator” może być używany w skrócie „integrator płatności”.

  • Identyfikator umowy rozliczeniowej -> Identyfikator konta integratora płatności
  • OperatorUserToken (OUT) -> GooglePaymentToken (GPT)
  • correlation_id -> requestId
  • Dzielenie się przychodami -> opłata

Proces uwierzytelniania

Ogólne informacje o procesie uwierzytelniania w przypadku tokenizowanych form płatności znajdziesz na tej stronie.

Szczegóły płatności przez operatora

W przypadku Płatności przez operatora celem procesu uwierzytelniania jest udowodnienie, że użytkownik ma kontrolę nad kartą SIM powiązaną z jego kontem u operatora. Użytkownicy z dostępem do płatności przez operatora mogą być uwierzytelnieni przy użyciu dowolnego z tych 3 mechanizmów:

Integrator płatności może współpracować z Google, aby wybrać mechanizmy uwierzytelniania, które najlepiej pasują do ich usług.

Porównanie z DCB3

Proces uwierzytelniania zastępuje wywołanie zwrotne approveuser do Google elementem OUT specyfikacji DCB3.

W DCB3 uwierzytelnianie i powiązanie zostały połączone w jeden proces. W usłudze płatności Google Standard uwierzytelnianie to coś innego niż powiązanie konta.

Proces powiązania

Ogólne informacje o procesie tworzenia powiązania w przypadku tokenizowanych form płatności znajdziesz na tej stronie.

Główną różnicą między procesem powiązania stosowanym w przypadku narzędzi do płatności przez operatora a ogólnym procesem tokenizowanych form płatności jest to, że dowód uwierzytelniania dostarczony w metodzie associateAccount różni się w zależności od tego, czy integrator płatności zażądał dodatkowego testu zabezpieczającego dla użytkownika.

Jeśli integrator płatności odpowiedział, że oczekuje dodatkowego testu zabezpieczającego dla użytkownika, dowód uwierzytelniania to dowód tożsamości przedstawiony przez konkretny mechanizm uwierzytelniania użyty przez Google w dodatkowym testowaniu. Na przykład dowód uwierzytelniania wygenerowany przez mechanizm obsługi haseł jednorazowych SMS-MT to identyfikator żądania metody sendOtp plus samo hasło jednorazowe.

Atrybuty instrumentu

Ogólna sekcja poświęcona atrybutom tokenizowanej formy płatności w ogólnym przeglądzie tokenizowanej formy płatności zawiera omówienie pojęcia accountAlias, accountNickname i fullAccountNickname.

Szczegóły płatności przez operatora

  • Numerem telefonu użytkownika powinien być accountAlias. Będzie ona potrzebna do identyfikacji instrumentu w sytuacji, gdy użytkownik skontaktuje się z zespołem pomocy Google w sprawie swojego konta.
  • accountNickname i fullAccountNickname to wyświetlane nazwy używane do identyfikowania instrumentu w interfejsie.

Porównanie ze specyfikacją DCB3

Proces tworzenia powiązań zastępuje te komponenty specyfikacji DCB3:

  • Wywołanie GetProvisioning SOAP
  • Wywołanie SOAP
  • Wygenerowane przez operatora OUT

Duże znaczenie ma tu fakt, że Google generuje token płatności Google (GPT) w trakcie procesu powiązania, a nie przez operatora.

Warto też pamiętać, że w odróżnieniu od DCB3, gdzie wyświetlenia są ograniczone do konkretnego identyfikatora BillingConsentmentId, tag GPT nie jest ograniczony do żadnego konkretnego identyfikatora PaymentIntegratorAccountID.

Odśwież przepływ tokenów

Ogólne informacje o przepływie tokenów odświeżania w przypadku tokenizowanych form płatności znajdziesz na tej stronie.

Szczegóły płatności przez operatora

W przypadku instrumentów płatniczych u operatora zdecydowanie odradzamy wygaśnięcie tokenów płatności Google, ponieważ powoduje to anulowanie zamówień subskrypcji. Zamiast tracić ważność tokenów i polegać na procesie tokenów odświeżania w celu rozwiązania problemów, często można zrealizować ten przypadek, korzystając z opisanego poniżej procesu aktualizacji konta.

Proces aktualizacji konta

Proces aktualizacji konta pozwala integratorowi płatności informować Google o zmianach na koncie integratora użytkownika. Te pola są oryginalnie dostarczane do Google w ramach procesu tworzenia powiązań. Oto kilka przykładów danych konta, które może zaktualizować integrator płatności:

  • Miesięczne, dzienne i dzienne limity transakcji użytkownika oraz dotyczące poszczególnych produktów
  • stan obsługi administracyjnej konta integratora użytkownika
  • rodzaj konta integratora użytkownika (przedpłacone, abonamenty, firmowe itp.);
  • „AliasKonta”, „Pseudonim konta” lub „fullAccountNickname” użytkownika
  • informacje o tym, czy użytkownik skonfigurował, usunął lub zmienił wstępnie udostępniony statyczny kod PIN;
  • czy użytkownik zamknął swoje konto lub zmienił numer telefonu, co spowoduje unieważnienie instrumentu użytkownika w systemie Google.
  • usuń przepływ tokena

Porównanie ze specyfikacją DCB3

Proces aktualizacji konta zastępuje te komponenty specyfikacji płatności bezpośrednio u operatora:

  • Odpytywanie wywołania GetProvisioning SOAP
  • Okresowa unieważnienie tokena

Proces zakupu

Ogólne informacje o procesie zakupu w przypadku tokenizowanych form płatności znajdziesz na tej stronie.

Szczegóły płatności przez operatora

Niektórzy operatorzy używają USSD lub innej technologii do pobierania kodu PIN od użytkowników podczas każdego zakupu. W przypadku tych operatorów, zamiast wywoływać metodę Capture(), wywołujemy asynchronicznieCapture() i dajemy operatorowi 30 sekund na poproszenie użytkownika o podanie kodu PIN i zakończenie przechwycenia. Po ustaleniu ostatecznego stanu płatności operator informuje Google o wyniku, wywołując metodęcaptureResultnotifications().

Porównanie ze specyfikacją DCB3

Zaszły tutaj duże zmiany.

  • Pojedyncze wywołanie metody synchronicznej – Cap() zamiast auth() + plik wsadowy
  • Brak plików wsadowych
  • Brak metody cancel() (rejestracja + zwrot środków zamiast uwierzytelniania + anulowanie)
  • Brak pola user_message w odpowiedzi – kody odrzucenia są zmapowane na wiadomości należące do Google zlokalizowane na język konta użytkownika.
  • Najważniejsze zmiany w terminologii:
    • CorrelationId -> requestId
    • BillingConsentmentId -> paymentIntegratorAccountId
    • OperatorUserToken -> googlePaymentToken

Proces zakupu, którego dotyczy problem

Stale pracujemy nad obsługą procesu zakupu, który obejmuje test uwierzytelniania użytkownika przed każdym zakupem. Z większości metod uwierzytelniania, które można zastosować przed procesem tworzenia powiązania, można też korzystać przed procesem trudnego zakupu, aby zapewnić dodatkowe uwierzytelnianie użytkownika.

Proces zwrotu środków

Ogólne informacje o procesie zwrotu środków w przypadku tokenizowanych form płatności znajdziesz na tej stronie.

tokenizowana forma płatności obsługuje proces zwrotu środków z 1 wiadomością, Metoda zwrotu środków umożliwia zwrot środków za pełny zakup lub zwrot części zakupu. Wiele częściowych zwrotów środków może spowodować zwrot środków za jeden zakup.

Szczegóły płatności przez operatora

W procesie zwrotu środków nie ma nic specjalnego na instrumentach płatności u operatora.

Porównanie ze specyfikacją DCB3

Zwroty środków są wyzwalane przez synchroniczne wywołanie interfejsu API zamiast przez plik. Oprócz tego dla 1 oryginalnej płatności można utworzyć kilka częściowych zwrotów środków, zamiast obsługiwać tylko 1 zwrot środków o pełnej wartości.

Proces realizacji przelewu

Ogólne informacje o procesie płatności w przypadku tokenizowanych form płatności znajdziesz na tej stronie.

Proces płatności określa, w jaki sposób Google i integrator płatności przeprowadzają rozliczenie. Google jest systemem księgowości, który zajmuje się przesyłaniem płatności. Google regularnie wysyła wyciąg do integratora płatności. Zawiera ono podsumowanie kwoty, jaką integrator płatności jest winny Google, oraz instrukcje, jak płacić Google. Aby integrator płatności mógł uzgodnić dane, może wysłać do Google zapytanie o szczegóły na poziomie transakcji, z których składa się przelew.

Szczegóły płatności przez operatora

remittanceStatementDetails Płatności przez operatora obejmują dodatkowe pola, które nie znajdują się jeszcze w definicjach interfejsu API procesu płatności. m.in.:

  • revshareCategory
  • itemPrice
  • tax
  • sygnatura czasowa

W przypadku przewoźników, którzy podpisali z Google umowę o podziale przychodów w wysokości 50/50, opłaty podane w remittanceStatementDetails są obliczane zbiorczo dla danych revshareCategory, a nie dla poszczególnych zdarzeń.

Porównanie ze specyfikacją DCB3

Proces płatności zastępuje te pojęcia w specyfikacji płatności bezpośrednio u operatora:

  • Miesięczny raport obciążenia/płatności w formacie PDF
  • Plik CSV ze szczegółami faktury miesięcznej
  • Pliki CSV z potwierdzeniem dziennym

Główne różnice między tymi usługami polegają na usuwaniu plików i obsłudze codziennych przelewów. Kwota do przesłania jest dostarczana za pomocą interfejsu API synchronicznego, a inny interfejs API obsługuje zapytania o szczegóły rachunku.

Proces zgłaszania oszustw

Proces zgłaszania oszustw pozwala integratorowi płatności poinformować Google o potencjalnie fałszywej transakcji przez wywołanie metody fraudNotification. Ten proces służy do aktualizowania wewnętrznego mechanizmu wykrywania ryzyka Google i nie inicjuje żadnych przepływów pieniężnych.

Szczegóły płatności przez operatora

W procesie powiadomień o cofnięciu płatności nie ma nic specjalnego na instrumentach płatności przez operatora.