Apple Pay DPAN
You’re now watching this thread. If you’ve opted in to email or web notifications, you’ll be notified when there’s activity. Click again to stop watching or visit your profile to manage watched threads and notifications.
You’ve stopped watching this thread and will no longer receive emails or web notifications when there’s activity. Click again to start watching.
I’m facing an issue with some master sandbox testing cards, the DPAN value displayed on the “Wallet
& Apple Pay Setting” different from the value we got after decrypting the payment token. check the below sample values:
FPAN: 5204 2477 5000 1497
DPAN on device setting: **********5057
Decrypted DPAN: 520424****5996
The DPAN and the decrypted DPAN should be the same.
Пропуск в партер – как запускались Apple Pay и Samsung Pay в Яндекс.Деньгах
На волне всеобщего увлечения бесконтактной оплатой хочу поделиться подкапотным опытом Яндекс.Денег по запуску Apple Pay и Samsung Pay. Нашей команде пришлось координировать усилия с MasterCard и производителями смартфонов. Подружить эту компанию и не сойти с ума – задача сама по себе нетривиальная. Вдобавок мы были в первой волне тех, кто пришел на «праздник», и многие решения пришлось обкатывать на ходу.
Под катом подробности о подключении бесконтактных платежей в Яндекс.Деньгах, тестировании и особенностях работы систем безопасности с новым типом платежей.
В этом посте речь пойдет о платежных системах Apple Pay и Samsung Pay, которые основаны на схожих принципах и отличаются в деталях. Для простоты я буду называть их просто *Pay везде, где детали не принципиальны.
Зачем все это
Оплатить товар с телефона можно давно – достаточно установить мобильное приложение вашего банка, в котором должна быть опция бесконтактной оплаты (приложение Яндекс.Денег тоже подойдет, кстати). Данные о карте хранятся в защищенном виде на устройстве пользователя и доступны по технологии HCE – это программный аналог чипа банковской карты.
Есть и отдельные программы вроде Кошелька, которые предлагают возможности беспроводной оплаты для банков-партнеров и, в качестве бонуса, хранение скидочных карт.
Вот почему раньше для бесконтактной оплаты требовались дополнительные «прослойки»:
- Владельцы iPhone не могли платить бесконтактно, потому что интерфейс NFC в смартфонах Apple нельзя напрямую использовать для оплаты в сторонних приложениях. К тому же NFC появился только в iPhone 6 и SE.
- На многих современных смартфонах появилось отдельное устройство Secure Element (SE), которое выполняет функции EMV-чипа банковской карты и не привязано к конкретному банку или карте. Такое унифицированное решение удобнее пользователю и проще в реализации банку, у которого до этого не было оплаты со смартфона.
Apple Pay и Samsung Pay нужны в первую очередь для того, чтобы оплата со смартфона через NFC стала стандартизированной и безопасной.
Небольшой экскурс в появление Secure Element и безопасность карточек
Изначально платежные карты выпускались только с магнитной полосой, на которой был записан номер карты. Естественно, номер легко копировался, поэтому за дело взялась организация EMVCo, разработавшая более защищенный чип EMV. Эта мера позволила существенно сократить число мошеннических операций, но целиком проблему не решила. Кроме того, процесс оплаты был несовершенен и поэтому продолжались работы над дальнейшими улучшениями.
Далее появились бесконтактные платежи на пластике (MasterCard PayPass, VISA PayWave), а потом платежные функции карты стали частично переходить на мобильные устройства.
Путь был тернист, и среди прочих платежные системы пробовали следующие варианты:
- SIM-карта со встроенным чипом Secure Element, выпускаемая совместно сотовым оператором и банком-эмитентом;
- наклейка на телефон со встроенным беспроводным модулем и Secure Element;
- использование встроенного в телефон NFC-адаптера и программной эмуляции Secure Element (HCE).
В конечном счете MasterCard «перетасовал карты» и закрепил за производителями мобильных устройств функции хранения карточных данных и проведения оплаты. Так появился MasterCard Digital Enablement Service (MDES) от MasterCard, а затем и *Pay.
Но HCE все равно полностью не исчезла, так как позволяет банкам использовать собственные мобильные приложения для бесконтактной оплаты. То есть банк может самостоятельно добавить в свое приложение функцию оплаты с карты. Плюс к тому, в приложении можно реализовать какие-нибудь фирменные удобства вроде оплаты ЖКХ.
Кстати, в мобильных Яндекс.Деньгах тоже осталась опция бесконтактной оплаты через HCE — для всех тех, кто по разным причинам не может воспользоваться *Pay.
Подружить всех со всеми
Надеюсь, теперь все причинно-следственные связи восстановлены, поэтому вернемся к проекту бесконтактной оплаты Яндекс.Денег.
Если все равно что-то осталось туманным – обязательно спрашивайте в комментариях.
Все дальнейшие сценарии буду иллюстрировать на примере карт Яндекс.Денег, по которым набралось больше всего информации.
Чтобы пользователь мог непринужденно оплатить товар с телефона, нужно тесное сотрудничество четырех сторон:
- сервиса бесконтактных платежей от производителя смартфона (Apple Pay и Samsung Pay);
- платежной системы (MasterCard);
- эмитента карточки (Яндекс.Деньги);
- банка-эквайера продавца.
Таким образом, команде Яндекс.Денег нужно было договориться с Apple, Samsung, Mastercard и реализовать поддержку обновленных платежных протоколов на своей стороне. Еще потребовалось добавить прием платежей через Apple Pay и Samsung Pay в Яндекс.Кассу – платёжное решение для бизнеса. Но это уже другая история.
На иллюстрации не хватает банка-эквайера – убрал его для простоты.
Когда пользователь добавляет карту в кошелек, Apple Wallet формирует криптограмму с зашифрованными данными карты и цифровой подписью, а затем отправляет ее в MasterCard. Там криптограмма расшифровывается и происходит токенизация. Токенизация – это формирование номера DPAN, который представляет собой синоним оригинальной карты, уникальный для каждого физического устройства.
Памятка о DPAN и его особенностях
Digital Primary Account Number (DPAN) – это специальный номер-токен, который платежная система выдает конкретному устройству для использования одной из карт пользователя. Такой номер уникален для каждого устройства и поэтому генерируется каждый раз при добавлении одной и той же карты в кошелек очередного устройства.
Токен нужен для того, чтобы не хранить на мобильном устройстве реальных платежных данных.
Но DPAN не будет сгенерирован, пока MasterCard не проверит поддержку *Pay на стороне эмитента, то есть Яндекс.Денег. Для этого необходимо:
- Дождаться проверки Apple или Samsung возможности использовать устройство в качестве оплаты (не украден ли телефон, есть ли права Root и т.д.).
- Подключиться к MasterCard Digital Enablement Service (MDES). Подробности о подобных приложениях едва ли не полностью подпадают под NDA, поэтому желающим придется запрашивать документацию напрямую у MasterCard.
- Реализовать поддержку специфических запросов *Pay.
- Протестировать систему с Apple, Samsung и MasterCard. Тестирование частично выездное, поэтому тут все не так просто, как может показаться.
Но пользователь может захотеть добавить карту не вручную, а из приложения Яндекс.Денег. Такая возможность есть, но используется немного другой механизм.
Красный, желтый, зеленый
Когда пользователь добавляет карточку в кошелек телефона, запускается один из трех сценариев дальнейшего развития событий, в зависимости от степени риска:
- Зеленый. Используется когда запрос на добавление карты приходит от мобильного приложения эмитента (Яндекс.Деньги) и в нем есть специальный ключ, подтверждающий аутентификацию пользователя в банковском приложении. Дополнительных проверок не требуется.
- Желтый. Обычно используется при добавлении карты вручную или с помощью камеры телефона (OCR). Кошелек спросит CVV-код карты и запросит дополнительную аутентификацию.
- Оранжевый. Фактически означает отказ в добавлении карты.
Если у вас еще нет пластиковой карты Яндекс.Денег, то для пробы пера можно выпустить виртуальную прямо в приложении.
Но мы живем не в идеальном сферическом мире, поэтому часто будет использоваться именно желтый путь. Чтобы он тоже проходил гладко и на этапе распознавания реквизитов карты камерой не было проблем, мы отправили в Apple более 200 фото тестовых карточек. Без этого обучения алгоритм распознавания периодически ошибался и пытался добавить в кошелек карту с неверными данными.
Предполетная подготовка
Когда необходимый софт на бэкенде был готов, а бета-версия Яндекс.Денег обучена премудростям Apple Pay (для Samsung Pay опция токенизации через наше мобильное приложение пока недоступна), настала утомительная пора тестирования.
Кстати, для подключения к «банкету» недостаточно все реализовать и сообщить в MasterCard о готовности – платежная система и производители телефонов обязательно проверят вас лично. Например, по поводу Apple Pay к нам приехал товарищ из компании UL с набором всевозможных гаджетов Apple. Одних только iPhone у него было 6 штук — 3 поколения в 2 версиях (простая и Plus). С их помощью аудитор проверил множество сценариев оплаты, включая возврат средств.
Обновленный процессинг Яндекс.Денег работал в изолированном тестовом сегменте, поэтому для проверки использовался «белый список» карт – для них MasterCard просто включил платежи *Pay. Но вот с тестовой средой от Apple были некоторые сложности.
Например, отдельной платежной инфраструктуры для обкатки не было, поэтому тестировщикам Яндекс.Денег пришлось перевести свои смартфоны и Apple ID на регион «США» и подбирать ответы на некоторые запросы самостоятельно.
Но дьявол кроется в деталях, а ошибки – на последней миле. Оказалось, что далеко не все банки следят за обновлением прошивок своих терминалов, а кассирам в большинстве своем чужды современные технологии.
Карту давайте…
Моделей платежных терминалов и прошивок к ним довольно много, и у самых древних из них мозги сходили с ума от *Pay. Пришлось понимать и прощать, попутно сообщая в поддержку соответствующих банков о “небольших сложностях с POS-терминалом”.
Когда все уже вроде бы работало, по некоторым транзакциям в мобильный кошелёк стали приходить суммы с прочерком. Это явно означало проблемы вне систем Яндекс.Денег. Конечно, на саму оплату такие отчеты не влияли, но когнитивный диссонанс присутствовал.
(Не)лазейка для мошенников
Токенизация карт со стороны Яндекс.Денег, как и других банков, сопровождается проверкой таких запросов на мошеннические паттерны. Для этого в Яндекс.Деньгах существует отдельный механизм со своей сложной логикой и полномочиями блокировать крайне подозрительные операции – система антифрода.
Так как система работает на основе определенных правил, обнаружилась потенциальная проблема с безопасностью при токенизации чужой карты на устройство. Для этого нужны номер карты, срок действия и CVC2. Да, эмитент наверняка запросит дополнительную валидацию, но даже в случае с SMS-паролем фишинг и социальная инженерия работают. При сумме оплаты до 1000 рублей терминал даже пин-код не спросит, а SMS-оповещения включены до сих пор не у всех владельцев карт.
С такими угрозами можно бороться на уровне процессинга. Каждое действие пользователя со своим счетом или картой рассматривается в режиме онлайн фрод-машиной: если сработает хотя бы одно блокирующее правило, то транзакция будет отклонена.
Для каждого пользователя Яндекс.Денег формируется индивидуальный поведенческий профиль: что он любит и не любит, как и когда обычно платит, типичные периоды активности и множество других признаков. На основе этой информации и с помощью машинного обучения строится прогноз будущих значений, то есть наиболее вероятных действий человека. Если антифрод замечает отклонения фактических показателей от их прогноза, то может запросить дополнительную аутентификацию или отклонить транзакцию.
Про машинное обучение в системах безопасности можно много интересного рассказать в связи с его давним внедрением в Яндекс.Деньгах, но это уже тема отдельной статьи.
Если вы по работе сталкивались с другими нюансами подключения к *Pay – поделитесь в комментариях, многим будет любопытно.
- Apple Pay
- Samsung Pay
- бесконтактные платежи
- яндекс.деньги
- mastercard
Порядок использования банковских карт в сервисах мобильных платежей
1. Термины и определения
1.1. Мобильное приложение (Apple Pay / Google Pay / Samsung Pay / Mir Pay) – программа Сервиса, предустановленная Клиентом на Мобильном устройстве, позволяющая осуществить Токенизацию и хранить информацию о Токенах, а также информацию, позволяющую однозначно различить ту или иную Карту: изображение Карты, последние 4 цифры Номера карты (FPAN).
1.2. Мобильное устройство – устройство, поддерживающее работу с операционными системами:
– IOS (iPhone 6 и выше, iPad, Apple Watch, Mac);
– Android (устройства с NFC-чипом, которые работают под управлением системы Android KitKat (4.4) и выше).
1.3. Номер карты (FPAN) – уникальный набор цифр, наносимый эмбоссером (иным устройством персонализации) на лицевую сторону Карты. Номер карты состоит из шестнадцати цифр.
1.4. Пароль — комбинация символов (цифр), служащая для Верификации Клиента в Мобильном устройстве. Пароль обеспечивает однозначную Верификацию Клиента в Мобильном устройстве. Пароль используется многократно, и может быть изменен Клиентом самостоятельно неограниченное количество раз.
1.5. Сервис – мобильные платежные сервисы от компаний Apple Inc. / Google Ireland Limited / Samsung Electronics Co. Ltd. / Акционерное общество «Национальная Система Платежных Карт». Сервис совместим с существующими бесконтактными считывателями Платежных систем, которая позволяет Клиенту оплачивать покупки при помощи беспроводной связи Мобильного устройства без физического использования Карты.
1.6. Токен (DPAN) – цифровое представление Карты, которое формируется по факту регистрации Карты в Мобильном приложении, и которое хранится в зашифрованном виде в защищенном хранилище Мобильного устройства.
1.7. Токенизация – процесс создания Токена (DPAN) и его связки с Картой, позволяющий однозначно определить Карту, использованную для совершения операций с использованием Сервиса. Токенизация осуществляется по факту добавления Карты в Мобильное приложение.
1.8. ID – уникальный идентификатор Клиента как пользователя Мобильного устройства.
1.9. Wallet – предустановленная на Мобильном устройстве программа Сервиса, позволяющая осуществить Токенизацию и хранить информацию о Токенах, а также информацию, позволяющую однозначно различить ту или иную Карту: изображение Карты, последние 4 цифры Номера карты (FPAN).
2. Общие положения
2.1. Банк не является провайдером в Сервисе и не предоставляет программное обеспечение (Мобильное приложение), устанавливаемое на Мобильном устройстве Клиента, в котором хранится Токен (DPAN).
2.2. С помощью Сервиса владельцы Мобильных устройств могут оплачивать покупки по технологии NFC (технология беспроводной высокочастотной связи малого радиуса действия) в сочетании с Мобильным приложением и Touch ID / Face ID. Сервис позволяет Мобильным устройствам осуществлять платежи в торгово‑сервисных предприятиях и сети Интернет. Клиент может выполнять платежи, используя беспроводную связь с Мобильного устройства. Использование Сервиса осуществляется в соответствии с настоящим «Порядком использования банковских карт КБ «ЭНЕРГОТРАНСБАНК» (АО) в сервисах мобильных платежей» и правилами мобильных платежных сервисов.
2.3. Информация из аппаратно программного комплекса Платежной системы, Процессингового центра и компаний Apple Inc. / Google Ireland Limited / Samsung Electronics Co. Ltd. / Акционерное общество «Национальная Система Платежных Карт» может использоваться в качестве доказательств при рассмотрении споров по операциям по Карте в Сервисе, в том числе в судебном порядке.
2.4. Документ по операциям с использованием банковских карт (реестр операций/платежей), подписанный электронной подписью Процессингового центра, юридически эквивалентен Распоряжению Клиента на совершение Операций по Счету, составленному на бумажном носителе и подписанному оригинальной подписью Клиента, и является для Банка Распоряжением Клиента на совершение операции по Счету и составление Расчетного документа, необходимого для проведения Операций по Счету при использовании банковских карт КБ «ЭНЕРГОТРАНСБАНК» (АО) в Сервисе.
3. Регистрация Карт в Мобильном приложении
3.1. Для осуществления расчетов через Сервис Клиенту необходимо зарегистрировать Карту в Мобильном приложении одним из способов:
– используя камеру Мобильного устройства с автоматическим заполнением Реквизитов карты и ручным вводом CVC2;
– используя ручной ввод Реквизитов карты (номер карты, срок действия карты, CVC2);
– иной способ при наличии технической возможности.
Фиксация момента регистрации Карты в Мобильном приложении осуществляется в электронном виде в аппаратно программном комплексе Процессингового центра. На момент регистрации Карта должна быть активна, иметь не истекший срок действия.
3.2. При регистрации Карты в Мобильном приложении Авторизация Клиента может осуществляться путем ввода Клиентом одноразового пароля, направленного на номер мобильного телефона в виде SMS-сообщения и/или PUSH-уведомления. При совершении Операции по карте Авторизация Клиента может осуществляться одним из следующих способов в зависимости от технологий и функциональных технических возможностей используемого Мобильного приложения и/или Мобильного устройства:
– путем ввода Клиентом Пароля;
– с использованием технологий Touch ID / Face ID;
– путем ввода ПИН кода Мобильного приложения.
3.3. После ввода Номера карты, при необходимости дополнительной проверки Клиента Банком (по усмотрению Банка), осуществляется Верификация Клиента и активация Токена с использованием Простой электронной подписи путём ввода Клиентом Одноразового пароля, полученного в SMS сообщении и/или PUSH уведомлении или на номер мобильного телефона Клиента.
3.4. По факту успешной регистрации Карты в Мобильном приложении в защищенном хранилище Мобильного устройства формируется и хранится Токен. Токен позволяет однозначно идентифицировать Карту, используемую при совершении платежей в Сервисе. По факту успешной регистрации Карты в Мобильном приложении Сервис направляет Клиенту соответствующее SMS-сообщение и/или PUSH уведомление.
3.5. Клиент может самостоятельно удалить одну или несколько Карт из Мобильного приложения с помощью кнопки «удалить».
3.6. Изображение Карты в Мобильном приложении может не соответствовать реальному дизайну Карты и содержит маскированный Номер карты (отображены 4 последние цифры Номера карты).
3.7. Клиент может зарегистрировать на одном Мобильном устройстве не более 10 (Десяти) Карт (контроль осуществляет Сервис).
4. Подтверждение Операции по карте (платежа)
4.1. Платежи в Сервисе могут осуществляться:
– через POS терминал, оснащенный технологией NFC;
– в мобильных приложениях на Мобильном устройстве, поддерживающих расчеты через Сервис.
4.2. Если платеж совершен через POS терминал, оснащенный технологией NFC, то подтверждение платежа для Мобильного приложения может осуществляться одним из следующих способов в зависимости от технологий и функциональных технических возможностей используемого Мобильного приложения и/или Мобильного устройства:
– путем ввода Клиентом Пароля;
– с использованием технологий Touch ID / Face ID;
– путем ввода ПИН-кода Мобильного приложения.
4.3. Если платеж совершен в мобильном приложении, поддерживающем Сервис, то подтверждение платежа осуществляется с помощью Touch ID / Face ID на Мобильном устройстве либо (в случае такой технической необходимости (невозможно отсканировать палец, искажен Отпечаток пальца и т.д.)) вводом пароля от Мобильного устройства.
4.4. При наличии 2 (Двух) и более Карт в Мобильном приложении, в том числе других банков эмитентов, Клиент должен выбрать Карту, с использованием которой будут совершаться платежи в Сервисе.
4.5. В Мобильном приложении фиксируются 10 (Десять) последних операций по каждой Карте, содержащейся в Мобильном приложении.
4.6. Стороны установили, что для Сторон доказательством совершения Операций по Карте с использованием Мобильных приложений является Документ (реестр операций/платежей) по Операциям по карте, соответствующий условиям п.п. 4.8, 4.9 Приложения 3 настоящих Правил КБО.
5. Блокировка Мобильного устройства / Токена
5.1. В случае блокировки Карты блокируются все Токены для данной Карты на всех Мобильных устройствах с целью недопущения совершения расчетов в Сервисе.
5.2. В случае утраты Мобильного устройства Клиенту необходимо обратиться в Банк с целью блокировки Токена, содержащегося на данном Мобильном устройстве. В данном случае Банк блокирует только Токен, содержащийся на данном Мобильном устройстве.
6. Требования к безопасности
6.1. Организационные меры по защите информации, реализуемые Клиентом:
– не оставлять Мобильное устройство без присмотра;
– обеспечить соответствующий уровень безопасности на Мобильном устройстве, используя Пароли, Touch ID / Face ID и другие возможные методы блокировки/разблокировки Мобильного устройства;
– убедиться, что на Мобильном устройстве не зарегистрированы Отпечатки пальцев или Модель лица другого лица;
– не разглашать третьим лицам регистрационные данные от Мобильного устройства, такие как ID, Пароль;
– удалить все личные данные и финансовую информацию со старого Мобильного устройства, если прекращено его использование;
– обратиться в Банк по номеру телефона, напечатанному на оборотной стороне Карты, либо по номеру телефона Банка, указанному на сайте Банка www.energotransbank.com, как можно скорее, в случае подозрений на любое несанкционированное использование Мобильного устройства, а также, если Мобильное устройство было взломано, потеряно или украдено.
6.2. Необходимо изменить учетные данные в Мобильном устройстве, чтобы избежать несанкционированного использования Карт:
– не блокировать любые функции безопасности, предусмотренные приложениями Мобильных устройств, для использования этих функций и процедур безопасности для защиты всех Карт, зарегистрированных в Мобильном приложении;
– создать сложный Пароль;
– удалять информацию о Картах в Мобильном приложении при передаче Мобильного устройства третьим лицам;
– не подвергать Мобильное устройство операциям взлома операционной системы устройства.
7. Ответственность сторон
7.1. Клиент несет ответственность:
– за сохранение конфиденциальности ID, Пароля и других средств Верификации Клиента;
– за использование Мобильного устройства третьими лицами;
– за Операции по карте, совершенные Клиентом в Сервисе;
– за нарушение требований к технической защите Мобильного устройства, указанных в Разделе 6 Порядка, в том числе в случаях, когда Клиент использует Мобильное устройство, которое было подвергнуто операциям взлома операционной системы устройства.
7.2. Банк не несет ответственности:
– за работу Сервиса;
– за отсутствие возможности совершения в Сервисе Операций по карте;
– за любое приостановление, аннулирование или прекращение использования Карты в Сервисе;
– за конфиденциальность информации, хранящейся на Мобильном устройстве, в том числе в Мобильном приложении;
– за состояние сетей беспроводной связи, используемой Сервисом;
– за конфиденциальность и безопасность передачи данных в связи с электронной передачей данных через сторонние подключения, не попадающие под контроль Банка. Обеспечение конфиденциальности и безопасности передачи данных осуществляется компаниями Apple Inc. / Google Ireland Limited / Samsung Electronics Co. Ltd. / Акционерное общество «Национальная Система Платежных Карт»;
– за поддержку операционной системы (iOS, Android OS) Мобильного устройства.
What Is DPAN and Card Info?
What is DPAN and Card Info? These are two payment card properties introduced by Google Pay and Apple Pay almost in the same way. See details below.
Try our Android app NFC EMV Explorer. Tap your cards, watches, and phones to touch and feel PAN and DPAN.
About DPAN
Whereas Primary Account Number (PAN) is the real card number, usually depicted on the card, the Device PAN (DPAN) is assigned to the card as a pseudonym. It looks like a PAN but it is not. It is associated with a particular device (e.g. a smartphone) which emulates the card virtually stored in the Google Pay or Apple Pay wallet.
If the same card is virtually stored in another wallet, it will have DPAN different from the one associated with the first wallet.
DPAN is a unique card number alias. Only one real card is associated with a given DPAN. The opposite is not true. One real card may have several DPANs, different in each device.
The card issuer assigns DPAN at the time of adding the virtual card to the wallet (Google Pay or Apple Pay one). This is done via so called card tokenization process.
The process of adding a card to a wallet and assigning a DPAN to it is pretty complex. From the Cardholder’s standpoint it is rather simple and described in Google and Apple documentation. There are the following agents or services participating in this process at the same time:
- Google Pay or Apple Pay service
- Android or Apple (iOS or MAC) operating system
- Cardholder
- Issuer
- Tokenization infrastructure
The good news is that the cardholder does not need to know anything about the above. The cardholder simply follows instructions on the device, to complete the process within a minute or so.
DPAN cannot be used to create a fraudulent transaction at e-merchant website because the real card PAN must be used there.
The real card PAN is not stored in Google Pay or Apple Pay wallets and does not participate in transactions originated via these wallets.
Google Pay wallet shows the DPAN “tail”, or masked DPAN, as virtual account number, e.g. “**** 1355” to the the smartphone holder. The masked DPAN is depicted in the card details in the wallet application.
Apple Pay does practically the same but calls the masked DPAN device account number.
About Card Info
The last 4 digits of PAN along with the card schemes IDs such as “Visa” or “Mastercard” comprises so called Card Info. Card Info is available to e-merchants participating in payment transactions originated via Google Pay or Apple Pay wallets. It is used for transaction tracking and resolving issues with cardholders.
Remarkably, Card Info is not available for brick-and-mortar merchants engaging Google Pay and Apple Pay wallets via NFC-capable Point of Sales (PoS) terminals when they read virtual cards data in these wallets. NFC PoS terminals operate with DPAN.
DPAN and PAN Tracking Examples
PAN and DPANs are provided below for the matter of examples. They are accidental, invalid, and do not pass Luhn checks.
Let’s suppose, for the matter of example, that you have Visa card with PAN 4000000000004321. In most cases, you can see the PAN depicted on your card plastic. Respectively, Card Info digits will be depicted at your card image in your Google Pay and Apple Pay wallets in a form of
Let’s suppose that the same (virtual) card in your Google Pay wallet has DPAN 4111111111115876. You can see the masked DPAN in your Google Pay wallet as
virtual account number **** 5876
Let’s suppose that the same (virtual) card in your Apple Pay wallet has DPAN 42222222222223545. You can see the masked DPAN in your Apple Pay wallet as
device account number **** 3545
Your payments receipts, printed by an NFC PoS terminal at a brick-and-mortar merchant, depicts the following:
- **** 4321, if you tapped your real card
- **** 5876, if you tapped your smartphone with Google Pay
- **** 3545, if you tapped your smartphone with Apple Pay
If you use your card directly (not Apple Pay or google Pay) for online payments at an e-merchant, your receipt from the merchant will depict card info: something like **** 4321 or Visa 4321.
If you use Google Pay or Apple Pay for online payments or for in-app payments, your receipts will display the same.
Please note that if you have more than one smartphone (or smartwatch) with Google Pay (or Apple Pay to that matter) DPANs of the same card will be different in each of them.
DPAN Issues
Unfortunately, there are some issues with DPAN and PAN creating poor user experience in some use cases and limiting usage of Google Pay and Apple Pay. The devil is, as always, is in the details.
DPAN is Hidden in E-commerce
DPAN (as a method of card tokenization) was introduced to make PAN “secret”. Hence, there is no need to hide DPAN because it cannot be used outside its wallet. From the merchant standpoint, having DPAN can be useful because it is unique and can allow to associate a given card with certain business processes within the merchant.
Both Apple Pay and Google Pay hide DPAN from “simple” e-merchants (non-PCI-DSS compliant ones). They hide DPAN within an encrypted payment token associated with a given transaction.
E-merchants, may have access to DPAN if they are PCI DSS-compliant but this is costly.
The whole idea of card tokenization was to make the merchants’ life easy, and give them a unique and safe card pseudonyms without requesting from merchants PCI-DSS compliance.
DPAN is Readable at Brick-and-Mortar Merchant
Despite Google Pay and Apple Pay effort to hide DPAN from e-merchants, they cannot hide it from brick-and mortar-merchants. Technically, this would have been possible but extremely expensive because it would require changing EMV standard and reprogramming all NFC-capable PoS terminals.
Any such terminal reads DPAN when you tap your smartphone with your virtual card stored in Google Pay or Apple Pay wallet. You can find more details here for Visa and Mastercard cards.
Public Transit Use Case
Some account-based public transit fare collection systems use online card payment transactions to prepay transit services and register your card as a transit pass. This allows you, later, to tap the same card at the transit validation device and get access to the transit service you already purchased online. Of course, your card PAN participates in such registration.
It such cases, you better not tap your smartphone with Google Pay or Apple Pay at the validation device because the DPAN is not equal to PAN. Transit gates will not open.
The similar is applicable to transits that cap or discount your fares post-factum, aggregating your rides during a certain period of time. Do not tap different devices and cards if you want to get your discount because the PAN and all your DPANs are different. See, for example, Transport for London instructions to that matter.
Loyalty Use Case, Across Web and NFC Transactions
Suppose, you used your real card PAN to buy something online at FloorMart website and you got some loyalty points associated with your card PAN.
Later, you decide to visit a brick-and-mortar FloorMart store in person, and use your loyalty to get a discount.
Make sure that you tap your real card, not your smartphone, at their PoS terminal. Otherwise, you will not get your discount because DPAN is not equal to PAN.