Данное техническое решение относится к информационным способам и системам в вычислительной технике, а именно к способам и системам передачи права оплаты товаров или услуг сторонним плательщикам.

УРОВЕНЬ ТЕХНИКИ

В настоящее время у покупателя во время совершения онлайн оплаты товара или услуги может возникнуть ситуация, когда не хватает средств на расчетном счете или они закончились. В таком случае обычно приходиться отказываться от покупки, что может повлечь за собой отсутствие товара или услуги при пополнении денежных средств через какое-то время.

Существуют ситуации, когда некоторые категории пользователей (например, дети) не имеют доступа к кредитным картам/расчетным счетам и возможность осуществления покупок становится для них ограниченной и проблематичной.

Из уровня техники известно техническое решение, описанное в патенте США US 9355394 В2 "Systems and Methods of Aggregating Split Payments Using a Settlement Ecosystem", дата публикации 31.05.2016, правообладатель Visa International Service Association. Данное техническое решение предоставляет возможность разделить группе людей оплату за какое-либо действие или событие, например, совместно оплатить поход в ресторан, аренду автомобиля и собрать деньги на подарок. Первоначально человек сам может оплатить товар или услугу посредством, например, кредитной или дебетовой карты, а потом урегулировать финансовые отношения с другими участниками группы, используя средства, описанные в изобретении.

Данное решение требует для задачи привлечения к оплате третьих лиц хранение платежных реквизитов покупателей, к которым могут получить доступ мошенники, причем повышает нагрузку на хранение данных в системе.

СУЩНОСТЬ

Данное техническое решение решает существующие в уровне технике проблемы делегирования возможности оплаты стороннему плательщику сформированного покупателем заказа.

Способ передачи права оплаты товаров или услуг сторонним плательщикам, характеризующийся тем, что:

получают от покупателя запрос на оплату сформированного заказа за счет средств другого плательщика; получают данные, по крайней мере, одного плательщика; формируют для, по крайней мере, одного плательщика ссылку на оплату сформированного покупателем заказа, отправляют, по крайней мере, одному плательщику информацию о заказе, сформированную ссылку для оплаты сформированного покупателем заказа; отображают плательщику интерфейс оплаты заказа, сделанного покупателем без необходимости авторизации и/или идентификации. В некоторых вариантах реализации данные плательщика включают, по крайней мере, ФИО и номер телефона.

В некоторых вариантах реализации дополнительно производят идентификацию и/или авторизацию покупателя, направившего запрос на оплату корзины с покупками;

В некоторых вариантах реализации данные плательщика включают, по крайней мере, ФИО и e-mail.

В некоторых вариантах реализации отправка плательщикам информации о заказе осуществляется посредством sms или mms.

В некоторых вариантах реализации отправка плательщикам информации о заказе осуществляется посредством на аккаунт электронного мессенджера, связанного с номером телефона плательщика.

В некоторых вариантах реализации отправка плательщикам информации о заказе осуществляется посредством e-mail.

В некоторых вариантах реализации информация о заказе включает текст описания заказа и/или комментарии покупателя, товарные позиции заказа.

КРАТКОЕ ОПИСАНИЕ ЧЕРТЕЖЕЙ

Фиг. 1 - концептуальная схема взаимодействия устройств согласно первому варианту реализации способа передачи права оплаты товаров или услуг сторонним плательщикам.

Фиг. 2 - концептуальная схема взаимодействия устройств согласно второму варианту реализации способа передачи права оплаты товаров или услуг сторонним плательщикам.

Фиг. 3А - внешний вид формы авторизации и идентификации покупателя.

Фиг. 3Б - внешний вид формы авторизации и идентификации покупателя с полем ввода кода авторизации.

Фиг. 4 - внешний вид формы ввода плательщиков.

Фиг. 5 - внешний вид интерфейса описания заказа покупателя.

Фиг. 6 - блок-схема алгоритма передачи права оплаты товаров или услуг сторонним плательщикам.

Фиг. 7 - схема работы интернет-магазина с платежным шлюзом.

ПОДРОБНОЕ ОПИСАНИЕ

Ниже будут описаны понятия и определения, необходимые для подробного раскрытия осуществляемого технического решения.

Техническое решение может быть реализовано в виде распределенной компьютерной системы.

В данном решении под системой подразумевается компьютерная система, ЭВМ (электронно-вычислительная машина), ЧПУ (числовое программное управление), ПЛК (программируемый логический контроллер), компьютеризированные системы управления и любые другие устройства, способные выполнять заданную, четко определенную последовательность операций (действий, инструкций).

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

Устройство обработки команд считывает и выполняет машинные инструкции (программы) с одного или более устройства хранения данных. В роли устройства хранения данных могут выступать, но, не ограничиваясь, жесткие диски (HDD), флеш-память, ПЗУ (постоянное запоминающее устройство), твердотельные накопители (SSD), оптические носители (CD, DVD и т.п.).

Программа - последовательность инструкций, предназначенных для исполнения устройством управления вычислительной машины или устройством обработки команд.

Покупатель - физическое или юридическое лицо, осуществляющее заказ товара или услуги на онлайн ресурсе и являющееся приобретателем товара или услуги.

Плательщик - физическое или юридическое лицо, осуществляющее оплату за товар или услугу, которому в настоящем техническом решении делегирует оплату покупатель.

Платежная группа - группа участников процесса совершения покупки, созданная покупателем в момент приглашения плательщиков к оплате корзины с товарами или услугами в интерфейсе решения, установленного на сайте-интеграторе, также платежную можно создать в интерфейсе личного кабинета участника на стороне решения до того, как покупателем будет инициирован запрос на оплату на стороне любого сайта-интегратора решения

Интернет-магазин - сайт, торгующий товарами или услугами посредством сети Интернет. Позволяет покупателям онлайн, в своем браузере или через мобильное приложение, сформировать заказ на покупку, выбрать способ оплаты и доставки заказа, оплатить заказ.

Корзина - в интернет-магазинах - временное хранилище выбранных товаров или услуг перед их заказом.

Платежный шлюз - аппаратно-программный комплекс, который позволяет автоматизировать процесс приема платежей в Интернете. Платежный шлюз разрабатывается платежной системой, которая и определяет его спецификацию.

Совершая покупки в интернет-магазине или мобильном приложении, покупатель на устройстве (102) добавляет покупаемые товары в корзину. После того, как все необходимые товары выбраны и добавлены в корзину происходит процесс оформления заказа и его оплаты.

В некоторых вариантах реализации информация о товарах в корзине хранится на устройстве покупателя (102). В некоторых вариантах реализации информация о товарах в корзине хранится на сервере (103).

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

В некоторых вариантах реализации (здесь и далее по тексту) отображение интерфейса включает следующие шаги: сервер (103) формирует представление страницы, которое отправляется на устройство покупателя (102), затем устройство покупателя (102) получает сформированное представление и производит его отображение на экране.

В некоторых вариантах реализации представление страницы формируется посредством html (xhtml) и/или css и/или js.

В некоторых вариантах реализации представление страницы формируется посредством xml.

В некоторых вариантах реализации представление интерфейса уже сформировано на устройстве покупателя (102) и отображается согласно логике программного обеспечения, через которое осуществляет покупку покупатель. При отображении интерфейса может осуществляться взаимодействие с сервером (103) для получения необходимой для отображения информации.

При выборе покупателем на устройстве (102) данной опции оплаты, на сервере

(103) создается слепок сформированного заказа, и сохраняется в базе данных

(104). При этом данному слепку сформированного заказа присваивается уникальный идентификатор order_id.

В некоторых вариантах реализаций опция оплаты может быть выполнена в виде кнопки или ссылки.

В некоторых вариантах реализации слепок сформированного заказа создается на этапах, предшествующих отображению интерфейса оплаты.

В некоторых вариантах реализации слепок сформированного заказа создается при формировании элементов интерфейса, отвечающих за выбор данной опции оплаты (за счет третьих лиц-плательщиков).

В некоторых вариантах реализации уникальный идентификатор представляет собой числовое значение.

В некоторых вариантах реализации уникальный идентификатор представляет собой алфавитно-цифровую последовательность.

В некоторых вариантах реализации алфавитно-цифровая последовательность представляет собой тип GUID или Uniqueidentifier.

В некоторых вариантах реализации слепок заказа включает некоторые (одно или более) из указанных данных: номер заказа (OrderNumber), общая сумма заказа (OrderPrice), код валюты заказа (OrrderCurrency), имя покупателя (UserName), номер телефона покупателя (UserPhone), адрес электронной почты покупателя (UserEmail), список объектов-позиций (OrderPositions), содержащих, по крайней мере следующие поля: абсолютные ссылки на изображения выбранных позиций (PreviewLink), названия позиций (Title), количество товара в позиции (Quantity), цена за единицу товара в позиции (Price).

В некоторых вариантах реализации информация о заказе хранится в памяти устройства покупателя (102), затем, при выборе покупателем оплаты за счет средств третьих лиц-плательщиков, эта информация передается на сервер (103), который создает слепок заказа и сохраняет эту информацию в базу данных (104).

В некоторых вариантах реализации информация о заказе хранится в памяти сервера (103). При выборе покупателем оплаты за счет средств третьих лиц-плательщиков, устройство покупателя (102) отправляет запрос серверу (103), который создает слепок заказа и сохраняет эту информацию в базу данных (104).

В некоторых вариантах реализации уникальный идентификатор order_id генерируется на сервере (103).

В некоторых вариантах реализации уникальный идентификатор order_id генерируется базой данных (104) при добавлении новой записи.

Далее начинается процесс авторизации и идентификации покупателя. При авторизации покупателю на устройстве (102) отображается интерфейс идентификации и авторизации, содержащий данные, которые покупатель должен ввести для идентификации и авторизации.

В некоторых вариантах реализации, интерфейс авторизации представляет собой форму (фиг 3А), которая содержит, по крайней мере, поля имя (301) и номер телефона покупателя (302).

В некоторых вариантах реализации, интерфейс авторизации представляет собой форму, которая содержит, по крайней мере, поля имя и e-mail покупателя.

После ввода данных покупателя на устройстве (102), они отправляются на сервер (103). Затем покупателю на устройстве (102) отображается интерфейс ввода кода авторизации.

В некоторых вариантах реализации интерфейс авторизации содержит кнопку (303), при помощи которой данные покупателя отправляются на сервер (103).

Сервер (103) генерирует код авторизации (auth_code) и отправляет его покупателю на указанный им номер телефона. Покупатель, получив код авторизации, вводит его (auth_code) на устройстве (102) (фиг 3Б), после чего введенный код отправляется на сервер (103). Сервер (103) получив введенный покупателем код авторизации, сравнивает его с отправленным покупателю. Если оба кода совпали, покупатель авторизовывается, иначе происходит отказ в авторизации. После успешной авторизации покупателя, сформированный заказ связывается с идентификатором покупателя user_id, определенном в процессе авторизации.

В некоторых вариантах реализации интерфейс ввода кода авторизации содержит, по крайней мере, поля имя (301), номер телефона покупателя (302), поле для кода авторизации (304).

В некоторых вариантах реализации, если покупатель в течение заранее заданного времени не направляет на сервер (103) код авторизации, то данный код для него аннулируется и ему высылается новый.

В некоторых вариантах реализации интерфейс ввода кода авторизации содержит элемент (305), по нажатию на который на сервер (103) отправляется запрос на повторное отправление кода авторизации.

В некоторых вариантах реализации код авторизации представляет собой последовательность цифр и/или букв.

Далее покупателю на устройстве (102) отображается интерфейс (фиг. 4) ввода новых или выбора введенных ранее данных о третьих лицах - плательщиках (интерфейс ввода плательщиков), которым будет предложено произвести оплату заказа.

В некоторых вариантах реализации данные о плательщиках включают имя (403, 405), номер телефона (404, 406). Интерфейс может включать поля для ввода, по крайней мере, одного плательщика.

В некоторых вариантах реализации данные о плательщиках включают имя, номер телефона, название платежной группы (402 или 401).

В некоторых вариантах реализации интерфейс ввода данных о плательщиках содержит элемент выбора ранее созданных покупателем групп плательщиков. При этом, группы загружаются сервером (103) из базы данных (104).

После ввода данных на устройстве покупателя (102), происходит валидация введенных данных. При успешной валидации введенных данных создает контекст авторизации, генерируется уникальный идентификатор контекста авторизации auth_context_id, который связывается с плательщиками и идентификатором заказа order_id.

В некоторых вариантах реализации валидация данных включает проверку данных на соответствие их некоторому формату. Например, соответствие введенного e-mail разрешенному формату электронной почты (RFC 2822).

В некоторых вариантах реализации идентификаторы связываются путем создания записи в ОЗУ или базе данных (104). В качестве примера может быть создание записи содержащей поля auth_context_id, payer_id (плательщик), order_id.

Затем на указанные номера телефонов (403, 406) и/или e-mail плательщиков отправляется информация о заказе сделанным покупателем, со ссылкой на оплату данного заказа.

В некоторых вариантах реализации отправка информации о заказе на номер телефона осуществляется посредством sms, mms.

В некоторых вариантах реализации отправка информации о заказе на номер телефона осуществляется на связанный с данным номером аккаунт электронного мессенджера.

В некоторых вариантах реализации при отправке информации о заказе плательщику сервер (103) определяет связанные с телефонным номером плательщика аккаунты в электронных мессенджерах (viber, telegram, whatsapp и д.р) и осуществляет отсылку информации на, по крайней мере, один связанный аккаунт электронного мессенджера.

В некоторых вариантах реализации определение связанных с номером аккаунтов осуществляется путем использования API данных мессенджеров.

В некоторых вариантах реализации валидация введенных данных происходит на устройстве покупателя (102).

В некоторых вариантах реализации валидация введенных данных происходит на сервере (103), при этом, введенные на устройстве (102) данные о плательщиках отправляются на сервер (103), где происходит их валидация.

В некоторых вариантах реализации отправка информации о заказе покупателя со ссылкой на оплату происходит на устройстве покупателя (102).

В некоторых вариантах реализации при отправке информации о заказе покупателя со ссылкой на оплату на устройстве покупателя (102) выполняются следующие шаги:

- генерируется описание заказа покупателя,

- на сервер (103) отправляется запрос формирования, по крайней мере, одной уникальной ссылки для оплаты заказа плательщиком

- сервер (103), получив данный запрос, генерирует, по крайней мере, одну уникальную ссылку для оплаты заказа данным плательщиком pay_link, указывающую на сервер, при этом, ссылка связывает контекст авторизации auth_context_id, идентификатор заказа order_id и плательщика

- отправляют, по крайней мере, одну ссылку pay_link на устройство покупателя (102)

- получают на устройстве покупателя (102), по крайней мере, одну сформированную ссылку pay_link,

- отправляют с устройства покупателя (102) сгенерированное описание заказа и ссылку pay_link, по крайней мере, одному плательщику.

В некоторых вариантах реализации отправка информации о заказе покупателя со ссылкой на оплату происходит на сервере.

В некоторых вариантах реализации при отправке информации о заказе покупателя со ссылкой на оплату на сервере (103) выполняются следующие шаги:

- сервер (103) на основании информации о товарах в заказе, генерирует описание заказа покупателя,

- сервер (103) генерирует, по крайней мере, одну уникальную ссылку для оплаты заказа данным плательщиком pay_link, указывающую на сервер (103), при этом, ссылка связывает контекст авторизации auth_context_id, идентификатор заказа order_id и плательщика

- сервер (103) отправляет сгенерированное описание заказа и ссылку pay_link, по крайней мере, одному плательщику используя номер его телефона или e-mail.

В некоторых вариантах реализации генерация ссылки включает следующие шаги:

- Генерируют на сервере (103) уникальный идентификатор pay_code;

- Связывают на сервере (103) идентификатор pay_code с идентификатором контекста авторизации auth_context_id, идентификатором заказа order_id.

- Формируют на сервере (103) ссылку, указывающую на сервер (103), в одном из параметров которой передается значение pay_code.

В качестве примера ссылки может быть http://web-server.com/param1={pav_code} или http://web-server.com/param1/{pay_code}

Где вместо {pay_code} подставляется конкретное значение. В качестве указания на сервер используется URI web-server.com, который указывает на фактический адрес сервера (103).

Плательщики, указанные покупателем, получают информацию о заказе на устройстве (фиг. 1, 105N или 105М). Если информация отсылалась на номер телефона плательщика, то полученное сообщение содержит краткую информацию о заказе и ссылку на страницу с полным описанием заказа и опциями отказа и подтверждения оплаты заказа покупателя. При переходе по ссылке плательщику отображается интерфейс информации о заказе (фиг. 5). Если информация отсылалась на e-mail плательщика, то сообщение содержит информацию о заказе, опции отказа и подтверждения оплаты заказа покупателя.

В некоторых вариантах реализации интерфейс информации о заказе содержит, по крайней мере, описание заказа и/или комментарии покупателя (501), позиции заказа (502).

В некоторых вариантах реализации, если информация отсылалась на связанный с номером телефона плательщика аккаунт электронного мессенджера, то сообщение содержит информацию о заказе, опции отказа и подтверждения оплаты заказа плательщика.

В случае выражения согласия на оплату данного заказа (опция подтверждения оплаты) покупателя, плательщик (105N или 105М) перенаправляется на интерфейс оплаты заказа. В случае, если согласие на оплату осуществлено более чем одним плательщиком, то всем последующим плательщикам, кроме самого первого, отказывается в осуществлении оплаты.

В некоторых вариантах реализации согласие на оплату выражается путем нажатия на кнопку (504) «Выполнить» / «Подтвердить».

В некоторых вариантах реализации при отказе в осуществлении оплаты, плательщику отображается интерфейс отказа об оплате.

В некоторых вариантах реализации при обработке согласия на оплату сервер (103) определяет значение номер заказа OrderNumber, связанное с данным заказом, затем плательщику отображается интерфейс оплаты данного заказа покупателя для данного плательщика.

В некоторых вариантах реализации сервер (103) обрабатывает переход по ссылке pay_link плательщиком следующим образом:

- Получает параметры и их значение, указанные в ссылке, в т.ч. значение pay_code;

- Находит ассоциированные с данным значением pay_code значения идентификатора auth_context_id, идентификатора заказа order_id;

- Извлекает из базы данных (104) слепок заказа с указанным order_id;

- Извлекает значение OrderNumber;

- Производит необходимые настройки для проведения оплаты товара через платежный шлюз.

В некоторых вариантах реализации, под настройками платежного шлюза подразумевается осуществление последовательности действий (операций), необходимых для осуществления оплаты, например, регистрация заказа в платежном шлюзе.

При необходимости, плательщик в интерфейсе оплаты выбирает платежное средство. Когда выбор платежного средства осуществлен, плательщик вводит платежные данные и подтверждает оплату.

В некоторых вариантах реализации выбор платежного средства включает следующие опции - пластиковая карта, платежные системы, оплата через смс и др.

В некоторых вариантах реализации платежные данные включают номер карты, CVC/CVC2 код, срок действия карты, владельца (owner) карты.

После подтверждения оплаты плательщика, сервер (103) уведомляет покупателя об оплате его заказа плательщиком.

В случае невозможности завершить оплату заказа плательщиком, сервер (103) уведомляет покупателя об ошибке в оплате.

В некоторых вариантах реализации сервер (103) представляет собой виртуальный сервер.

В некоторых вариантах реализации сервер (103) является распределенной компьютерной системой, включающей 2 и более сервера.

В некоторых вариантах реализации база данных (104) представляет собой распределенную базу данных.

В некоторых вариантах реализации база данных (104) представляет собой key-value хранилище.

В некоторых вариантах реализации устройство покупателя (102) представляет собой персональный компьютер.

В некоторых вариантах реализации устройство покупателя (102) представляет собой смартфон или планшетный компьютер.

В некоторых вариантах реализации устройство покупателя представляет собой электронный терминал, расположенный в магазине. Терминал подключен к сети интернет и имеет возможность доступа к серверу (103).

В некоторых вариантах реализации связь между устройством 105 N и/или 105М и сервером (103) осуществляется посредством сети интернет. В некоторых вариантах реализации (фиг. 1) сервер (103) представляет собой web-сервер, на котором расположен интернет-магазин, в котором покупатель выбирает товары для заказа. Сервер (103) использует для хранения данных базу данных (104).

В некоторых вариантах реализации, для обмена данными между сервером (103) и устройством покупателя (102) и/или плательщика может использоваться протокол http/https и реализованные в них методы - get, post, put и др.

В некоторых вариантах реализации, для обмена данными между сервером (103) и устройством покупателя (102) и/или плательщика может использоваться протокол на базе XML или бинарный протокол.

В одном из вариантов реализации техническое решение может быть выполнено в виде отдельного сервиса, предоставляющего покупателю возможность оплаты заказа, находящегося в корзине, за счет средств третьих лиц - плательщиков.

Совершая покупки в интернет-магазине или мобильном приложении, покупатель добавляет покупаемые товары в корзину. После того, как все необходимые товары выбраны и добавлены в корзину происходит процесс оформления заказа и его оплаты.

Перед отображением интерфейса оплаты, заказ сформированный покупателем, сохраняется на сервере (203) и ему присваивается уникальный идентификатор OrderNumber.

В некоторых вариантах реализации заказ включает некоторые (одно или более) из указанных данных: номер заказа (OrderNumber), общая сумма заказа (OrderPrice), код валюты заказа (OrderCurrency), имя покупателя (UserName), номер телефона покупателя (UserPhone), адрес электронной почты покупателя (UserEmail), список объектов-позиций (OrderPositions), содержащих, по крайней мере следующие поля: абсолютные ссылки на изображения выбранных позиций (PreviewLinks), названия позиций (Title), количество товара в позиции (Quantity), цена за единицу товара в позиции (Price).

В некоторых вариантах реализации заказ сохраняется в базе данных (206).

В процессе оформления покупки, покупателю на устройстве (102) отображается интерфейс оплаты покупки с возможностью выбора оплаты товаров за счет средств третьих лиц - плательщиков.

При выборе покупателем на устройстве (102) данной опции, на сервере (203) формируется слепок заказа и передается на сервер (204). Получив слепок заказа, сервер (204) сохраняет его в базе данных (205). При этом данному слепку заказа присваивается уникальный идентификатор order_id.

В некоторых вариантах реализации опция оплаты может быть выполнена в виде кнопки или ссылки.

В некоторых вариантах реализации сервер (203) вместе со слепком заказа передает на сервер (204) токен, связанный с данным заказом. Токен сохраняется вместе со слепком заказа в базе данных (205). Токен, связанный с данным заказом, формируется на этапе оформления заказа.

В некоторых вариантах реализации слепок заказа формируется в виде js объекта, который отправляется на сервер при выборе покупателем опции оплаты покупки с возможностью выбора оплаты товаров за счет средств третьих лиц - плательщиков.

В некоторых вариантах реализации слепок заказа формируется в виде ассоциативных массивов, значения которых отправляются на сервер при выборе покупателем опции оплаты покупки с возможностью выбора оплаты товаров за счет средств третьих лиц - плательщиков.

В некоторых вариантах реализации уникальный идентификатор представляет собой числовое значение.

В некоторых вариантах реализации уникальный идентификатор представляет собой алфавитно-цифровую последовательность.

В некоторых вариантах реализации слепок заказа включает некоторые (одно или более) из указанных данных: номер заказа (OrderNumber), общая сумма заказа (OrderPrice), код валюты заказа(OrderCurrency), имя покупателя (UserName), номер телефона покупателя (UserPhone), адрес электронной почты покупателя (UserEmail), список объектов позиций (OrderPositions), абсолютные ссылки на изображения выбранных позиций (PreviewLinks), названия позиций (Title), количество товара в позиции (Quantity), цена за единицу товара в позиции (Price).

В некоторых вариантах реализации уникальный идентификатор order_id генерируется на сервере (204).

В некоторых вариантах реализации уникальный идентификатор order_id генерируется базой данных (205), при добавлении новой записи.

Далее сервер (204) запускает процесс авторизации и идентификации покупателя. При авторизации и идентификации покупателю на устройстве (102) отображается интерфейс идентификации и авторизации, содержащий данные, которые покупатель должен ввести для идентификации и авторизации.

В некоторых вариантах реализации интерфейс ввода кода авторизации содержит, по крайней мере, поля имя (301), номер телефона покупателя (302), поле для кода авторизации (304).

В некоторых вариантах реализации, если покупатель в течение заранее заданного времени не направляет на сервер (204) код авторизации, то данный код для него аннулируется и ему высылается новый.

В некоторых вариантах реализации интерфейс ввода кода авторизации содержит элемент (305), по нажатию на который на сервер (204) отправляется запрос на повторное отправление кода авторизации.

В некоторых вариантах реализации код авторизации представляет собой последовательность цифр и/или букв.

После ввода данных покупателя на устройстве (102), они отправляются на сервер (204). Затем покупателю на устройстве (102) отображается интерфейс ввода кода авторизации.

Сервер (204) генерирует код авторизации (auth_code) и отправляет его покупателю на указанный им номер телефона. Покупатель, получив код авторизации, вводит его (auth_code) на устройстве (102), после чего введенный код отправляется на сервер (204). Сервер (204) получив введенный покупателем код авторизации, сравнивает его с отправленным покупателю. Если оба кода совпали, покупатель авторизовывается, иначе происходит отказ в авторизации. После успешной авторизации покупателя, он связывается с идентификатором заказа order_id.

В некоторых вариантах реализации валидация данных включает проверку данных на соответствие их некоторому формату. Например, соответствие введенного e-mail разрешенному формату электронной почты (RFC 2822).

В некоторых вариантах реализации идентификаторы связываются путем создания записи в ОЗУ или базе данных (205). В качестве примера может быть создание записи содержащей поля auth_context_id, payer_id (плательщик), order_id.

Далее покупателю на устройстве (102) отображается интерфейс ввода новых или выбора введенных ранее данных о третьих лицах - плательщиках, которым будет предложено произвести оплату заказа.

В некоторых вариантах реализации данные о плательщиках включают имя, номер телефона.

В некоторых вариантах реализации данные о плательщиках включают имя, номер телефона, название платежной группы.

После ввода данных на устройстве покупателя (102), происходит валидация введенных данных. При успешной валидации введенных данных на сервере (204) создается контекст авторизации, генерируется код для упрощенной авторизации плательщиков, генерируется уникальный идентификатор контекста авторизации auth_context_id, который связывается с плательщиками и идентификатором заказа order_id. Затем на указанные номера телефонов или e-mail плательщиков сервер (204) отправляет информацию о заказе сделанным покупателем, со ссылкой на подтверждение оплаты данного заказа confirm_link.

В некоторых вариантах реализации валидация введенных данных происходит на устройстве покупателя (102).

В некоторых вариантах реализации валидация введенных данных происходит на сервере (204), при этом, введенные на устройстве (102) данные о плательщиках отправляются на сервер (204), где происходит их валидация.

В некоторых вариантах реализации отправка информации о заказе покупателя со ссылкой на подтверждение оплаты происходит на устройстве покупателя (102).

В некоторых вариантах реализации отправка информации о заказе покупателя со ссылкой на подтверждение оплаты происходит на сервере.

В некоторых вариантах реализации при отправке информации о заказе покупателя со ссылкой на подтверждение оплаты на сервере (204) выполняются следующие шаги:

- сервер (204) на основании информации о товарах в заказе, генерирует описание заказа покупателя,

- сервер (204) генерирует, по крайней мере, одну уникальную ссылку для подтверждения оплаты заказа данным плательщиком confirm_link, указывающую на сервер (204), при этом, ссылка содержит код для упрощенной авторизации плательщиков и связывает контекст авторизации auth_context_id, идентификатор заказа order_id и плательщика

- сервер (204) отправляет сгенерированное описание заказа и ссылку confirm-link, по крайней мере, одному плательщику используя номер его телефона или e-mail.

В некоторых вариантах реализации генерация ссылки confirm_link включает следующие шаги:

- Генерируют на сервере (204) уникальный идентификатор pay_code (код для упрощенной авторизации);

- Связывают на сервере (204) идентификатор pay_code с идентификатором контекста авторизации auth_context_id, идентификатором заказа order_id

- Формируют на сервере (204) ссылку, указывающую на сервер (204) в одном из параметров которой передается значение pay_code.

В качестве примера ссылки может быть, http://web-server.com/param1={pay_code} или http://web-server.com/param1/{pay_code}

Где вместо {pay_code} подставляется конкретное значение. В качестве указание на сервер используется URI web-server.com, который указывает на фактический адрес сервера (204).

Плательщики, указанные покупателем, получают информацию о заказе на устройстве (фиг. 2, 105N или 105М). Если информация отсылалась на номер телефона плательщика, то полученное сообщение содержит краткую информацию о заказе и ссылку на страницу с полным описанием заказа и опциями отказа и подтверждения оплаты заказа покупателя. При переходе по ссылке плательщику отображается интерфейс информации о заказе (фиг. 5). Если информация отсылалась на e-mail плательщика, то сообщение содержит информацию о заказе, опции отказа и подтверждения оплаты заказа покупателя.

В некоторых вариантах реализации интерфейс информации о заказе содержит, по крайней мере, описание заказа и/или комментарии покупателя (501), позиции заказа (502).

В некоторых вариантах реализации, если информация отсылалась на связанный с номер телефона плательщика аккаунт электронного мессенджера, то сообщение содержит информацию о заказе, опции отказа и подтверждения оплаты заказа плательщика.

В случае выражения согласия на оплату данного заказа покупателя, плательщик (105N или 105М здесь и далее не имеет принципиальной разницы какой именно пользователь осуществляет данное действие) перенаправляется сервером (204) на интерфейс оплаты заказа сформированный на сервере (203). В случае, если согласие на оплату осуществлено более чем одним плательщиком, то всем последующим плательщикам, кроме самого первого, отказывается в осуществлении оплаты.

В некоторых вариантах реализации для перенаправления сервером (204) плательщика на интерфейс оплаты заказа, сформированный на сервере (203), формируется ссылка redirect_link, указывающая на сервер (203) и содержащая значение номер заказа OrderNumber и опционально токен.

В некоторых вариантах реализации формат ссылки redirect_link задается заранее, при настройке. В качестве иллюстративного примера, при настройке может задаться адрес обработчика оплаты, такой как http://webshop.com/pay/order={OrderNumber}&token={Token}, где {OrderNumber} - значение номер заказа, a {Token} - токен.

В некоторых вариантах реализации согласие на оплату выражается путем нажатия на кнопку (504) «Выполнить» / «Подтвердить».

В некоторых вариантах реализации при отказе в осуществлении оплаты, плательщику отображается интерфейс отказа об оплате.

В некоторых вариантах реализации при обработке согласия на оплату сервер (204) определяет значение номер заказа OrderNumber, связанное с данным заказом, и отправляет эти данные серверу (203). После чего плательщику на устройстве (фиг. 2, 105N или 105М) отображается интерфейс оплаты данного заказа покупателя для данного плательщика.

В некоторых вариантах реализации при обработке согласия на оплату сервер (204) определяет токен, значение номер заказа OrderNumber, связанное с данным заказом, и отправляет эти данные серверу (203). После чего плательщику на устройстве (фиг. 2, 105N или 105М) отображается интерфейс оплаты данного заказа покупателя для данного плательщика. После получения данных, сервер (203) сверяет токен связанный с данным номером заказа OrderNumber и полученный токен, а также наличие сохраненного заказа с таким номером OrderNumber. В случае их несовпадения и/или отсутствия заказа с таким номером OrderNumber происходит отмена операции оплаты. После этого сервер (203) получает из базы данных (206) данные, связанные с заказом OrderNumber и производит необходимые настройки для проведения оплаты товара через платежный шлюз.

В некоторых вариантах реализации, под настройками платежного шлюза подразумевается осуществление последовательности действий (операций), необходимых для осуществления оплаты, например, регистрация заказа в платежном шлюзе.

При необходимости, плательщик на устройстве (фиг 2, 105N или 105М) в интерфейсе оплаты выбирает платежное средство. Когда выбор платежного средства осуществлен, плательщик вводит платежные данные и подтверждает оплату.

В некоторых вариантах реализации выбор платежного средства включает следующие опции - пластиковая карта, платежные системы, оплата через смс и др.

В некоторых вариантах реализации платежные данные включают номер карты, CVC/CVC2 код, срок действия карты, владельца (owner) карты.

После подтверждения оплаты плательщика, сервер (203) уведомляет покупателя об оплате его заказа плательщиком.

В случае невозможности завершить оплату заказа плательщиком, сервер (203) уведомляет покупателя об ошибке в оплате.

В некоторых вариантах реализации база данных (205) может представлять собой реляционную базу данных или key-value хранилище, или иерархическую базу данных.

В некоторых вариантах реализации база данных (205) располагается в ОЗУ сервера (204).

В некоторых вариантах реализации устройство покупателя (102) представляет собой персональный компьютер.

В некоторых вариантах реализации устройство покупателя (102) представляет собой смартфон или планшетный компьютер.

В некоторых вариантах реализации устройство покупателя представляет собой электронный терминал, расположенный в магазине. Терминал подключен к сети интернет и имеет возможность доступа к серверу (203).

В некоторых вариантах реализации связь между сервером (203) и сервером (204) осуществляется посредством сети интернет.

В некоторых вариантах реализации связь между устройством (105N) и/или 105М и сервером (204) или (203) осуществляется посредством сети интернет.

В некоторых вариантах реализации для связи сервера (203) и сервера (204) используется протокол http и/или https.

В некоторых вариантах реализации для связи сервера (203) и сервера (204) используется бинарный протокол.

В некоторых вариантах реализации (фиг. 2) сервер (203) представляет собой web-сервер, на котором расположен интернет-магазин, в котором покупатель выбирает товары для заказа. На сервере (204) располагается программное обеспечение, позволяющее производить оплату товаров покупателя за счет третьих лиц-плательщиков. Программное обеспечение сервера (204) использует базу данных (205) для хранения данных.

В некоторых вариантах реализации, для обмена данными между сервером (203) и устройством покупателя (102) может использоваться протокол http/https и реализованные в них методы - get, post, put и др.

В некоторых вариантах реализации, для обмена данными между сервером (203) или (204) и устройством плательщика (105N или 105М) может использоваться протокол http/https и реализованные в них методы - get, post, put и др.

В одном из вариантов реализации техническое решение может быть реализовано следующим образом. Совершая покупки в интернет-магазине или мобильном приложении, покупатель на устройстве (102) добавляет покупаемые товары в корзину. После того, как все необходимые товары выбраны и добавлены в корзину происходит процесс оформления заказа и его оплаты.

В некоторых вариантах реализации информация о товарах в корзине хранится на устройстве покупателя (102). В некоторых вариантах реализации информация о товарах в корзине хранится на сервере (103).

В процессе оформления покупки или при отображении сформированной корзины, покупателю на устройстве (102) отображается интерфейс оплаты покупки с возможностью выбора оплаты товаров за счет средств третьих лиц -плательщиков.

В некоторых вариантах реализации (здесь и далее по тексту) отображение интерфейса включает следующие шаги: сервер (103) формирует представление страницы, которое отправляется на устройство покупателя (102), затем устройство покупателя (102) получает сформированное представление и производит его отображение на экране.

В некоторых вариантах реализации представление страницы формируется посредством html (xhtml) и/или css и/или js.

В некоторых вариантах реализации представление страницы формируется посредством xml.

Покупатель, желая, чтобы его товар оплатили третьи лица-плательщики, вводит в интерфейсе данные о плательщиках и выбирает опцию оплаты за счет третьих лиц-плательщиков (интерфейс ввода плательщиков), которым будет предложено произвести оплату сформированного заказа.

При выборе покупателем на устройстве (102) данной опции оплаты, на сервере (103) создается слепок сформированного заказа, и сохраняется в базе данных (104). При этом данному слепку сформированного заказа присваивается уникальный идентификатор order_id.

В некоторых вариантах реализации слепок сформированного заказа создается на этапах, предшествующих отображению интерфейса оплаты.

В некоторых вариантах реализации слепок сформированного заказа создается при формировании элементов интерфейса, отвечающих за выбор данной опции оплаты (за счет третьих лиц-плательщиков).

В некоторых вариантах реализации уникальный идентификатор представляет собой числовое значение.

В некоторых вариантах реализации уникальный идентификатор представляет собой алфавитно-цифровую последовательность.

В некоторых вариантах реализации алфавитно-цифровая последовательность представляет собой тип GUID или Uniqueidentifier.

В некоторых вариантах реализации слепок заказа включает некоторые (одно или более) из указанных данных: номер заказа (OrderNumber), общая сумма заказа (OrderPrice), код валюты заказа (OrderCurrency), имя покупателя (UserName), номер телефона покупателя (UserPhone), адрес электронной почты покупателя (UserEmail), список объектов-позиций (OrderPositions), содержащих, по крайней мере следующие поля: абсолютные ссылки на изображения выбранных позиций (PreviewLink), названия позиций (Title), количество товара в позиции (Quantity), цена за единицу товара в позиции (Price).

В некоторых вариантах реализации информация о заказе хранится в памяти устройства покупателя (102), затем, при выборе покупателем оплаты за счет средств третьих лиц-плательщиков, эта информация передается на сервер (103), который создает слепок заказа и сохраняет эту информацию в базу данных (104).

В некоторых вариантах реализации информация о заказе хранится в памяти сервера (103). При выборе покупателем оплаты за счет средств третьих лиц-плательщиков, устройство покупателя (102) отправляет запрос серверу (103), который создает слепок заказа и сохраняет эту информацию в базу данных (104).

В некоторых вариантах реализации уникальный идентификатор order_id генерируется на сервере (103).

В некоторых вариантах реализации уникальный идентификатор order_id генерируется базой данных (104) при добавлении новой записи.

В некоторых вариантах реализации данные о плательщиках включают имя, номер телефона и/или e-mail. Интерфейс может включать поля для ввода, по крайней мере, одного плательщика.

В некоторых вариантах реализации данные о плательщиках включают имя, номер телефона и/или e-mail, название платежной группы.

В некоторых вариантах реализации интерфейс ввода данных о плательщиках содержит элемент выбора ранее созданных покупателем групп плательщиков. При этом, группы загружаются сервером (103) из базы данных (104).

После ввода данных на устройстве покупателя (102), происходит валидация введенных данных. При успешной валидации введенных данных создает контекст авторизации, генерируется уникальный идентификатор контекста авторизации auth_context_id, который связывается с плательщиками и идентификатором заказа order-id.

В некоторых вариантах реализации валидация данных включает проверку данных на соответствие их некоторому формату. Например, соответствие введенного e-mail разрешенному формату электронной почты (RFC 2822).

В некоторых вариантах реализации идентификаторы связываются путем создания записи в ОЗУ или базе данных (104). В качестве примера может быть создание записи содержащей поля auth_context_id, payer_id (плательщик), order_id.

Затем на указанные номера телефонов и/или e-mail плательщиков отправляется информация о заказе сделанным покупателем, со ссылкой на оплату данного заказа.