RU2646335C1 - Способ онлайн передачи права оплаты товаров или услуг сторонним плательщикам - Google Patents
Способ онлайн передачи права оплаты товаров или услуг сторонним плательщикам Download PDFInfo
- Publication number
- RU2646335C1 RU2646335C1 RU2016148462A RU2016148462A RU2646335C1 RU 2646335 C1 RU2646335 C1 RU 2646335C1 RU 2016148462 A RU2016148462 A RU 2016148462A RU 2016148462 A RU2016148462 A RU 2016148462A RU 2646335 C1 RU2646335 C1 RU 2646335C1
- Authority
- RU
- Russia
- Prior art keywords
- order
- server
- payer
- payment
- buyer
- Prior art date
Links
- 238000000034 method Methods 0.000 title claims abstract description 47
- 238000013475 authorization Methods 0.000 claims abstract description 87
- 238000012545 processing Methods 0.000 abstract description 13
- 230000000694 effects Effects 0.000 abstract description 7
- 239000000126 substance Substances 0.000 abstract 1
- 230000008569 process Effects 0.000 description 23
- 238000012790 confirmation Methods 0.000 description 21
- 238000010200 validation analysis Methods 0.000 description 18
- 230000009471 action Effects 0.000 description 9
- 238000004891 communication Methods 0.000 description 8
- 101150010802 CVC2 gene Proteins 0.000 description 6
- 238000013502 data validation Methods 0.000 description 5
- 238000010586 diagram Methods 0.000 description 4
- 230000003993 interaction Effects 0.000 description 4
- 238000013500 data storage Methods 0.000 description 2
- VYZAMTAEIAYCRO-UHFFFAOYSA-N Chromium Chemical compound [Cr] VYZAMTAEIAYCRO-UHFFFAOYSA-N 0.000 description 1
- 230000004931 aggregating effect Effects 0.000 description 1
- 238000003491 array Methods 0.000 description 1
- 230000008859 change Effects 0.000 description 1
- 238000005516 engineering process Methods 0.000 description 1
- 239000000284 extract Substances 0.000 description 1
- 238000012011 method of payment Methods 0.000 description 1
- 238000012986 modification Methods 0.000 description 1
- 230000004048 modification Effects 0.000 description 1
- 230000003287 optical effect Effects 0.000 description 1
- 239000007787 solid Substances 0.000 description 1
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q30/00—Commerce
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q20/00—Payment architectures, schemes or protocols
Landscapes
- Business, Economics & Management (AREA)
- Accounting & Taxation (AREA)
- Strategic Management (AREA)
- Physics & Mathematics (AREA)
- General Business, Economics & Management (AREA)
- General Physics & Mathematics (AREA)
- Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- Development Economics (AREA)
- Economics (AREA)
- Finance (AREA)
- Marketing (AREA)
- Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)
Abstract
Изобретение относится к способу онлайн передачи права оплаты товаров или услуг с устройства покупателя на устройства сторонних плательщиков. Технический результат заключается в автоматизации онлайн передачи права оплаты товаров или услуг. В способе получают на сервере от устройства покупателя запрос на оплату сформированного заказа за счет средств другого плательщика, формируют на сервере слепок заказа покупателя, присваивают слепку заказа идентификатор заказа и сохраняют слепок заказа в базе данных, производят авторизацию покупателя, оформляющего заказ через устройство покупателя, получают на сервере данные по крайней мере одного плательщика, от устройства покупателя, формируют на сервере для по крайней мере одного плательщика уникальную ссылку на оплату сформированного покупателем заказа, указывающую на сервер, при этом ссылка связывает контекст авторизации, идентификатор заказа, плательщика, сервер отправляет по крайней мере одному плательщику информацию о заказе, сформированную уникальную ссылку для оплаты сформированного покупателем заказа, при переходе по сформированной уникальной ссылке плательщику отображают на устройстве плательщика интерфейс оплаты заказа, сделанного покупателем без необходимости авторизации и/или идентификации. 6 з.п. ф-лы, 8 ил.
Description
Данное техническое решение относится к информационным способам и системам в вычислительной технике, а именно к способам и системам передачи права оплаты товаров или услуг сторонним плательщикам.
УРОВЕНЬ ТЕХНИКИ
В настоящее время у покупателя во время совершения онлайн оплаты товара или услуги может возникнуть ситуация, когда не хватает средств на расчетном счете или они закончились. В таком случае обычно приходиться отказываться от покупки, что может повлечь за собой отсутствие товара или услуги при пополнении денежных средств через какое-то время.
Существуют ситуации, когда некоторые категории пользователей (например, дети) не имеют доступа к кредитным картам/расчетным счетам и возможность осуществления покупок становится для них ограниченной и проблематичной.
Из уровня техники известно техническое решение, описанное в патенте США 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 плательщиков отправляется информация о заказе сделанным покупателем, со ссылкой на оплату данного заказа.
В некоторых вариантах реализации отправка информации о заказе на номер телефона осуществляется посредством 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={pay_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).
В некоторых вариантах реализации связь между устройством 105N и/или 105М и сервером (103) осуществляется посредством сети интернет. В некоторых вариантах реализации (фиг. 1) сервер (103) представляет собой web-сервер, на котором расположен интернет-магазин, в котором покупатель выбирает товары для заказа. Сервер (103) использует для хранения данных базу данных (104).
В некоторых вариантах реализации, для обмена данными между сервером (103) и устройством покупателя (102) и/или плательщика может использоваться протокол http/https и реализованные в них методы - get, post, put и др.
В некоторых вариантах реализации, для обмена данными между сервером (103) и устройством покупателя (102) и/или плательщика может использоваться протокол на базе XML или бинарный протокол.
В одном из вариантов реализации техническое решение может быть реализовано следующим образом. Совершая покупки в интернет-магазине или мобильном приложении, покупатель на устройстве (фиг. 1, 102) добавляет покупаемые товары в корзину. После того, как все необходимые товары выбраны и добавлены в корзину происходит процесс оформления заказа и его оплаты.
В некоторых вариантах реализации информация о товарах в корзине хранится на устройстве покупателя (фиг. 1, 102). В некоторых вариантах реализации информация о товарах в корзине хранится на сервере (фиг. 1, 103).
В процессе оформления покупки или при отображении сформированной корзины, покупателю на устройстве (фиг. 1, 102) отображается интерфейс оплаты покупки с возможностью выбора оплаты товаров за счет средств третьих лиц -плательщиков.
В некоторых вариантах реализации (здесь и далее по тексту) отображение интерфейса включает следующие шаги: сервер (фиг. 1, 103) формирует представление страницы, которое отправляется на устройство покупателя (102), затем устройство покупателя (фиг. 1, 102) получает сформированное представление и производит его отображение на экране.
В некоторых вариантах реализации представление страницы формируется посредством html (xhtml) и/или css и/или js.
В некоторых вариантах реализации представление страницы формируется посредством xml.
Покупатель, желая, чтобы его товар оплатили третьи лица-плательщики, вводит в интерфейсе данные о плательщиках и выбирает опцию оплаты за счет третьих лиц-плательщиков (интерфейс ввода плательщиков), которым будет предложено произвести оплату сформированного заказа.
В некоторых вариантах реализации данные о плательщиках включают имя, номер телефона и/или e-mail. Интерфейс может включать поля для ввода, по крайней мере, одного плательщика.
В некоторых вариантах реализации данные о плательщиках включают имя, номер телефона и/или e-mail, название платежной группы.
В некоторых вариантах реализации интерфейс ввода данных о плательщиках содержит элемент выбора ранее созданных покупателем групп плательщиков. При этом, группы загружаются сервером (фиг. 1, 103) из базы данных (фиг. 1,104).
После ввода данных на устройстве покупателя (фиг. 1, 102), происходит валидация введенных данных. При успешной валидации введенных данных создает контекст авторизации, генерируется уникальный идентификатор контекста авторизации auth_context_id, который связывается с плательщиками и идентификатором заказа CurrentOrder.
В некоторых вариантах реализации в качестве CurrentOrder используется номер заказа OrderNumber или любой другой идентификатор, позволяющий однозначно идентифицировать данный заказ.
В некоторых вариантах реализации валидация данных включает проверку данных на соответствие их некоторому формату. Например, соответствие введенного e-mail разрешенному формату электронной почты (RFC 2822).
В некоторых вариантах реализации идентификаторы связываются путем создания записи в ОЗУ или базе данных (фиг. 1, 104). В качестве примера может быть создание записи содержащей поля auth_context_id, payer_id (плательщик), CurrentOrder.
Затем на указанные номера телефонов и/или e-mail плательщиков отправляется информация о заказе сделанным покупателем, со ссылкой на оплату данного заказа.
В некоторых вариантах реализации отправка информации о заказе на номер телефона осуществляется посредством sms, mms.
В некоторых вариантах реализации отправка информации о заказе на номер телефона осуществляется на связанный с данным номером аккаунт электронного мессенджера.
В некоторых вариантах реализации при отправке информации о заказе плательщику сервер (103) определяет связанные с телефонным номером плательщика аккаунты в электронных мессенджерах (viber, telegram, whatsapp и д.р) и осуществляет отсылку информации на, по крайней мере, один связанный аккаунт электронного мессенджера.
В некоторых вариантах реализации определение связанных с номером аккаунтов осуществляется путем использования API данных мессенджеров.
В некоторых вариантах реализации валидация введенных данных происходит на устройстве покупателя (фиг. 1, 102).
В некоторых вариантах реализации валидация введенных данных происходит на сервере (фиг. 1, 103), при этом, введенные на устройстве (102) данные о плательщиках отправляются на сервер (фиг. 1, 103), где происходит их валидация.
В некоторых вариантах реализации отправка информации о заказе покупателя со ссылкой на оплату происходит на устройстве покупателя (фиг. 1, 102).
В некоторых вариантах реализации при отправке информации о заказе покупателя со ссылкой на оплату на устройстве покупателя (фиг. 1, 102) выполняются следующие шаги:
- генерируется описание заказа покупателя,
- на сервер (103) отправляется запрос формирования, по крайней мере, одной уникальной ссылки для оплаты заказа плательщиком
- сервер (103), получив данный запрос, генерирует, по крайней мере, одну уникальную ссылку для оплаты заказа данным плательщиком pay_link, указывающую на сервер, при этом, ссылка связывает контекст авторизации auth_context_id, идентификатор заказа CurrentOrder и плательщика;
- отправляют, по крайней мере, одну ссылку pay_link на устройство покупателя (102);
- получают на устройстве покупателя (102), по крайней мере, одну сформированную ссылку pay_link,
- отправляют с устройства покупателя (102) сгенерированное описание заказа и ссылку pay_link, по крайней мере, одному плательщику.
В некоторых вариантах реализации отправка информации о заказе покупателя со ссылкой на оплату происходит на сервере.
В некоторых вариантах реализации при отправке информации о заказе покупателя со ссылкой на оплату на сервере (103) выполняются следующие шаги:
- сервер (103) на основании информации о товарах в заказе, генерирует описание заказа покупателя,
- сервер (103) генерирует, по крайней мере, одну уникальную ссылку для оплаты заказа данным плательщиком pay_link, указывающую на сервер (103), при этом, ссылка связывает контекст авторизации auth_context_id, идентификатор заказа CurrentOrder и плательщика;
- сервер (103) отправляет сгенерированное описание заказа и ссылку pay_link, по крайней мере, одному плательщику используя номер его телефона или e-mail.
В некоторых вариантах реализации генерация ссылки включает следующие шаги:
- Генерируют на сервере (103) уникальный идентификатор pay_code;
- Связывают на сервере (103) идентификатор pay_code с идентификатором контекста авторизации auth_context_id, идентификатором заказа CurrentOrder.
- Формируют на сервере (103) ссылку, указывающую на сервер (103), в одном из параметров которой передается значение pay_code.
В качестве примера ссылки может быть, http://web-server.com/param1={pay_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, идентификатора заказа CurrentOrder;
- Извлекает из базы данных (104) слепок заказа с указанным CurrentOrder;
- Извлекает значение OrderNumber;
- Производит необходимые настройки для проведения оплаты товара через платежный шлюз.
В некоторых вариантах реализации, под настройками платежного шлюза подразумевается осуществление последовательности действий (операций), необходимых для осуществления оплаты, например, регистрация заказа в платежном шлюзе.
При необходимости, плательщик в интерфейсе оплаты выбирает платежное средство. Когда выбор платежного средства осуществлен, плательщик вводит платежные данные и подтверждает оплату.
В некоторых вариантах реализации выбор платежного средства включает следующие опции - пластиковая карта, платежные системы, оплата через смс и др.
В некоторых вариантах реализации платежные данные включают номер карты, CVC/CVC2 код, срок действия карты, владельца (owner) карты.
После подтверждения оплаты плательщика, сервер (103) уведомляет покупателя об оплате его заказа плательщиком.
В случае невозможности завершить оплату заказа плательщиком, сервер (103) уведомляет покупателя об ошибке в оплате.
В некоторых вариантах реализации сервер (103) представляет собой виртуальный сервер.
В некоторых вариантах реализации сервер (103) является распределенной компьютерной системой, включающей 2 и более сервера.
В некоторых вариантах реализации база данных (104) представляет собой распределенную базу данных.
В некоторых вариантах реализации база данных (104) представляет собой key-value хранилище.
В некоторых вариантах реализации устройство покупателя (102) представляет собой персональный компьютер.
В некоторых вариантах реализации устройство покупателя (102) представляет собой смартфон или планшетный компьютер.
В некоторых вариантах реализации устройство покупателя представляет собой электронный терминал, расположенный в магазине. Терминал подключен к сети интернет и имеет возможность доступа к серверу (103).
В некоторых вариантах реализации связь между устройством 105N и/или 105М и сервером (103) осуществляется посредством сети интернет. В некоторых вариантах реализации (фиг. 1) сервер (103) представляет собой web-сервер, на котором расположен интернет-магазин, в котором покупатель выбирает товары для заказа. Сервер (103) использует для хранения данных базу данных (104).
В некоторых вариантах реализации, для обмена данными между сервером (103) и устройством покупателя (102) и/или плательщика может использоваться протокол http/https и реализованные в них методы - get, post, put и др.
В некоторых вариантах реализации, для обмена данными между сервером (103) и устройством покупателя (102) и/или плательщика может использоваться протокол на базе XML или бинарный протокол.
В одном из вариантов реализации техническое решение может быть реализовано следующим образом. Совершая покупки в интернет-магазине или мобильном приложении, покупатель на устройстве (фиг. 1, 102) добавляет покупаемые товары в корзину. После того, как все необходимые товары выбраны и добавлены в корзину происходит процесс оформления заказа и его оплаты, при этом сформированному заказу задается идентификатор CurrentOrder.
В некоторых вариантах реализации информация о товарах в корзине хранится на устройстве покупателя (фиг. 1, 102). В некоторых вариантах реализации информация о товарах в корзине хранится на сервере (фиг. 1, 103).
В некоторых вариантах реализации в качестве CurrentOrder используется номер заказа OrderNumber или любой другой идентификатор, позволяющий однозначно идентифицировать данный заказ.
В процессе оформления покупки или при отображении сформированной корзины, покупателю на устройстве (102) отображается интерфейс оплаты покупки с возможностью выбора оплаты товаров за счет средств третьих лиц -плательщиков.
В некоторых вариантах реализации (здесь и далее по тексту) отображение интерфейса включает следующие шаги: сервер (фиг. 1, 103) формирует представление страницы, которое отправляется на устройство покупателя (фиг. 1, 102), затем устройство покупателя (фиг. 1, 102) получает сформированное представление и производит его отображение на экране.
В некоторых вариантах реализации представление страницы формируется посредством html (xhtml) и/или css и/или js.
В некоторых вариантах реализации представление страницы формируется посредством xml.
Покупатели, желая, чтобы ого товар оплатили третьи лица-плательщики, вводит в интерфейсе данные о плательщиках и выбирает опцию оплаты за счет третьих лиц-плательщиков (интерфейс ввода плательщиков), которым будет предложено произвести оплату сформированного заказа.
В некоторых вариантах реализации данные о плательщиках включают имя, номер телефона и/или e-mail. Интерфейс может включать поля для ввода, по крайней мере, одного плательщика.
В некоторых вариантах реализации данные о плательщиках включают имя, номер телефона и/или e-mail, название платежной группы.
В некоторых вариантах реализации интерфейс ввода данных о плательщиках содержит элемент выбора ранее созданных покупателем групп плательщиков. При этом, группы загружаются сервером (фиг. 1, 103) из базы данных (фиг. 1, 104).
После ввода данных на устройстве покупателя (фиг. 1, 102), происходит валидация введенных данных.
В некоторых вариантах реализации валидация данных включает проверку данных на соответствие их некоторому формату. Например, соответствие введенного e-mail разрешенному формату электронной почты (RFC 2822).
Затем на указанные номера телефонов и/или e-mail плательщиков отправляется информация о заказе сделанным покупателем, со ссылкой на оплату данного заказа.
В некоторых вариантах реализации отправка информации о заказе на номер телефона осуществляется посредством sms, mms.
В некоторых вариантах реализации отправка информации о заказе на номер телефона осуществляется на связанный с данным номером аккаунт электронного мессенджера.
В некоторых вариантах реализации при отправке информации о заказе плательщику сервер (103) определяет связанные с телефонным номером плательщика аккаунты в электронных мессенджерах (viber, telegram, whatsapp и д.р) и осуществляет отсылку информации на, по крайней мере, один связанный аккаунт электронного мессенджера.
В некоторых вариантах реализации определение связанных с номером аккаунтов осуществляется путем использования API данных мессенджеров.
В некоторых вариантах реализации валидация введенных данных происходит на устройстве покупателя (фиг. 1, 102).
В некоторых вариантах реализации валидация введенных данных происходит на сервере (фиг. 1, 103), при этом, введенные на устройстве (фиг. 1, 102) данные о плательщиках отправляются на сервер (фиг. 1, 103), где происходит их валидация.
В некоторых вариантах реализации отправка информации о заказе покупателя со ссылкой на оплату происходит на устройстве покупателя (102).
В некоторых вариантах реализации при отправке информации о заказе покупателя со ссылкой на оплату на устройстве покупателя (фиг. 1, 102) выполняются следующие шаги:
- генерируется описание заказа покупателя,
- на сервер (фиг. 1, 103) отправляется запрос формирования, по крайней мере, одной ссылки для оплаты заказа плательщиком,
- сервер (фиг. 1, 103), получив данный запрос, генерирует, по крайней мере, одну ссылку для оплаты заказа данным плательщиком pay_link, указывающую на сервер, при этом, ссылка содержит параметр CurrentOrder.
- отправляют, по крайней мере, одну ссылку pay_link на устройство покупателя (фиг. 1, 102)
- получают на устройстве покупателя (фиг. 1, 102), по крайней мере, одну сформированную ссылку pay_link,
- отправляют с устройства покупателя (фиг. 1, 102) сгенерированное описание заказа и ссылку pay_link, по крайней мере, одному плательщику.
В некоторых вариантах реализации отправка информации о заказе покупателя со ссылкой на оплату происходит на сервере.
В некоторых вариантах реализации при отправке информации о заказе покупателя со ссылкой на оплату на сервере (фиг. 1, 103) выполняются следующие шаги:
- сервер (103) на основании информации о товарах в заказе, генерирует описание заказа покупателя,
- сервер (103) генерирует, по крайней мере, одну ссылку для оплаты заказа данным плательщиком pay_link, указывающую на сервер (103), при этом, ссылка содержит параметр CurrentOrder.
- сервер (103) отправляет сгенерированное описание заказа и ссылку pay-link, по крайней мере, одному плательщику используя номер его телефона или e-mail.
Плательщики, указанные покупателем, получают информацию о заказе на устройстве (фиг. 1, 105N или 105М). Если информация отсылалась на номер телефона плательщика, то полученное сообщение содержит краткую информацию о заказе и ссылку на страницу с полным описанием заказа и опциями отказа и подтверждения оплаты заказа покупателя. При переходе по ссылке плательщику отображается интерфейс информации о заказе (фиг. 5). Если информация отсылалась на e-mail плательщика, то сообщение содержит информацию о заказе, опции отказа и подтверждения оплаты заказа покупателя.
В некоторых вариантах реализации интерфейс информации о заказе содержит, по крайней мере, описание заказа и/или комментарии покупателя (фиг. 5, 501), позиции заказа (502).
В некоторых вариантах реализации, если информация отсылалась на связанный с номером телефона плательщика аккаунт электронного мессенджера, то сообщение содержит информацию о заказе, опции отказа и подтверждения оплаты заказа плательщика.
В случае выражения согласия на оплату данного заказа (опция подтверждения оплаты) покупателя, плательщик (105N или 105М) перенаправляется на интерфейс оплаты заказа. В случае, если согласие на оплату осуществлено более чем одним плательщиком, то всем последующим плательщикам, кроме самого первого, отказывается в осуществлении оплаты.
В некоторых вариантах реализации согласие на оплату выражается путем нажатия на кнопку (504) «Выполнить» / «Подтвердить».
В некоторых вариантах реализации при отказе в осуществлении оплаты, плательщику отображается интерфейс отказа об оплате.
В некоторых вариантах реализации при обработке согласия на оплату сервер (103) определяет значение номер заказа CurrentOrder, связанное с данным заказом, затем плательщику отображается интерфейс оплаты данного заказа покупателя для данного плательщика.
В некоторых вариантах реализации сервер (103) обрабатывает переход по ссылке pay_link плательщиком следующим образом:
- Получает параметры и их значение, указанные в ссылке, в том числе CurrentOrder;
- Производит необходимые настройки для проведения оплаты товара через платежный шлюз.
В некоторых вариантах реализации, под настройками платежного шлюза подразумевается осуществление последовательности действий (операций), необходимых для осуществления оплаты, например, регистрация заказа в платежном шлюзе.
При необходимости, плательщик в интерфейсе оплаты выбирает платежное средство. Когда выбор платежного средства осуществлен, плательщик вводит платежные данные и подтверждает оплату.
В некоторых вариантах реализации выбор платежного средства включает следующие опции - пластиковая карта, платежные системы, оплата через смс и др.
В некоторых вариантах реализации платежные данные включают номер карты, 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).
Покупатель, желая, чтобы его товар оплатили третьи лица-плательщики, вводит на устройстве (фиг. 2, 102) в интерфейсе данные о плательщиках и выбирает опцию оплаты за счет третьих лиц-плательщиков (интерфейс ввода плательщиков), которым будет предложено произвести оплату сформированного заказа.
В некоторых вариантах реализации данные о плательщиках включают имя, номер телефона и/или e-mail.
В некоторых вариантах реализации данные о плательщиках включают имя, номер телефона и/или e-mail, название платежной группы.
После ввода данных на устройстве покупателя (фиг. 2, 102), происходит валидация введенных данных. При успешной валидации введенных данных на сервере (204) создается контекст авторизации, генерируется код для упрощенной авторизации плательщиков, генерируется уникальный идентификатор контекста авторизации auth_context_id, который связывается с плательщиками и идентификатором заказа OrderNumber. Затем на указанные номера телефонов или e-mail плательщиков сервер (204) отправляет информацию о заказе сделанным покупателем, со ссылкой на подтверждение оплаты данного заказа confirm_link.
В некоторых вариантах реализации валидация введенных данных происходит на устройстве покупателя (102).
В некоторых вариантах реализации валидация введенных данных происходит на сервере (204), при этом, введенные на устройстве (102) данные о плательщиках отправляются на сервер (204), где происходит их валидация.
В некоторых вариантах реализации отправка информации о заказе покупателя со ссылкой на подтверждение оплаты происходит на устройстве покупателя (102).
В некоторых вариантах реализации отправка информации о заказе покупателя со ссылкой на подтверждение оплаты происходит на сервере.
В некоторых вариантах реализации при отправке информации о заказе покупателя со ссылкой на подтверждение оплаты на сервере (204) выполняются следующие шаги:
- сервер (204) на основании информации о товарах в заказе, генерирует описание заказа покупателя,
- сервер (204) генерирует, по крайней мере, одну уникальную ссылку для подтверждения оплаты заказа данным плательщиком confirm_link, указывающую на сервер (204), при этом, ссылка содержит код для упрощенной авторизации плательщиков и связывает контекст авторизации auth_context_id, идентификатор заказа OrderNumber и плательщика,
- сервер (204) отправляет сгенерированное описание заказа и ссылку confirm_link, по крайней мере, одному плательщику используя номер его телефона или e-mail.
В некоторых вариантах реализации генерация ссылки confirm_link включает следующие шаги:
- Генерируют на сервере (204) уникальный идентификатор pay_code (код для упрощенной авторизации);
- Связывают на сервере (204) идентификатор pay_code с идентификатором контекста авторизации auth_context_id, идентификатором заказа OrderNumber.
- Формируют на сервере (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 и др.
Некоторые нюансы, выходящие за рамки данного технического решения, но необходимые для понимания концепции обработки заказов интернет-магазином запущенным на web-сервере (103) или (203) описаны ниже (фиг. 7).
1. Покупатель взаимодействует с магазином для создания заказа в интернет-магазине.
2. После делегирования права оплаты заказа плательщику и получения подтверждения со стороны плательщика, магазин регистрирует заказ в платежном шлюзе. Для регистрации используются такие параметры как сумма списания, валюта списание, номер заказа в системе магазина, а также URL возврата клиента.
3. На запрос регистрации платежный шлюз возвращает уникальный идентификатор заказа в платежной системе и URL, на который надо перенаправить плательщика для получения платежной формы.
4. Магазин передает браузеру клиента redirect на URL, полученный на шаге 3.
5. Устройство плательщика открывает URL.
6. В качестве страницы по указанному URL устройство плательщика отображает платежную форму.
7. Плательщик заполняет полученную форму и отправляет данные на сервер платежного шлюза.
8. Система проверяет вовлеченности карты в 3DSecure (SecureCode).
9. Шлюз отправляет устройству плательщика перенаправление (redirect) на страницу ACS банка эмитента (этот шаг является необходимым для реализации 3DS).
10. Устройство плательщика запрашивает у ACS форму авторизации пользователя (у каждого эмитента это делается по-своему).
11.ACS отправляет и отображает на устройстве плательщика эту форму.
12. Плательщик заполняет форму и отправляет ее в ACS.
13. ACS обрабатывает заполненную форму и (в не зависимости от результата) передает браузеру redirect на URL страницы платежного шлюза. Вместе с этим URL передаются зашифрованные параметры результата авторизации.
14. Устройство плательщика запрашивает страницу платежного шлюза, передавая зашифрованные параметры результата авторизации.
15. Платежный шлюз производит оплату (списание).
16. После проведения оплаты, платежный шлюз передает устройству плательщика URL возврата (указанный ранее при регистрации заказа магазином).
17. Устройство плательщика запрашивает страницу с результатами оплаты у магазина.
18. (необязательно) Система магазина запрашивает платежный шлюз о статусе оплаты заказа (по внутреннему номеру в платежной системе).
19. (необязательно) платежный шлюз возвращает статус оплаты.
20. Система магазина передает в браузер клиента страницу с результатами оплаты.
В этой схеме шаги 18 и 19 не являются обязательными, магазин может не использовать их в работе. Если по истечении отведенных на оплату 20 минут клиент не вернулся с платежного шлюза на страницу результатов оплаты магазина (на URL возврата клиента), то оплата считается неудачной. Изменение статуса оплаты заказа может быть выполнено по запросу магазина вручную сотрудниками Банка после проверки состояния транзакции в банковских системах. В этом случае после подтверждения изменения статуса заказа магазин может выполнить повторный запрос о статусе оплаты заказа (шаги 18-19). По завершении п. 20 заканчивается взаимодействие между магазином и платежным шлюзом в on-line режиме. Дальнейшие операции по завершению платежа (в случае двухстадийных платежей), отмене платежа и возврату денежных средств проводятся в off-line режиме.
В некоторых вариантах реализации, для регистрации заказа в платежном шлюзе, сервером (фиг. 2, 203 или фиг. 1, 103) передаются, по крайней мере, следующие данные:
- merchantOrderNumber - номер заказа в магазине;
- amount - сумма платежа в минимальных единицах валюты;
- currency - код валюты платежа ISO 4217;
- returnUrl - адрес, на который надо перенаправить плательщика в случае успешной оплаты;
- failUrl - адрес, на который надо перенаправить плательщика в случае неуспешной оплаты.
ПРИМЕРЫ РЕАЛИЗАЦИИ
Сервер (фиг. 2, 203) представляет собой web-сервер, на котором располагается интернет-магазин. В качестве программного обеспечения web-сервера используется база данных MySQL, веб-сервер Apache 2, операционная система Debian 7.
Сервер (фиг. 2, 204) представляет собой web-сервер, на котором располагается сервис, предоставляющий возможность оплаты товаров за счет средств сторонних плательщиков. В качестве программного обеспечения web-сервера используется база данных MSSQL (205), веб-сервер IIS, операционная система Windows.
Устройство покупателя (102) представляет собой ноутбук с операционной системой Windows.
Покупатель посредством сети интернет, через браузер (firefox, opera, ie, chrome или любой другой) устройства (102) осуществляет просмотр страниц интернет-магазина и добавляет в корзину данного интернет-магазина товары, которые он хочет купить. Выбрав необходимые товары, покупатель начинает процесс оформления товара. Начав оформления товара web-сервер, на котором располагается магазин сохраняет сформированный заказ в собственной базе данных MySQL. Сохраненному заказу задается идентификатор номера заказа OrderNumber, идентификатор заказа order_id, который задается автоматически при добавлении новой записи в базу данных. Пройдя этапы оформления заказа, покупателю на устройстве (102) отображается интерфейс выбора варианта оплаты, содержащий опцию оплаты за счет средств третьих лиц-плательщиков в виде кнопки «оплати за меня». При формировании данного интерфейса сервер (203) создал слепок заказа, сохранил его в виде js объекта и привязал отправку данного js объекта и токена, связанного с заказом по нажатию на кнопку «оплати за меня» на сервер (204). При нажатии на данную кнопку данные отправляются на сервер (204) и запускается процесс авторизации и идентификации покупателя сервером (204). Сервер (204) отображает в модальном окне интернет-магазина, расположенного на сервере (203) интерфейс авторизации и идентификации, содержащий поля имя (фиг. 3, 301), номер телефона покупателя (302). После ввода данных по нажатию на кнопку (303) они отправляются на сервер (204) и покупателю отображается интерфейс, содержащий поле ввода кода авторизации (фиг. 3Б, 304). Сервер (204) получив данные, генерирует код авторизации (auth_code) и отправляет его покупателю на указанный им номер телефона. Покупатель, получив код авторизации, вводит его (auth_code) на устройстве (102), после чего введенный код отправляется на сервер (204). Сервер (204) получив введенный покупателем код авторизации, сравнивает его с отправленным покупателю. Если оба кода совпали, покупатель авторизовывается, иначе происходит отказ в авторизации. После успешной авторизации покупателя, он связывается с идентификатором заказа order_id. Далее покупателю на устройстве (102) в том же модальном окне отображается интерфейс ввода новых или выбора введенных ранее данных о третьих лицах - плательщиках, которым будет предложено произвести оплату заказа. Данный интерфейс содержит поля для ввода имени и номера телефона или e-mail плательщика. Покупатель вводит данные и отправляет их на сервер (204) путем нажатия на кнопку «запросить оплату» (фиг. 4, 408). При успешной валидации введенных данных на сервере (204) создается контекст авторизации, генерируется уникальный идентификатор контекста авторизации auth_context_id, который связывается с указанными покупателем плательщиками и идентификатором заказа order_id. Затем на указанные номера телефонов или e-mail плательщиков сервер (204) отправляет информацию о заказе сделанным покупателем, со ссылкой на подтверждение оплаты заказа confirm_link, уникальной для каждого плательщика. Плательщики, указанные покупателем, получают информацию о заказе на устройстве (фиг. 2, 105N или 105М). Если информация отсылалась на номер телефона плательщика, то полученное сообщение содержит краткую информацию о заказе и ссылку на страницу с полным описанием заказа и опциями отказа и подтверждения оплаты заказа покупателя. При переходе по ссылке плательщику отображается интерфейс информации о заказе (фиг. 5). Если информация отсылалась на e-mail плательщика, то сообщение содержит информацию о заказе, опции отказа и подтверждения оплаты заказа плательщика. Плательщик с устройства 105N нажимает кнопку «подтвердить», сервер (204) определяет значение номер заказа OrderNumber, связанное с данным заказом и токен, после чего отправляет эти данные серверу (203) и перенаправляет плательщика на интерфейс оплаты заказа сформированный на сервере (203). Сервер (203) перед отображением плательщику интерфейса оплаты сверяет присланный токен, и токен, связанный с данным заказом, извлекает из базы данных информацию о заказе с номером OrderNumber и производит необходимые настройки для проведения оплаты товара через платежный шлюз. Далее плательщик на устройстве (фиг. 2, 105N или 105М) в интерфейсе оплаты выбирает платежное средство. Когда выбор платежного средства осуществлен, плательщик вводит платежные данные и подтверждает оплату.
Специалист в данной области техники может легко понять различные варианты реализации настоящего технического решения из рассмотренного описания и уровня техники, раскрытого технического решения. Предполагается, что описание и примеры рассматриваются только как примерные, с сущностью и объемом настоящего технического решения, обозначенными формулой.
Следует принимать во внимание, что настоящее техническое решение не ограничивается точными конструкциями, которые были описаны выше и проиллюстрированы на прилагаемых чертежах, и что различные модификации и изменения могут быть сделаны без отхода от области его применения.
Claims (14)
1. Способ онлайн передачи права оплаты товаров или услуг с устройства покупателя на устройства сторонних плательщиков содержит следующие шаги:
- получают на сервере от устройства покупателя запрос на оплату сформированного заказа за счет средств другого плательщика;
- формируют на сервере слепок заказа покупателя, присваивают слепку заказа идентификатор заказа и сохраняют слепок заказа в базе данных;
- производят авторизацию покупателя, оформляющего заказ через устройство покупателя;
- получают на сервере данные по крайней мере одного плательщика от устройства покупателя;
- формируют на сервере для по крайней мере одного плательщика уникальную ссылку на оплату сформированного покупателем заказа, указывающую на сервер, при этом ссылка связывает контекст авторизации, идентификатор заказа, плательщика;
- сервер отправляет по крайней мере одному плательщику информацию о заказе, сформированную уникальную ссылку для оплаты сформированного покупателем заказа;
- при переходе по сформированной уникальной ссылке плательщику отображают на устройстве плательщика интерфейс оплаты заказа, сделанного покупателем без необходимости авторизации и/или идентификации.
2. Способ по п. 1, в котором данные плательщика включают, по крайней мере, ФИО и номер телефона.
3. Способ по п. 1, в котором данные плательщика включают, по крайней мере, ФИО и e-mail.
4. Способ по п. 1, в котором отправка плательщикам информации о заказе осуществляется посредством sms или mms.
5. Способ по п. 1, в котором отправка плательщикам информации о заказе осуществляется посредством на аккаунт электронного мессенджера, связанного с номером телефона плательщика.
6. Способ по п. 1, в котором отправка плательщикам информации о заказе осуществляется посредством e-mail.
7. Способ по п. 1, в котором информация о заказе включает текст описания заказа и/или комментарии покупателя, товарные позиции заказа.
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
RU2016148462A RU2646335C1 (ru) | 2016-12-09 | 2016-12-09 | Способ онлайн передачи права оплаты товаров или услуг сторонним плательщикам |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
RU2016148462A RU2646335C1 (ru) | 2016-12-09 | 2016-12-09 | Способ онлайн передачи права оплаты товаров или услуг сторонним плательщикам |
Publications (1)
Publication Number | Publication Date |
---|---|
RU2646335C1 true RU2646335C1 (ru) | 2018-03-02 |
Family
ID=61568598
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
RU2016148462A RU2646335C1 (ru) | 2016-12-09 | 2016-12-09 | Способ онлайн передачи права оплаты товаров или услуг сторонним плательщикам |
Country Status (1)
Country | Link |
---|---|
RU (1) | RU2646335C1 (ru) |
Citations (6)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
RU2381557C2 (ru) * | 2004-08-25 | 2010-02-10 | Ск Телеком Ко., Лтд. | Система и способ аутентификации и осуществления оплаты с использованием мобильного терминала связи |
WO2013036170A2 (en) * | 2011-09-06 | 2013-03-14 | Rawllin International Inc. | Third-party payments for electronic commerce |
US20130159173A1 (en) * | 2011-12-19 | 2013-06-20 | Sridhar Sivaraman | Shared Mobile Payments |
US20130246218A1 (en) * | 2012-03-15 | 2013-09-19 | Balaji Gopalan | Remote third party payment of in-store items |
US9355394B2 (en) * | 2011-08-11 | 2016-05-31 | Visa International Service Association | Systems and methods of aggregating split payments using a settlement ecosystem |
US20160180320A1 (en) * | 2014-12-22 | 2016-06-23 | Apriva, Llc | System and method for facilitating an online transaction with a second mobile device |
-
2016
- 2016-12-09 RU RU2016148462A patent/RU2646335C1/ru not_active IP Right Cessation
Patent Citations (6)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
RU2381557C2 (ru) * | 2004-08-25 | 2010-02-10 | Ск Телеком Ко., Лтд. | Система и способ аутентификации и осуществления оплаты с использованием мобильного терминала связи |
US9355394B2 (en) * | 2011-08-11 | 2016-05-31 | Visa International Service Association | Systems and methods of aggregating split payments using a settlement ecosystem |
WO2013036170A2 (en) * | 2011-09-06 | 2013-03-14 | Rawllin International Inc. | Third-party payments for electronic commerce |
US20130159173A1 (en) * | 2011-12-19 | 2013-06-20 | Sridhar Sivaraman | Shared Mobile Payments |
US20130246218A1 (en) * | 2012-03-15 | 2013-09-19 | Balaji Gopalan | Remote third party payment of in-store items |
US20160180320A1 (en) * | 2014-12-22 | 2016-06-23 | Apriva, Llc | System and method for facilitating an online transaction with a second mobile device |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US10417706B1 (en) | Integrating externally-supplied interface component into transaction platform | |
JP5455269B2 (ja) | サードパーティ支払い処理のシステムおよび方法 | |
US8156041B2 (en) | Dynamic indicator for context sensitive real-time communications | |
US10169748B2 (en) | Alternative payment implementation for electronic retailers | |
US11182758B2 (en) | Rapid checkout after payment | |
US20110178897A1 (en) | Systems and methods for processing incomplete transactions over a network | |
US20120166311A1 (en) | Deferred payment and selective funding and payments | |
KR20160136415A (ko) | 가상 카드 값들을 사용하여 거래들을 수행하는 방법 | |
KR20110070856A (ko) | 결제 애플리케이션 조력 방법, 기계 판독 가능 매체 및 컴퓨터 구현 방법 | |
WO2012151163A1 (en) | Barcode checkout at point of sale | |
EP2386096A1 (en) | Payment system | |
KR20160003672A (ko) | 모바일 디바이스 상에서의 즉시 결제를 구현하기 위한 시스템 및 방법 | |
AU2007307648A1 (en) | Method and system for making anonymous on-line purchases | |
EP3031020A1 (en) | Methods and systems for providing 3-d secure service on-behalf-of merchants | |
US20150186391A1 (en) | Method of Document Processing for a Fully Integrated Ecommerce System | |
US20130212012A1 (en) | System And Method For Mobile Electronic Purchasing | |
JP2005250899A (ja) | プリペイド決済装置、プリペイド決済システム、プリペイド決済方法、及びプログラム | |
RU2646335C1 (ru) | Способ онлайн передачи права оплаты товаров или услуг сторонним плательщикам | |
US20170372280A1 (en) | System and method for decoupling an e-commerce order from the electronic payment transaction | |
KR20010085205A (ko) | 전자상거래에 의한 전자영수증 관리 시스템 및 그 방법 | |
US20190114602A1 (en) | Configuration Tool for Payment Processing | |
WO2014152732A1 (en) | System and method for mobile electronic purchasing | |
US20120226580A1 (en) | Gift transactions via a client device | |
KR102548159B1 (ko) | 결제 분리 승인 전문 구성 방법 | |
US11170419B1 (en) | Methods and systems for transaction division |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
MM4A | The patent is invalid due to non-payment of fees |
Effective date: 20181210 |