Динамические штрихкоды

Введение

Динамические штрихкоды выглядят как обычные, но периодически меняются, как правило, каждую минуту. Терминал или считывающее устройство программируется так, чтобы принимать только последний штрихкод. Эта мера безопасности снижает риски, связанные со скриншотами штрихкодов, в частности кражу билетов или их несанкционированную перепродажу. Динамические штрихкоды также могут использоваться в качестве резервного варианта для устройств, которые не поддерживают технологию Smart Tap из-за отсутствия NFC (аппаратного или программного).

Документация по API

Технические сведения о динамических штрихкодах приведены в разделе Тип RotatingBarcode.

Пример полезной нагрузки

JSON 
{
  "rotatingBarcode": {
    "type": "QR_CODE",
    "valuePattern": "MyRotatingBarcode-{totp_timestamp_seconds}-{totp_value_0}",
    "alternateText": "Ticket#: 1234567890",
    "totpDetails": {
      "algorithm": "TOTP_SHA1",
      "periodMillis": "3000",
      "parameters": [
        {
          "key": "3132333435363738393031323334353637383930",
          "valueLength": "8"
        }
      ]
    }
  }
}

Резервные механизмы

На устройстве пользователя в каждый момент времени используется только один механизм погашения, в зависимости от того, как настроена карта и от возможностей устройства. Типы погашения используются в следующем порядке приоритета:

  1. Smart Tap: если указаны полезные данные Smart Tap и устройство поддерживает NFC/HCE.
    • Обратите внимание, что пользователь может переопределить это поведение, нажав "Показать код". В этом случае будет показан динамический или статический штрихкод.
  2. Динамический штрихкод. Если указаны полезные данные динамического штрихкода.
  3. Статический штрихкод: если указаны полезные данные штрихкода.

Указание нескольких полезных нагрузок для погашения может обеспечить поддержку всех пользователей, но может иметь последствия для безопасности. В частности, если в качестве резервного варианта для динамического штрихкода используется статический, это сводит на нет большинство преимуществ динамического штрихкода с точки зрения безопасности. Статический резервный штрихкод будет показываться только в веб-просмотрах или на клиентах, которые не поддерживают динамические штрихкоды. Мы ожидаем, что все клиенты Google Кошелька будут поддерживать динамические штрихкоды.

Сохранить процесс

Google Wallet API предлагает несколько способов, в том числе:

  • создавать классы билетов на общественный транспорт при сохранении или заранее;
  • отправлять полные объекты в JWT или сохранять их заранее, а затем ссылаться на них по идентификатору в JWT;
  • Обновление объектов после их сохранения

Предлагаемое поле rotatingBarcode совместимо со всеми этими процессами, однако в целях повышения безопасности мы рекомендуем следующее:

  • Вызовите API object:insert, чтобы добавить карту на сервер Google Кошелька, и настройте кнопку "Добавить в Google Кошелек" так, чтобы она ссылалась на определенный объект по идентификатору в JWT. Это гарантирует, что в полученный JWT не будет включен секретный ключ динамического штрихкода.
  • Используйте секретный ключ одноразового пароля, который относится к одной карте.
  • Если ключ не обновляется, он должен быть действителен в течение всего срока действия карты. Мы не планируем обновлять этот ключ в ходе обычной работы.

На следующей схеме показано взаимодействие между различными участниками типичной интеграции.

Схема подключения динамических штрихкодов