Żądanie kart przez terminal

Terminal sprzedawcy może zażądać konkretnej karty na kilka sposobów.

Komunikacja między terminalem a aplikacją Google Pay

Identyfikatorem terminala jest identyfikator sprzedawcy. Jest on zmapowany na identyfikator wydawcy elementów promocyjnych w backendzie Google, którego programiści kart używają przez Google Pay API for Passes.

Kiedy jest używana funkcja smart tap, terminal wysyła swój identyfikator sprzedawcy do aplikacji Google Pay. Aplikacja sprawdza wydawców elementów promocyjnych każdej karty, pobiera identyfikator sprzedawcy i, jeśli identyfikator jest zgodny, przesyła odpowiednie karty do terminala.

Aby to zrobić, zobacz Konfigurowanie terminala sprzedawcy.

Proces ten wygląda tak:

Konfiguracja 1

Konfiguracja 1. Na diagramie powyżej Issuer_id: 2018 ma jedną klasę i jeden obiekt. To konto wydawcy jest używane przez programistę karty. Klasa Class_id: abc ma obiekt redemptionIssuers['1990']. Zgodnie z definicją Issuer_id: '1990' jest identyfikatorem wydawcy elementów promocyjnych, który odpowiada sprzedawcy fooPizza. Terminal ma identyfikator sprzedawcy 12345678. Jest on mapowany na identyfikator sprzedawcy skonfigurowany na koncie wydawcy elementów promocyjnych 1990. Każdy obiekt klasy Class_id: abc jest przekazywany do czytnika z identyfikatorem sprzedawcy 12345678.

Konfiguracja 1.1

Konfiguracja 1.1. W przykładzie powyżej fooPizza i yumPie mogą wykorzystać tę samą kartę object_id: 123. Klasa może mieć wielu wydawców elementów promocyjnych. Konta wydawców elementów promocyjnych odpowiadające wydawcom mają w swoich terminalach unikalne identyfikatory sprzedawców.

Konfiguracja 2

Konfiguracja 2. Diagram powyżej przedstawia, jak klasa może ustawić swoje konto wydawcy jako wydawcę elementów promocyjnych. Issuer_id: 2018 ma jedną klasę i jeden obiekt. Klasa Class_id: abc ma obiekt wydawcy elementów promocyjnych Issuer_id: 2018. Zgodnie z definicją Issuer_id: 2018 jest identyfikatorem wydawcy elementów promocyjnych, który odpowiada sprzedawcy fooPizza. Terminal ma identyfikator sprzedawcy 12345678. Jest on mapowany na identyfikator sprzedawcy, który zawiera klasę Class_id: abc i jest skonfigurowany jako obiekt Issuer_id: 2018. Obiekt klasy Class_id: abc jest przekazywany do terminala z identyfikatorem sprzedawcy 12345678.

Wybór użytkownika w aplikacji Google Pay

Zachowanie elementów przesyłanych do aplikacji Google Pay zależy od tego, co użytkownik widzi na swoim urządzeniu.

Jeśli użytkownik wyświetli kartę w Google Pay i użyje smart tap, karta zostanie przesłana, gdy identyfikator sprzedawcy będzie zgodny z terminalem, który wysyła żądanie. Dzieje się tak niezależnie od tego, czy identyfikator jest prawidłowy, co jest określane na podstawie właściwości klasy lub obiektu.

Użytkownik może nie widzieć karty, na przykład wtedy, gdy jest na karcie głównej Google Pay lub gdy wyświetla kartę na odblokowanym ekranie urządzenia. Jeśli użytkownik nie widzi karty i na podstawie identyfikatora sprzedawcy ma tylko jedną prawidłową kartę do wykorzystania, karta zostanie przekazana.

Jeśli użytkownik ma wiele prawidłowych kart do wykorzystania na podstawie identyfikatora sprzedawcy, Google Pay wykona jedną z tych operacji:

  • Wyświetli karuzelę z opcjami wyboru dla użytkownika, które wystarczy dotknąć, aby przekazać kartę.
  • Przekaże kartę, jeśli jest obecna tylko jedna prawidłowa karta.

Ważność karty zależy od jej kategorii. Sprawdź właściwości powiązane ze stanem i datą użycia, takie jak object.state lub object.validTimeInterval.

Przykład pobierania przez smart tap

Poniżej znajdziesz przykładową konfigurację fikcyjnych wydawców i ich programów lojalnościowych:

iLuvCoffeeEat-fooBacon-R-us
Identyfikator wydawcy123456789
Identyfikator sprzedawcy1114444444477777777
Klasa lojalnościowaR-podstawowyMoje nagrody- Brak -
Klasa lojalnościowaR-złoty- Brak -- Brak -

iLuvCoffee ma dwie klasy lojalnościowe służące do tworzenia kart: program R-podstawowy i program R-złoty. Natomiast Eat-foo ma własny program Moje nagrody, a Bacon-R-us nie oferuje żadnych programów lojalnościowych.

Załóżmy, że chcesz użyć takiej konfiguracji:

  • Program R-podstawowy można wykorzystać w Eat-foo i Bacon-R-us.
  • Program Moje nagrody można wykorzystać w Eat-foo.
  • Program R-złoty nie obsługuje smart tap.

W tej konfiguracji klasy lojalnościowe są ustawiane za pomocą poniższych identyfikatorów wydawców elementów promocyjnych:

  • R-podstawowy: 456, 789.
  • Moje nagrody: 456.
  • R-złoty: - brak -.

W tej konfiguracji instancje klas mają ustawione poniższe identyfikatory sprzedawców:

  • R-podstawowy: 44444444, 77777777.
  • Moje nagrody: 44444444.
  • R-złoty: - brak -.

Uwierzytelnianie sprzedawcy w czasie użycia smart tap

Z kontem wydawcy można powiązać dowolną liczbę publicznych kluczy bezpieczeństwa. Są one synchronizowane i przechowywane w aplikacji Google Pay, dzięki czemu są gotowe do użycia, gdy użytkownik zbliży telefon do terminala, który ma jeden z powiązanych identyfikatorów sprzedawców.

W naszym przykładzie zakładamy, że wydawcy mają też ustawione takie klucze:

iLuvCoffeeEat-fooBacon-R-us
Identyfikator wydawcy123456789
Identyfikator sprzedawcy111111114444444477777777
Klasa lojalnościowaR-podstawowyMoje nagrody- Brak -
Klucz publicznyaaabbb- Brak -

Użytkownik ma na swoim koncie Google Pay kartę lojalnościową iLuvCoffee R-podstawowy i kartę Eat-foo Moje nagrody, z których chce skorzystać, zbliżając telefon do różnych terminali.

Poniżej znajdziesz identyfikatory wydawców elementów promocyjnych tych dwóch klas kart lojalnościowych:

  • R-podstawowy: 456, 789.
  • Moje nagrody: 456.

Oto trzy możliwe rezultaty:

Terminal iLuvCoffee: w zasadzie aplikacja Google Pay może uwierzytelnić terminal i zatwierdzić go jako należący do iLuvCoffee. Jednak sprzedawca iLuvCoffee nie może wykorzystać własnej klasy lojalnościowej wydawcy, R-podstawowy. Dlatego w tym przypadku nie są przesyłane żadne dane.

Terminal Eat-foo: aplikacja Google Pay uwierzytelnia terminal Eat-foo, który używa klucza publicznego „bbb”. Jeśli założymy, że użytkownik nie może zobaczyć ekranu ze szczegółami karty R-podstawowy lub Moje nagrody, na przykład na karcie głównej, aplikacja wyszukuje karty do wykorzystania przez Eat-foo. Znajduje karty R-podstawowy i Moje nagrody oraz wyświetla karuzelę, w której użytkownik może kliknąć, aby wybrać kartę do przesłania

Jeśli użytkownik wyświetli kartę R-podstawowy i użyje smart tap, zostanie przesłana tylko karta R-podstawowy.

Terminal Bacon-R-us: na naszej platformie nie ma klucza publicznego Bacon-R-us, więc nawet jeśli ten sprzedawca jest ustawiony na karcie programu R-podstawowy jako wydawca elementów promocyjnych, nie może uwierzytelnić terminala i nie są przesyłane żadne dane.

Limity uwierzytelniania

Synchronizacja karty z aplikacją Google Pay polega na wyszukaniu w backendzie Google wszystkich wydawców materiałów promocyjnych karty. Identyfikatory sprzedawców, klucze publiczne i wersje kluczy przypisane do wydawców materiałów promocyjnych są zapisywane lokalnie na karcie w aplikacji Google Pay.

Identyfikator sprzedawcy może mieć wiele kluczy publicznych i wersji kluczy. Karta może mieć wiele identyfikatorów wydawców materiałów promocyjnych z mapowaniem jeden do jednego na identyfikator sprzedawcy.

Jeśli aplikacja Google Pay nie ma kart, które można wykorzystać w tym terminalu, nie uwierzytelni go. Określa to identyfikator sprzedawcy i żądana wersja klucza. Aktualizacja kluczy publicznych karty wymaga, aby urządzenie miało połączenie z internetem, co pozwoli mu pobrać nowe klucze z backendu Google.

Kartę można powiązać z wieloma kluczami publicznymi jednocześnie. Informacje o tym, jak ustawić wiele kluczy dla jednej karty, znajdziesz w sekcji Włączanie smart tap u sprzedawcy.

Wartość przekazana z karty

Obiekt każdej kategorii musi mieć ustawioną tę właściwość ciągu: object.smartTapRedemptionValue.

Gdy w klasie odpowiadającej obiektowi włączy się obsługa smart tap, ta wartość zostanie wysłana do terminala.

Użyj tej wartości do identyfikacji karty użytkownika zgodnie z ustawieniami punktu sprzedaży i wykonaj poniższe czynności po zbliżeniu telefonu do terminala sprzedawcy:

  1. Zaktualizuj saldo lub stan konta użytkownika w punkcie sprzedaży.
  2. Zaktualizuj swój backend zgodnie z transakcją w punkcie sprzedaży.
  3. Wyślij do obiektu aktualizację, która pokaże się na karcie Google Pay.

Szyfrowaniem wszystkich danych przesyłanych przez NFC zajmuje się terminal i aplikacja Google Pay. Po użyciu smart tap dane są odszyfrowywane przez terminal. Dane zawierają rekordy NDEF obiektu usługi, które odpowiadają przesyłanym kartom. Service number NDEF Record obiektu usługi zawiera ładunek z wartością ustawioną w parametrze object.smartTapRedemptionValue karty. Oznacza to, że programista karty nie musi niczego szyfrować. Jeśli programista potrzebuje dla większego bezpieczeństwa dodatkowego poziomu szyfrowania, ustaw wartość tak, aby mógł ją odszyfrować tylko system punktu sprzedaży. Za szyfrowanie odpowiada programista karty i osoba kontaktowa w punkcie sprzedaży.