СПОСОБ ПОЛУЧЕНИЯ ПЛАТЕЖНЫМИ СИСТЕМАМИ РЕКВИЗИТОВ ПОЛУЧАТЕЛЯ ПЛАТЕЖА
METHOD OF RECEIVING PAYMENT REQUISITES OF PAYMENT RECIPIENT BY PAYMENT SYSTEMS

Изобретение относится к способам автоматизации получения реквизитов получателя платежа при формировании счета на оплату для платежных систем, предназначенных для оплаты услуг и товаров, а также любых других переводов денежных средств.
В описании использована следующая терминология:
Платежная система - совокупность правил, процедур и технической инфраструктуры, обеспечивающих перевод стоимости от одного субъекта экономики другому. Платежные системы являются одной из ключевых частей современных монетарных систем. В ряде случаев платежными средствами выступают не деньги или долги, номинированные в деньгах, а условные платежные единицы или специализированные ценные бумаги (примером могут служить Web Money, биткойн). Платежные системы являются заменителем расчетов наличными деньгами при осуществлении внутренних и международных платежей и являются одним из базовых сервисов, предоставляемых банками и другими профильными финансовыми институтами.
Сторонняя платежная система - независимая платежная система, самостоятельно и отдельно функционирующая от способа (например, банк).
Платежные реквизиты - сведения, необходимые для перевода денежных средств. При этом могут иметься в виду реквизиты получателя платежа и реквизиты плательщика. В совокупности для совершения одного платежа используется более 40 реквизитов.
Безналичные расчеты - это платежи, осуществляемые без использования наличных денег, посредством перечисления денежных средств по счетам в финансовых учреждениях и зачетов взаимных требований.
Персональные данные - любая информация, относящаяся прямо или косвенно к определенному или определяемому физическому лицу (субъекту персональных данных). Хотя концепция персональных данных довольно стара, развитие компьютерных сетей и автоматизированного анализа данных позволили красть, централизованно собирать и массово продавать данные о человеке. Эти данные помогают выследить человека, спланировать преступление против него или постороннему выдать себя за другого человека.
Плательщик (покупатель, пользователь) - физическое или юридическое лицо, осуществляющее оплату за товар или услугу, а также осуществляющее перевод в чью-то пользу. Оплата может происходить в форме, отличной от денежной.
Получатель (продавец) - физическое, характеризующиеся ФИО и адресом прописки, или юридическое лицо, характеризующиеся названием и юридическим адресом или адресом точки реализации или электронным адресом, получающее оплату за товар или услугу, а также получающее перевод в свою пользу. Оплата может происходить в форме, отличной от денежной.
Матричный штрихкод - графическая информация, представляющая возможность считывания ее техническими средствами, - последовательность цветных и белых, или другого контрастного цвета геометрических фигур.
QR-код (англ. quick response - быстрый отклик) - разновидность матричного штрихкода (двумерный штрихкод), разработанная и представленная японской компанией «Denso-Wave».
URL (англ. Uniform Resource Locator,- единый указатель ресурса) - единообразный локатор (определитель местонахождения) ресурса.
Личный идентификатор - набор данных, содержащий уникальный номер в системе, наименование, адрес физический или электронный.
Идентификатор операции - набор данных, содержащий личный идентификатор, сумму, назначение платежа.
Тикет - уникальный номер операции в информационной системе получателя платежа, созданный шифрованием. Если получатель не имеет информационной системы, то тикет принимает значение по умолчанию ноль (0).
Точка продаж - место, где покупатель может оплатить выбранный товар или услугу. Точка продаж характеризуется наименованием, адресом и связанными с ней реквизитами. В случае существующего физически магазина адресом выступает почтовый адрес, в случае физического лица прописка (адрес регистрации в паспорте), в случае интернет магазина URL сайта.
Сервер системы - совокупность программного обеспечения и аппаратных средств для выполнения определенных функций, обеспечивающих функционирование системы. В данном описании относится к осуществлению заявляемого способа.
Клиентское устройство - смартфон, персональный компьютер или другое (в том числе мобильное) устройство с установленным специальным программным обеспечением для совместной работы в составе платежной системы и имеющее с ней связь для обмена данными.
В настоящем уровне техники существует множество различных платежных систем, предназначенных для использования физическими (Пример: Сбербанк Онлайн https://online.sberbank.ru) и юридическими лицами (Пример: iBank2 https://ibank2.ru). В последнее время наибольшую популярность получают системы безналичных online платежей с использованием Интернет для передачи данных. Такие системы реализованы в виде программы для клиентского устройства и имеют следующие недостатки:
- Включают ограниченный список получателей платежей, для которых пользователю не требуется вводить платежные реквизиты.
- Для остальных получателей платежей требуется вводить вручную платежные реквизиты, которые содержат большое количество (более 40 параметров) сложной для понимания обычного пользователя информации.
- Пользователь может не знать и не иметь возможности быстро получить платежные реквизиты получателя платежа в полном объеме.
Эти недостатки существенно ограничивают распространение и повсеместную применимость таких платежных систем.
Из уровня техники известен способ совершения покупок, описанный в патенте WО2012/083359, при котором:
- На сервере системы хранятся персональные данные покупателя, платежные реквизиты его банковских карт и других счетов, включая секретные данные для доступа.
- На сервере системы хранятся платежные реквизиты получателей платежей (продавцов).
- Для каждой покупки продавцом формируется через сервер системы индивидуальный QR-код, позволяющий однозначно идентифицировать данную покупку. Полученный QR-код визуально отображается для покупателя.
- Покупатель имеет клиентское устройство, программное обеспечение которого позволяет активировать QR-код и взаимодействует по каналу связи с сервером системы, который формирует заявку на покупку.
- Сервер системы выполняет оплату покупки путем перевода средств со счетов покупателя на счет продавца.
Описанный в патенте WO2012/083359 способ совершения покупок позволяет устранить недостатки, связанные с необходимостью ввода платежных реквизитов продавца и автоматизирует их получение, однако сам имеет ряд недостатков:
- Сервер системы описанного способа хранит персональные данные плательщика, платежные реквизиты его банковских карт и других счетов, включая секретные данные для доступа, а также историю движения средств. Фактически, сервер системы будет хранить консолидированную информацию о счетах, включая всю необходимую секретную информацию для осуществления переводов средств, что небезопасно.
- Описанный способ совершения покупок рассчитан на использование исключительно собственной платежной системы и не предполагает взаимодействия и использования внешних платежных систем, что ограничивает масштабы его использования, так как плательщикам (покупателям) придется устанавливать еще одну платежную систему на свои клиентские устройства и отказаться от использования существующих платежных систем.
- От получателя платежа (продавца) требуется наличие у него некой информационной системы, которая должна быть интегрирована с сервером системы и иметь постоянный канал связи, что ограничивает применимость способа продавцами, так как им придется нести дополнительные материальные затраты.
Наиболее близким к заявляемому является техническое решение по патенту на изобретение заявка RU №2658881 G06Q 30/04 (2012.01), с датой приоритета 01.06 2016 г., по которому СПОСОБ ПОЛУЧЕНИЯ ПЛАТЕЖНЫМИ СИСТЕМАМИ РЕКВИЗИТОВ ПОЛУЧАТЕЛЯ ПЛАТЕЖА характеризуется тем, что получатель платежа единожды регистрируется на сайте сервера системы, вводит характеризующие его данные и получает личный идентификатор в виде графического файла с изображением матричного штрихкода, который отображается (напечатан на бумажном носителе, отображен проецированием, голографически или на дисплее); плательщик имеет клиентское устройство с установленной сторонней платежной системой, адаптированной для работы со способом; плательщик с помощью клиентского устройства считывает изображение матричного штрихкода, из которого получает данные характеризующие получателя, верифицирует их, вводит сумму оплаты и подтверждает платеж; затем сторонняя платежная система отправляет идентификатор операции серверу системы по каналам связи, сервер системы верифицирует данные и возвращает платежные реквизиты сторонней платежной системе; сторонняя платежная система осуществляет перевод средств и, в случае успеха, сообщает об этом серверу системы; сервер системы уведомляет получателя об успешном переводе средств. Кроме того, матричный штрихкод содержит помимо личного идентификатора продавца сумму платежа и/или назначение платежа и/или реквизиты продавца, для генерации которых используется библиотека программ. В дополнение к матричному штрихкоду информация отображается буквенно-цифровым способом, при этом плательщик вводит информацию вручную в программное обеспечение сторонней платежной системы, интегрированной с системой способа.
Недостатки: защита операции недостаточна, поскольку фирменное наименование (наименование получателя платежа) не является уникальным фактором, QR-код может быть подменен, а плательщик это никак не сможет отследить, так же как и то, кому именно платит. Кроме того, обычный нешифрованный уникальный номер операции, формируемый платежными системами при обычной транзакции, может быть предсказуем при систематическом обращении к одному и тому же получателю платежа и простым увеличением номера выдан за оплату, т.е. не защищает получателя платежа от обмана.
Задача заявляемого способа - повысить безопасность способа получения платежными системами реквизитов получателя платежа путем включения в QR-код дополнительных факторов защиты, повышающих безопасность выполнения платежной операции, а также создания дополнительных уровней валидации.
Для этого предлагается в QR-код, формируемый информационной системой получателя платежа (продавца) включить адрес точки продаж, зарегистрированной получателем в системе, соответствующий наименованию точки продаж на сервере системы, а также тикет - шифрогенерируемый уникальный номер транзакции.
Первый момент. Поскольку наименование получателя платежа не уникально, добавление в QR-код адреса точки продаж, (а для интернет-магазинов - URL), в сочетании с наименованием точки продаж, отражаемых на одном из этапов валидации данных, позволит плательщику проконтролировать соответствие получателя платежа тому, которому он адресует платеж. Таким образом, плательщик, считав QR-код при помощи клиентского устройства, например, смартфона, может идентифицировать, кому платит, и в случае сомнения, отказаться от транзакции. Кроме того, валидация идентификационных данных получателя платежа проводится сервером системы и в случае успеха, т.е. установления соответствия идентификатора точки продаж + наименования + адрес, передает подтверждение сторонней платежной системе (например, в банк). Таким образом, включение в QR-код адреса точки продаж повышает уровень защиты и повышает безопасность платежной операции.
Второй момент. Так как уникальный номер операции может быть предсказан, то замена его на тикет (шифрогенерируремый уникальный идентификатор операции), включаемый в QR-код, повышает уровень безопасности платежной операции. Таким образом, повышается безопасность электронных платежей и использования сторонних платежных систем,
Общая последовательность действий заявляемого способа включает в себя: получатель регистрируется на сервере системы (т.е. в системе, предназначенной для осуществления заявляемого способа), регистрирует одни или несколько реквизитов, создает требуемое количество точек продаж (или пользуется персональной по умолчанию), связывает реквизиты с точками продаж, затем Получатель на каждую операцию генерирует QR-код, содержащий идентификатор точки продаж, наименование точки продаж, адрес точки продаж, тикет - опционально (если у получателя нет информационной системы, то тикет имеет по умолчанию нулевое значение, то есть равен нулю), назначение платежа - опционально, сумма - опционально, при этом идентификатор точки продаж, наименование точки продаж и адрес точки продаж должны совпадать с регистрируемыми получателем на сервере системы. Затем плательщик считывает QR-код, убеждается в правильности адресата платежа по демонстрируемым ему наименованию и адресу, в случае необходимости (если они не указаны в QR-коде) вводит сумму, назначение, затем отправляет введенные данные и данные из QR-кода сторонней платежной системе (частный случай - в банк), затем сторонняя платежная система проверяет не заморожен ли счет плательщика, достаточно ли денег на счету плательщика, если подтверждение есть, то сторонняя платежная система передает на сервер системы идентификатор, адрес, наименование. Затем сервер системы проверяет соответствие идентификатора и адрес + наименование точки продаж. Если данные подтверждаются, то сервер системы возвращает сторонней платежной системе (в банк) реквизиты получателя. Затем сторонняя платежная система проверяет реквизиты получателя, замораживает денежные средства в размере суммы предстоящего платежа и передает на сервер системы тикет, назначение и сумму платежа, затем сервер системы передает тикет, назначение и сумму информационной системе получателя платежа. Затем получатель платежа проверяет тикет, сумму, статус заказа, и передает подтверждение на прием средств серверу системы, затем сервер системы анализирует ответ получателя и передает его сторонней платежной системе. Затем сторонняя платежная система в случае подтверждения переводит деньги и сообщает об этом плательщику. Помимо возможности контроля и отмены транзакции на уровне сторонней платежной системы (например, банка) - по причине отсутствия средств и на уровне сервера системы - по причине несовпадения идентификатора, полученного системой с адресом и наименованием, что может говорить о подмене QR-кода, появляется возможность валидации данных и отмены на уровне получателя платежа, например, несоответствия статуса заказа. Кроме того, становится обоснованной отмена платежа на уровне плательщика, если необходимо, поскольку он получает данные (наименование точки продаж, адрес точки продаж, назначение, сумму платежа) по которым может судить о правильности указания получателя платежа.
Таким образом, повышается безопасность электронных платежей, а также универсальность использования сторонних платежных систем, становится более надежной процедура контроля для получателей платежей.
Отличия от прототипа:
Во-первых, поскольку наименование получателя платежа не уникально, кроме того, у одного получателя может быть несколько точек, добавление в QR-код адреса точки продаж, (а для интернет-магазинов - URL), включенного в систему, (дополнительно подтвержденный, например, с помощью геолокации), сочетание наименование + адрес точки продаж, отражаемое на одном из этапов валидации данных, позволит плательщику проконтролировать соответствие получателя тому, которому он адресует платеж. Таким образом, плательщик, считав QR-код при помощи клиентского устройства, например, смартфона, может идентифицировать, кому платит, и в случае сомнения, отказаться от транзакции. Кроме того, валидация идентификационных данных получателя платежа проводится сервером системы и в случае успеха, т.е. установления соответствия данной точке продаж идентификатора + наименования + адреса, передает подтверждение сторонней платежной системе (например, в банк). Т.о. включение в матричный штрихкод адреса точки продаж повышает уровень защиты и повышает безопасность платежной операции.
Во-вторых, у прототипа получатель платежа формирует идентификатор операции, который включается в матричный штрихкод. Этого недостаточно для безопасности платежа, поскольку обычный нешифрованный уникальный номер операции, формируемый платежными системами при обычной транзакции, может быть предсказуем при систематическом обращении к одному и тому же получателю платежа и простым увеличением номера выдан за оплату, т.е. не защищает получателя платежа от обмана. В заявляемом способе матричный штрихкод генерируется информационной системой получателя платежа и создается на основе идентификатора точки продаж, наименования точки продаж, адреса точки продаж (обязательные данные), тикета и опционально сумма, назначение платежа, при помощи программного обеспечения и библиотеки, используемой информационной системой получателя платежа. Тикет формируется информационной системой продавца (получателя платежа), либо шифрофункцией на основе уникальных данных операции (номер, время, сумма) или генератором случайных чисел, является уникальным в информационной системе получателя платежа и сопоставлен однозначно с конкретной покупкой, что повышает безопасность.
В-третьих, у прототипа платеж осуществлялся на предпоследнем этапе, после чего система еще извещала получателя платежа о проведенном платеже, когда уже отмена невозможна. Это для повышения безопасности бесполезный признак. В заявляемом способе получатель может отказаться от получения платежа до того как банк перевел деньги. То есть, сервер системы анализирует ответ получателя платежа и передает его сторонней платежной системе (в банк), а сторонняя платежная система в случае подтверждения переводит деньги и сообщает об этом плательщику, что повышает безопасность платежа.
Таким образом валидация, то есть подтверждение истинности данных осуществляется на трех уровнях: когда плательщик сверяет сумму, адрес, наименование; когда сторонняя платежная система (банк) сверяет сумму, реквизиты плательщика, реквизиты получателя, когда сервер системы сверяет идентификатор точки продаж с одной стороны и адрес+наименование точки продаж с другой, и когда получатель платежа сверяет тикет, статус заказа и сумму платежа.
Технический результат заявляемого способа заключается в повышении безопасности платежей при осуществлении электронных платежей.
Технический результат достигается способом, включающим то, что получатель платежа регистрируется на сайте сервера системы, вводит характеризующие его данные и получает личный идентификатор в виде графического файла с изображением матричного штрихкода, который отображается (напечатан на бумажном носителе, отображен проецированием, голографически или на дисплее); затем плательщик с помощью клиентского устройства считывает изображение матричного штрихкода, из которого получает данные характеризующие получателя, верифицирует их, вводит сумму оплаты и подтверждает платеж; затем сторонняя платежная система (например, банк) отправляет идентификатор операции серверу системы по каналам связи, сервер системы верифицирует данные и возвращает платежные реквизиты сторонней платежной системе; сторонняя платежная система осуществляет перевод средств и сообщает об этом серверу системы;
отличающийся тем, что получатель регистрирует на сервере системы требуемое количество реквизитов, создает требуемое количество точек продаж (или пользуется персональной по умолчанию), связывает реквизиты с точками продаж, затем получатель на каждую операцию генерирует QR-код содержащий идентификатор точки продаж, наименование точки продаж, адрес точки продаж, тикет, назначение платежа (опционально), сумма (опционально), при этом идентификатор, наименование и адрес должны совпадать с регистрируемыми получателем на сервере системы, плательщик при считывании QR-кода убеждается в правильности адресата платежа по демонстрируемым ему наименованию и адресу, в случае необходимости (если они не указаны в QR-коде) вводит сумму, назначение, затем отправляет введенные данные и данные из QR-кода сторонней платежной системе, сторонняя платежная система проверяет счет плательщика, затем сторонняя платежная система передает на сервер системы идентификатор, адрес, наименование, затем сервер системы проверяет соответствие идентификатора и адреса с наименованием получателя, и если данные подтверждаются, то сервер системы возвращает сторонней платежной системе реквизиты получателя, которая проверяет реквизиты получателя и резервирует денежные средства в размере суммы платежа, передает серверу системы тикет, сумму и назначение платежа, затем сервер системы передает тикет, сумму и назначение платежа информационной системе получателя платежа, затем получатель проверяет тикет, сумму, назначение платежа, статус заказа, и передает подтверждение на прием средств серверу системы, сервер системы анализирует ответ получателя и передает его сторонней платежной системе, а сторонняя платежная система в случае подтверждения переводит деньги и сообщает об этом плательщику. Если получатель не имеет информационной системы, то тикет равен нулю, при этом QR-код является статичным и содержит идентификатор точки продаж, адрес точки продаж, наименование точки продаж. Если получателем выступает интернет-магазин в качестве адреса местонахождения получателя используется единообразный локатор URL. Как частный случай, добавление в QR-код адреса точки продаж, включенной в систему, дополнительно подтверждается с помощью геолокации. Другой частный случай, в дополнение к матричному штрихкоду информация отображается буквенно-цифровым способом, при этом плательщик вводит информацию вручную в программное обеспечение сторонней платежной системы, интегрированной с системой способа.
Преимущества данного способа получения платежными системами реквизитов получателя платежа:
- Сервер системы не выполняет функций платежной системы и, следовательно, не хранит персональных и секретных данных плательщика, вместо этого он предоставляет сервис по предоставлению платежных реквизитов получателя любым сторонним платежным системам. В результате удается избежать опасного дублирования конфиденциальных данных в нескольких системах.
- Из предыдущего преимущества следует, что любая платежная сторонняя система, работающая с любыми денежными средствами, включая электронные кошельки, путем минимальной доработки своего программного обеспечения, без каких-либо действий по интеграции с получателями платежей, сможет сразу начать работать со всеми зарегистрированными на сервере системы продавцами. При этом покупателям достаточно будет простого обновления версии программного обеспечения на своих клиентских устройствах.
- Получателям платежей для работы с системой и получения платежей на свой счет достаточно зарегистрироваться на сервере системы и получить матричный штрихкод для дальнейшего представления покупателю. Даже при отсутствии собственной информационной системы для использования способа достаточно распечатать полученный матричный штрихкод, что упрощает и снижает затраты на внедрение.
Сущность описанного способа получения платежными системами реквизитов получателя платежа поясняется изображением на фигуре.
Фигура - Способ получения платежными системами реквизитов получателя платежа, где
СС - Сервер системы,
ПР - Получатель (продавец);
МК - Матричный штрих код;
КУ - Клиентское устройство;
ПС - Сторонняя платежная система (например, банк);
ПЛ - Плательщик (покупатель, пользователь);
1 - Считывание матричного штрих кода;
2 - Ввод данных плательщиком, валидация данных и подтверждение платежа;
3 - Передача значения матричного штрих кода и данных введенных плательщиком;
4 - Передача идентификатора, адреса и наименования точки продаж;
5 - Передача реквизитов получателя платежа;
6 - Передача тикета, суммы и назначения платежа;
7 - Передача тикета, суммы и назначения платежа;
8 - Передача подтверждения готовности принять платеж;
9 - Передача подтверждения готовности получателя принять платеж;
10 - Передача сообщения об успешном платеже.
Пример осуществления.
- Получатель ПР регистрирует на сервере системы СС требуемое количество реквизитов, создает требуемое количество точек продаж, связывает реквизиты с точками продаж.
- Получатель ПР на каждую операцию генерирует QR-код (МК), содержащий идентификатор точки продаж, наименование получателя, адрес, тикет - опционально (если у получателя нет информационной системы (ИС), то тикет имеет нулевое значение, т.е. равен нулю), назначение платежа - опционально, сумма - опционально. При этом наименование и адрес точки продаж должны совпадать с регистрируемыми на сервере системы СС.
- Плательщик ПЛ считывает (1) QR-код, убеждается в правильности адресата платежа по демонстрируемым ему наименованию и адресу точки продаж, в случае необходимости (если они не указаны в QR-коде) вводит (2) сумму, назначение. Отправляет (3) данные из QR-кода и введенные им сторонней платежной системе ПС.
- Сторонняя платежная система ПС проверяет не заморожен ли счет плательщика, достаточно ли денег на счету плательщика. Если подтверждение есть, то сторонняя платежная система ПС передает (4) в систему идентификатор, адрес, наименование точки продаж.
- Сервер системы СС проверяет соответствие идентификатора и адрес+наименование точки продаж. Если подтверждение есть, то сервер системы СС возвращает (5) сторонней платежной системе ПС реквизиты получателя платежа ПР.
- Сторонняя платежная система ПС проверяет реквизиты получателя платежа ПР. Если информация подтверждается, то замораживает денежные средства в размере суммы предстоящего платежа и передает (6) серверу системы СС тикет и сумму.
- Сервер системы СС передает (7) тикет и сумму информационной системе получателя платежа ПР.
- Получатель платежа ПР проверяет тикет, сумму, статус заказа. Если сведения соответствуют имеющимся в его информационной системе, то передает подтверждение на прием средств (8) серверу системы СС.
- Сервер системы СС анализирует ответ получателя и передает сторонней платежной системе ПС (9).
- Сторонняя платежная система ПС в случае подтверждения переводит деньги и сообщает об этом плательщику (10).
В заявляемом способе получения платежными системами реквизитов получателя платежа участвуют следующие элементы:
- расположенный в Интернет сервер системы способа с программным обеспечением и базой данных;
- получатель платежа (продавец), который зарегистрировался на сервере системы, ввел свои платежные реквизиты, адрес и наименование точки продаж (нескольких точек продаж) и в дальнейшем демонстрирует плательщику (покупателю) изображение матричного штрихкода;
- матричный штрихкод, содержащий информацию об идентификаторе, наименовании и адресе, точки продаж;
- клиентское устройство в виде смартфона, имеющего фотокамеру, стороннее мобильное приложение (например, мобильное приложение Сбербанк Онлайн) и доступ в Интернет;
- сторонняя платежная система (например, система Сбербанк Онлайн) с которой взаимодействует мобильное приложение смартфона;
- плательщик (покупатель), владеющий смартфоном и желающий совершить покупку.