Результат интеллектуальной деятельности: СИСТЕМА СПИСАНИЯ И ПЕРЕЧИСЛЕНИЯ ДЛЯ X-PAY ЦИФРОВЫХ КОШЕЛЬКОВ

Перекрестная ссылка на связанные заявки

Настоящая заявка испрашивает приоритет, согласно 35 USC §119(e), ранее поданной предварительной патентной заявки США № 62/476,971, поданной 27 марта 2017, и предварительной патентной заявки США № 62/534,734, поданной 20 июля 2017, обе из которых включены в настоящий документ посредством ссылки во всей их полноте.

Предшествующий уровень техники

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

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

Однако процесс клиринга и урегулирования обычно требует одного или нескольких рабочих дней для завершения. Продавцы не могут получить денежные средства до тех пор, пока клиринг и урегулирование не завершены полностью. Более того, в некоторых ситуациях, продавцу может быть желательным акцептовать бесконтактные транзакции системы счетов платежа без наличия инфраструктуры бесконтактных платежей на месте. Например, мелкому продавцу может быть нежелательно нести затраты, связанные с получением и установкой бесконтактных аппаратных систем. Также, в некоторых случаях, когда терминал POS, которым владеет продавец, достиг конца своего срока службы, продавцу может быть желательным продолжить акцептовать транзакции системы счетов платежа через альтернативные каналы без приобретения замены для установленного в текущее время терминала POS.

Краткое описание чертежей

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

Фиг. 1 представляет собой диаграмму, иллюстрирующую систему для выполнения процесса pull-платежа (дебетового платежа, или платежа путем списания, инициируемого получателем) и push-платежа (кредитного платежа, или платежа путем перечисления, инициируемого плательщиком) в соответствии с примерным вариантом осуществления.

Фиг. 2 представляет собой диаграмму, иллюстрирующую систему для выполнения процесса платежа путем списания и путем перечисления, в соответствии с другим примерным вариантом осуществления.

Фиг. 3 представляет собой диаграмму, иллюстрирующую процесс спонсорской системы, определяющей идентификационные данные эмитента, в соответствии с примерным вариантом осуществления.

Фиг. 4 представляет собой диаграмму, иллюстрирующую пример процесса аутентификации, в соответствии с примерным вариантом осуществления.

Фиг. 5 представляет собой диаграмму, иллюстрирующую процесс локального платежа путем списания и путем перечисления в соответствии с примерным вариантом осуществления.

Фиг. 6 представляет собой диаграмму, иллюстрирующую способ списания и перечисления платежа, в соответствии с примерным вариантом осуществления.

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

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

Подробное описание

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

Традиционная обработка платежей требует процесса клиринга и урегулирования “овернайт” (до начала следующего рабочего дня), который может занимать по меньшей мере один рабочий день или более. К тому же, когда платежная транзакция производится в выходной день или праздник, платеж не обрабатывается до следующего рабочего дня, что приводит к дополнительной задержке, прежде чем денежные ресурсы переводятся от держателя карты (“потребителя”) к продавцу. Примерные варианты осуществления преодолевают эти недостатки в традиционном процессе клиринга и урегулирования платежа путем обеспечения доступности денежных ресурсов на счете продавца менее чем через час (например, 10 минут, 20 минут, 30 минут и т.д.) без необходимости клиринга и урегулирования “овернайт”. Перевод денежных ресурсов почти в реальном времени одновременно осуществляет перевод ответственности. Соответственно, счет продавца может быть кредитован денежными ресурсами в тот же самый день (или даже тот же самый час), обеспечивая готовность доступа к денежным ресурсам.

Как описано в настоящем документе, спонсорская система, такая как банк–эквайер, банк–эмитент, процессор платежа, прикладной программный интерфейс (API) или тому подобное, может осуществлять связь с цифровым кошельком, применяемым держателем карты, и может действовать по поручению держателя карты, чтобы переводить платеж со счета держателя карты на счет продавца через процесс списания (pull, дебетования) и перечисления (push, кредитования). Списание и перечисление представляют собой отдельные односторонние транзакции, которые перемещают деньги от эмитента счета–отправителя к спонсорской системе и затем от спонсорской системы на эмитент счета продавца. Например, держатель карты может выбрать счет платежа в цифровом кошельке и предоставить запрос на оплату на спонсорскую систему на основе сканирования кода быстрого ответа (QR), выполняемого, чтобы захватить QR–код продавца. В QR–код может быть встроена информация счета продавца и информация продавца. В дополнение к информации счета продавца, устройство держателя карты может также передавать (зашифрованную) информацию счета держателя карты, которая хранится в цифровом кошельке. Соответственно, спонсорская система может принимать информацию счета эмитента как держателя карты, так и продавца.

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

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

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

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

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

Чтобы улучшить связанную процедуру обработки QR–платежей, примерные варианты осуществления расширяют возможность совершения платежей на основе QR–кода на цифровые кошельки не–эмитента (также называемые X–pay кошельками), которые могут поддерживать одну или несколько платежных карт и/или счетов на основе эмитента. Как описано в настоящем документе, цифровой кошелек не–эмитента относится к цифровым кошелькам, которыми не владеют и которые не задействуются финансовыми организациями, но которые вместо этого управляются объектами, которые не имеют лицензии на денежные переводы. Поскольку каждое государство имеет свои собственные лицензионные требования, имеет место вариабельность в требованиях отправителя денег от государства к государству. Однако почти каждое государство требует от отправителей удовлетворять требованиям быть лицензированными в качестве отправителя денег, таким как обеспечение гарантии выполнения (поручительской гарантии), а также федеральным регистрационным требованиям сети по борьбе с финансовыми преступлениями (FinCEN). К тому же, отправители денег должны быть лицензированы в каждом государстве, в котором осуществляется деятельность по переводу. Поэтому, лицензии на денежные переводы могут представлять собой значительную затрату времени и денег.

Цифровым кошелькам не–эмитента не требуются лицензии на денежные переводы, поскольку они не администрируют денежный перевод. Существуют десятки цифровых кошельков на основе не–эмитента, включающие в себя кошельки на основе изготовителя комплектного (оригинального, под собственной торговой маркой) оборудования (OEM), такие как Samsung Pay, Apple Pay, Android Pay и т.д., а также другие кошельки не–эмитента, такие как MasterPass от MasterCard, Google Wallet, Oracle Pay и т.д. До сих пор эти цифровые кошельки не–эмитента были неспособны участвовать в транзакциях списания и перечисления на основе QR. Примерные варианты осуществления теперь обеспечивают возможность таким цифровым кошелькам не–эмитента отправлять деньги сразу же от держателя карты продавцу.

Фиг. 1 иллюстрирует систему 100 для выполнения процесса платежа путем списания и путем перечисления, в соответствии с примерным вариантом осуществления. Со ссылкой на фиг. 1, система 100 включает в себя мобильное устройство 110, реализующее цифровой кошелек, такой как цифровой кошелек не–эмитента, но варианты осуществления не ограничены цифровым кошельком не–эмитента и могут включать в себя цифровой кошелек на основе эмитента. Мобильное устройство 110 может представлять собой смартфон, планшет, ноутбук, записную книжку, электронный прибор, носимое смарт–устройство или тому подобное, которое может представлять собой устройство держателя карты или держателя счета, исполняющее один или несколько цифровых кошельков. Цифровой кошелек разрешает держателю карты/пользователю добавлять счета платежа через процесс оцифровки, который может безопасно сохранять токенизированную (снабженную метками) информацию счета для счета платежа на безопасном элементе мобильного устройства 110. В соответствии с различными вариантами осуществления, держатель карты (отправитель) может отправлять деньги на получающий счет (получатель), такой как счет продавца.

Система 100 дополнительно включает в себя спонсорскую систему 120, которая может действовать по поручению держателя карты мобильного устройства 110, чтобы выполнять процесс платежа путем списания и путем перечисления посредством платежной сети 150, чтобы списать деньги из счета–отправителя и перечислить деньги на счет–получатель. Спонсорская система 120 может осуществлять связь с банком–эмитентом счета–отправителя (эмитентом–отправителем 130) и банком–эмитентом счета–получателя (эмитентом–получателям 140) посредством платежной сети 150. В одном примере, спонсорская система 120 может включать в себя вычислительное устройство/сервер, реализующий API отправки в соответствии с различными вариантами осуществления. API отправки включает в себя услуги, библиотеки, код и тому подобное, которые обеспечивают возможность спонсорской системе 120 осуществлять связь с платежной сетью и передавать сообщения платежа путем списания и путем перечисления. Например, API отправки позволяет спонсорской системе 120 списать платеж от эмитента–отправителя 130 на основе запроса из цифрового кошелька на мобильном устройстве 110 и перечислить списанный платеж из спонсорской системы 120 на эмитент–получатель 140 , где эмитент–получатель делает денежные ресурсы доступными почти в реальном времени для получателя без требования завершения процесса урегулирования и клиринга овернайт, чтобы послать денежные ресурсы.

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

В любом из решения API и решения банка торговой точки, спонсорская система 120 принимает как PAN потребителя, так и PAN продавца от точки входа, которая в примере на фиг. 1 представляет собой цифровой кошелек не–эмитента. Например, потребитель может сканировать QR–код продавца с использованием своего цифрового кошелька не–эмитента, который может синтаксически анализировать информацию счета продавца из QR–кода, и также хранит информацию эмиссии PAN потребителя и обеспечивает их на спонсорскую систему 120. Здесь, синтаксический анализ QR–кода может производиться посредством цифрового кошелька не–эмитента, чтобы получить PAN продавца. Тем временем, цифровой кошелек может уже иметь сохраненную в нем копию PAN потребителя, который может быть токенизирован в целях безопасности.

Что вызвать процесс платежа путем списания и путем перечисления, мобильное устройство 110 может сканировать QR–код продавца с использованием цифрового кошелька не–эмитента. Например, QR–код может быть связан с покупкой предмета, такого как товар, услуга и/или тому подобное. QR–код может включать в себя информацию о продавце, закодированную в нем, такую как номер счета продавца (PAN), сумма транзакции, код категории продавца (MCC), код валюты транзакции, страна продавца, город продавца, имя продавца, поля оптических данных, проверки CRC и тому подобное. Следует понимать, что дополнительная информация, не рассматриваемая конкретно, может также быть включена в QR–код. Чтобы отобразить QR–код, QR–код может отображаться на экране вычислительного устройства или другого объекта (киоска, телевизора, терминала POS и т.д.) в местоположении продавца. В качестве другого примера, QR–код может быть включен в чек за товары или услуги, распечатываемый продавцом или отображаемый онлайн посредством веб–страницы, так что он может сканироваться мобильным устройством 110 держателей карт в местоположении, которое удалено от продавца.

В ответ на сканирование QR–кода, цифровой кошелек не–эмитента может синтаксически анализировать QR–данные, чтобы получить информацию продавца, такую как PAN продавца, закодированную в QR. К тому же, цифровой кошелек не–эмитента передает запрос на платеж путем списания на спонсорскую систему 120. Здесь, запрос может представлять собой запрос сообщения не–платежа, или он может включать в себя сообщение, которое уже находится в формате для обработки посредством платежной сети (ISO 8583). Если он не в формате, готовом для обработки платежей, то запрос может быть преобразован спонсорской системой 120 в сообщение запроса авторизации, которое сформатировано для сообщения запроса авторизации платежной сети. Запрос, отправленный от цифрового кошелька на мобильном устройстве 110 на спонсорскую систему 120, может включать в себя одно или несколько значений в полях транзакций, которые указывают, что запрос должен быть обработан в качестве процесса платежа путем списания/перечисления.

В ответ на прием запроса, спонсорская система 120 может обеспечивать безопасность платежных денежных ресурсов от банка–эмитента держателя карты (эмитента–отправителя 130), который является эмитентом счета–отправителя. Например, цифровой кошелек (или провайдер кошелька) может отправлять запрос сканирования QR–кода на спонсорскую систему 120, которая затем пытается списать деньги из банка–эмитента потребителя посредством платежной сети 150. Спонсорская система 120 может выполнять операцию списания путем передачи сообщения запроса авторизации (например, ISO 8583) на эмитент–отправитель 130 посредством платежной сети 150 и принимать сообщение ответа авторизации от эмитента–отправителя 130 посредством платежной сети 150.

Более того, перед, во время и/или после операции списания, мобильное устройство 110 и эмитент–отправитель 130 могут выполнять процесс аутентификации посредством спонсорской системы 120 и платежной сети 150, чтобы верифицировать, что держатель карты/счет представляет собой авторизованного пользователя и/или карту. Процесс аутентификации может переводить ответственность за возврат платежа от спонсорской системы 120 (и X–pay кошелька на мобильном устройстве 110) на эмитент–отправитель 130 в результате перевода путем списания. Напротив, для традиционного запроса покупки на основе PAN, ответственность не переводится до тех пор, пока не будет удовлетворен процесс клиринга и урегулирования овернайт.

Когда платеж был списан со счета–отправителя, выпущенного эмитентом–отправителем 130, и переведен на спонсорскую систему 120, спонсорская система 120 может перечислить списанный платеж на эмитент–получатель 140 посредством платежной сети 150. Эмитент–получатель 140 является эмитентом счета–получателя (такого как счет продавца). Из–за процесса аутентификации, который выполняется во время транзакции списания, ответственность за возврат платежа переводится от спонсорской системы 120 на эмитент держателя карты счета 130 отправки. Процесс списания и перечисления представляет собой необходимый процесс из двух последовательных этапов, где каждый этап включает в себя односторонний платежный перевод, который обычно выполняется при помощи процесса клиринга овернайт. Однако процесс платежа путем списания и путем перечисления делает денежные ресурсы доступными на счете получателей, как только эмитент–получатель 140 одобряет авторизацию перечисления. Другими словами, денежные ресурсы перемещаются от эмитента–отправителя 130 на эмитент–получатель 140 за минуты посредством спонсорской системы 120, и денежные ресурсы становятся доступными почти в реальном времени (например, 30 минут и т.д.) для счета продавца в эмитенте–отправителе 140.

Система 100 обеспечивает возможность QR–платежей от провайдера кошелька 3ей стороны, который не является эмитентом финансового счета и не имеет лицензии на денежные переводы. В одном варианте осуществления, спонсорская система 120 может представлять собой банк–эквайер, который обрабатывает транзакцию списания/перечисления по поручению цифрового кошелька не–эмитента. В качестве другого примера, спонсорская система 120 может представлять собой устройство, реализующее API отправки (например, MasterCard Send API и т.д.), которое выполняет процесс транзакции списания/перечисления по поручению цифрового кошелька не–эмитента. Отличие от традиционных платежных систем отправки состоит в том, что должны происходить две транзакции, чтобы осуществлять списание и перечисление. Потребитель, имеющий счет, желает выполнить платеж при помощи этого счета продавцу. Деньги необходимо вывести со счета потребителя и перечислить на счет продавца. Когда потребитель использует цифровой кошелек на основе эмитента, эмитент имеет прямой доступ к информации счета держателя карты. Поэтому, эмитент может выводить деньги непосредственно со счета без необходимости беспокоиться о том, чтобы обрабатывать запрос списания. Однако, в контексте цифрового кошелька не–эмитента, потребитель обеспечивает PAN (который может представлять собой токен (маркер)), но цифровой кошелек не–эмитента не имеет возможности переводить деньги со счета потребителя. Процесс списания и перечисления, выполняемый спонсорской системой 120 по поручению цифрового кошелька не–эмитента на мобильном устройстве 110 проводит решение в жизнь.

Следует также понимать, что примерные варианты осуществления не ограничены запросом, запускаемым посредством цифрового кошелька не–эмитента. В качестве другого примера, вместо того чтобы принимать запрос от цифрового кошелька, процесс списания/перечисления может с выгодой использоваться финансовой организацией, такой как банк–эквайер, банк–эмитент и тому подобное. Поэтому, следует понимать, что пример согласно фиг. 1 не ограничен выполнением в ответ на запрос от цифрового кошелька не–эмитента.

Фиг. 2 иллюстрирует примерную систему 200 для выполнения процесса платежа путем списания и путем перечисления, в соответствии с другим примерным вариантом осуществления. В примере на фиг. 2, сеть списания и перечисления является той же самой, что и на фиг. 1, но точка ввода представляет собой терминал 210 мобильной точки продаж (mPOS) продавца, который принимает PAN потребителя и хранит PAN эмитента продавца, которые затем обеспечиваются на спонсорскую систему 120. В этом примере, терминал 210 mPOS может принимать транзакцию бесконтактного платежа от цифрового кошелька на мобильном устройстве 220, не требуя от продавца устанавливать оборудование и инфраструктуру бесконтактного платежа. Например, бесконтактный платеж может выполняться между держателем карты (отправителем) и продавцом (получателем), где платежные учетные данные переводятся терминалу 210 mPOS продавца от мобильного устройства 220 посредством беспроводного протокола. Когда держатель карты подносит мобильное устройство 220 (или другое платежное средство, такое как карта выпуска и т.д.) поблизости или на предопределенное расстояние от терминала 210 mPOS продавца, информация счета платежа может переводиться беспроводным образом от мобильного устройства 220 на терминал 210 mPOS.

Например, системы бесконтактных платежей включают в себя кредитные карты и дебетовые карты, брелоки для ключей, смарт–карты или другие устройства, включая смартфоны и другие мобильные устройства, которые используют радиочастотную идентификацию (RFID) или связь близкого радиуса действия (NFC), такие как Apple Pay®, Samsung Pay®, Google Wallet® и тому подобное, для совершения безопасных платежей. Встроенный чип и антенна обеспечивают возможность потребителям взмахнуть или иным образом провести карту, брелок или портативное устройство по считывателю в терминале 210 mPOS. Бесконтактные платежи совершаются в непосредственной физической близости, в отличие от мобильных платежей, которые используют сотовые сети широкого охвата или Wi–Fi сети и обычно не используют непосредственной физической близости.

Обычно, поддержка бесконтактных платежей требует значительной инфраструктуры банком–эквайером продавца, чтобы придерживаться требований для обработки бесконтактных транзакций платежных счетов. В результате, эквайер должен добавить непроизводительные издержки в платежную информацию, принимаемую от продавца, и также предпринять определенные меры предосторожности в отношении конфиденциальной финансовой информации счета, хранящейся в нем, чтобы предотвратить мошенничество или утечку конфиденциальных данных. Однако примерные варианты осуществления улучшают это требование путем обеспечения возможности бесконтактных платежей, не требуя банка–эквайера. В примере на фиг. 2, цифровой кошелек не–эмитента на мобильном устройстве 220 может переводить детали бесконтактной транзакции счета платежа держателя карты на терминал 210 mPOS продавца способом бесконтактного платежа, чтобы урегулировать транзакцию между держателем карты и продавцом. Детали бесконтактной транзакции могут включать в себя PAN, срок действия, CVC, имя, адрес и тому подобное для счета платежа, ассоциированного с держателем карты, информацию продавца, информацию транзакции и тому подобное.

Спонсорская система 120 может представлять собой платежный процессор, реализующий API отправки. Поэтому, вместо того, чтобы требовать инфраструктуру организации–эквайера между терминалом 210 mPOS продавца и платежной сетью 150, эмитента–отправителя 130 и эмитента 140 приема, система 200 может опускать эквайер. В результате, системе 200 не требуется поддерживать инфраструктуру эквайера, более того, терминал 210 mPOS продавца может осуществлять связь непосредственно с платежным процессором (спонсорской системой 120), который может реализовывать API отправки. Более того, процесс может полагаться на устройства, уже установленные в платежной сети, тем самым делая обработку платежей транзакции бесконтактного платежа значительно более быстрой.

API, реализуемый спонсорской системой 120 на фиг. 1 и 2, может упаковывать детали транзакции (например, цифровой кошелек не–эмитента, детали бесконтактной транзакции и т.д.) в подходящее сообщение (например, запрос/ответ авторизации) через API отправки платежного процессора, такой как MasterCard Send Unified API. API может принимать детали продавца и обрабатывать транзакцию списания/перечисления не–эмитента (фиг. 1) и бесконтактную транзакцию денежных средств (фиг. 2) между эмитентом 130 потребителя и эмитентом 140 продавца. Более того, API может также облегчать клиринг и урегулирование для транзакции с эмитентом 130 потребителя и эмитентом 140 продавца.

Это решение позволяет продавцам обрабатывать платежи во множестве форм. Например, в одной форме, как регулярную бесконтактную транзакцию списания, с выгодой использующую систему, где продавец получает денежные ресурсы как часть стандартного процесса клиринга и урегулирования. Альтернативно, если продавец также представляет собой QR–продавца, то он может осуществлять доступ к своему PAN продавца из QR вместе с информацией другого продавца и обеспечивать платежные данные потребителя, чтобы обрабатывать транзакцию списания и перечисления при помощи API, чтоб позволит продавцу принимать денежные ресурсы почти в реальном времени и не требуя стандартного процесса клиринга и урегулирования.

Некоторые из преимуществ удаления эквайера включают в себя разрешение продавцу осуществлять доступ к QR–платежам. Более того, продавец может с выгодой использовать ту же самую существующую базовую систему данных и быть в состоянии выполнять бесконтактную транзакцию, не требуя эквайера. Всем объектам, которые требуются продавцу, чтобы обработать платеж, необходимо предоставить набор требований для бесконтактных платежей. Эти требования больше не требуются для инфраструктуры эквайера, поскольку операционный отдел (бэк–офис) продавца непосредственно интегрирован в API платежного оператора. Другое расширенное преимущество состоит в том, что локальный процесс списания и перечисления, описанный в отношении фиг. 5, делает денежные ресурсы доступными в счете продавца почти сразу же, а не после традиционного процесса урегулирования, который осуществляет клиринг только один раз в рабочий день (24 часа) или дольше.

Фиг. 3 иллюстрирует процесс 300 определения спонсорской системой 120 идентификационных данных эмитента, в соответствии с примерным вариантом осуществления. Со ссылкой на фиг. 3, запрос 310 отправки передается от цифрового кошелька, исполняющегося на мобильном устройстве 110, на спонсорскую систему 120. Запрос отправки может представлять собой запрос сообщения, включающий в себя идентификатор или указатель, что мобильное устройство 110 желает инициировать транзакцию списания/перечисления вместе с защищенной информацией счета отправки и счета приема. Запрос 310 отправки может также включать в себя токенизированные данные первичного номера счета (PAN) держателя карты, которые могут сравниваться с таблицей эмитентов 320, чтобы определить, какой эмитент является владельцем токена. Здесь, каждому эмитенту назначается диапазон значений токенов в таблице 320.

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

Например, значение ‘00’ кода обработки вместе с конкретным значением кода категории продавца (MCC) может определять, что транзакция представляет собой транзакцию списания. Например, для транзакции списания, значение DE3 из сообщения может представлять собой ’00’, значение DE18 может представлять собой 6538 для платежа от человека к человеку, или действительный MCC продавца для платежа от человека к продавцу, и значение DE48SE77 может иметь значение ‘C07’ для платежа от человека к человеку и ‘C67’ для платежа от человека к продавцу. Аналогично, для транзакции перечисления, значения DE3 и DE48SE77 могут быть теми же самыми, что и для транзакции списания, в то время как значение DE18 может представлять собой 6536 для внутреннего платежа, 6537 для зарубежного платежа, и действительный MCC продавца для платежа от человека к продавцу. Сообщение авторизации может передаваться на эмитент счета–отправителя или эмитент счета–получателя в зависимости от того, выполняется ли списание или перечисление.

Фиг. 4 иллюстрирует пример процесса 400 аутентификации, в соответствии с примерным вариантом осуществления. Со ссылкой на фиг. 4, процесс 400 аутентификации выполняется между цифровым кошельком, исполняющимся на мобильном устройстве 110, и эмитентом 130 счета платежа, включенным в цифровой кошелек. Здесь, процесс 400 аутентификации выполняется посредством спонсорской системы 120 и платежной сети 150. Процесс 400 аутентификации может представлять собой процесс аутентификации цифрового безопасного удаленного платежа (DSRP), который аутентифицирует информацию EMV, хранящуюся на мобильном устройстве 110, посредством протокола EMV. Процесс 400 аутентификации может выполняться перед запросом на платеж путем списания/перечисления, во время запроса на платеж путем списания/перечисления и т.п.

Аутентификация DSRP реализует токенизацию и динамические криптограммы для онлайн–покупок, чтобы достигнуть того же самого уровня безопасности транзакций, что и обеспечивается через бесконтактную транзакцию в магазине. Процесс 400 аутентификации может использовать возможности мобильного устройства 110 и может включать в себя функции, такие как аутентификация, извлечение токена и генерация криптограмм. Обеспечение этого требует осуществления коммуникации приложения кошелька на мобильном устройстве 110 и у эмитента 130, и обе стороны могут реализовывать релевантные API и SDK, чтобы выполнять DSRP.

Все транзакции DSRP проходят через мобильное устройство 110, чтобы извлечь токены, в дополнение к потребителю, от которого требуется применить свой мобильный PIN для аутентификации платежа (например, посредством пользовательского интерфейса мобильного устройства 110). Успешная аутентификация ведет к отправке токена и сгенерированных криптограмм от устройства к онлайн–продавцу, который будет обрабатывать их как замену данных файла на карте. Процесс 400 аутентификации переводит ответственность за возврат платежа в отношении списанного платежа от спонсорской системы 120 на эмитент–отправитель 130 счета платежа, включенного в мобильный кошелек 110. Например, во время транзакции списания, перевод ответственности может быть получен путем использования DSRP на основе устройства. По меньшей мере одно из устройства платежной сети, системы эмитента, цифрового кошелька, исполняющегося на пользовательском устройстве, и тому подобного, может указывать, что аутентификация была выполнена и что ответственность была переведена через DSRP, путем вставки указателя уровня безопасности (например, 242, 247 и т.д.) в сообщение авторизации/клиринга ISO 8583. В некоторых примерах, системы эмитента, системы обработки платежей или тому подобное могут делегировать аутентификацию держателя карты на кошелек устройства через процесс ID и верификации (ID&V) во время токенизации.

Следует также понимать, что процесс 400 аутентификации не ограничен DSRP, а может включать в себя безопасный код для верификации PAN и тому подобное. Например, во время транзакции списания, перевод ответственности может быть получен с использованием трехмерного кода безопасности (3D–Secure), который представляет собой технический стандарт, для обеспечения того, чтобы держатель карты не представлял транзакции. По меньшей мере одно из устройства платежной сети, системы эмитента, цифрового кошелька, исполняющегося на пользовательском устройстве, и тому подобного может указывать, что аутентификация была выполнена и что ответственность была переведена, через 3D–Secure путем вставки указателя уровня безопасности (например, 212 и т.д.) в сообщение авторизации/клиринга ISO 8583. В некоторых примерах, системы эмитента могут аутентифицировать держателя карты через пошаговую модернизацию или путем использования c выгодой данных, обеспеченных в запросе аутентификации (аутентификация на основе риска). Например, 3D–Secure может позволять серверу управления доступом (или ACS) эмитента принимать данные и инициировать пошаговую модернизацию для держателя карты при необходимости.

Фиг. 5 иллюстрирует локальный процесс 500 платежа путем списания и путем перечисления, выполняемый спонсорским узлом 520, в соответствии с примерным вариантом осуществления. В этом примере, спонсорский узел 520 также представляет собой эмитента счета–отправителя, используемого цифровым кошельком не–эмитента, исполняющимся на мобильном устройстве 510. Здесь, спонсорский узел 520 выполняет локальную операцию списания само–эквайринга без необходимости передавать и принимать авторизацию для счета–отправителя через платежную сеть на отдельную систему эмитента. В этом примере, спонсорский узел 520 выполняет роль как эквайера, так и эмитента в процессе списания.

Фиг. 6 иллюстрирует способ 600 списания и перечисления платежа, в соответствии с примерным вариантом осуществления. Например, способ 600 может выполняться спонсорской системой, такой как вычислительная система финансовой организации (банка–эквайера), устройство обработки платежей, исполняющее API отправки, и тому подобное. Со ссылкой на фиг. 6, в 610, способ включает в себя прием запроса отправки для перевода денег со счета–отправителя на счет–получатель. В одном примере, запрос отправки может приниматься от цифрового кошелька (например, цифрового кошелька не–эмитента), исполняющегося на мобильном устройстве, на основе операции сканирования QR–кода, выполняемой посредством мобильного устройства. В качестве другого примера, запрос отправки может приниматься от терминала mPOS, который принимает бесконтактное взаимодействие от мобильного устройства счета–отправителя. В любом случае, запрос отправки может включать в себя PAN счета–отправителя и PAN счета–получателя.

К тому же, запрос отправки может быть преобразован в сообщение авторизации, которое включает в себя указатель в поле запроса (например, запроса авторизации), который указывает, что запрос отправки представляет собой запрос платежа путем списания/перечисления. В качестве неограничивающего примера, указатель может включать в себя текстовое значение, битовое значение, числовое значение, символ или тому подобное, которое включено в поле транзакции запроса авторизации платежа, который составляет запрос отправки. Например, значение ‘00’ кода обработки вместе с конкретным значением кода категории продавца (MCC) может определять, что транзакция представляет собой транзакцию списания. Например, для транзакции списания, значение DE3 из сообщения может представлять собой ’00’, значение DE18 может представлять собой 6538 для платежа от человека к человеку или действительный MCC продавца для платежа от человека к продавцу, и значение DE48SE77 может иметь значение ‘C07’ для платежа от человека к человеку и ‘C67’ для платежа от человека к продавцу. Аналогично, для транзакции перечисления, значения DE3 и DE48SE77 могут быть теми же самыми, что и для транзакции списания, в то время как значение DE18 может представлять собой 6536 для внутреннего платежа, 6537 для заграничного платежа и действительный MCC продавца для платежа от человека к продавцу.

В 620, способ может включать в себя исполнение посредством спонсорской системы протокола аутентификации между мобильным устройством и эмитентом счета–отправителя. Например, когда запрос отправки принимается от цифрового кошелька не–эмитента, аутентификация может выполняться между цифровым кошельком на мобильном устройстве и эмитентом счета–отправителя, чтобы верифицировать по меньшей мере одно из идентификационных данных держателя карты (например, посредством PIN или безопасного кода для PAN), или чтобы верифицировать платежный счет (например, цифровой безопасный удаленный платеж и т.д.). Например, запрос отправки может приниматься от цифрового кошелька не–эмитента (например, кошелька OEM и т.д.), который не имеет авторизации на доступ к информации счета счета–отправителя, сохраненной эмитентом счета–отправителя. Путем аутентификации одного из карты и пользователя, счет и/или держатель карты может быть верифицирован, даже хотя цифровой кошелек не управляется финансовой организацией и не осуществляет связь непосредственно с банком–эмитентом или платежной сетью.

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

В некоторых вариантах осуществления, спонсорская система может определять эмитента счета–отправителя на основе диапазона токенов, который включает в себя ID токена, принятый от цифрового кошелька держателя карты, из множества диапазонов токенов, спаренных с соответственными ID эмитента. Здесь, ID токена может представлять токенизированную платежную информацию держателя карты (например, PAN, дату истечения, CVC и т.д.). К тому же, из–за аутентификации, выполняемой в 620, списание платежа посредством платежной сети переводит ответственность за возврат платежа в отношении списанного платежа от спонсорской системы на эмитент счета–отправителя в ответ на успешное исполнение протокола аутентификации.

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

Варианты осуществления, описанные выше, могут быть реализованы в аппаратных средствах, в компьютерной программе, исполняемой процессором, в прошивке или в комбинации приведенного выше. Компьютерная программа может быть воплощена на считываемом компьютером носителе, таком как носитель хранения или устройство хранения. Например, компьютерная программа может находиться в памяти с произвольным доступом (“RAM”), флэш–памяти, постоянной памяти (“ROM”), стираемой программируемой постоянной памяти (“EPROM”), электрически стираемой программируемой постоянной памяти (“EEPROM”), регистрах, жестком диске, съемном диске, постоянной памяти на компакт–диске (“CD–ROM”) или любой другой форме носителя хранения, известной в данной области техники.

Носитель хранения может быть связан с процессором, так что процессор может считывать информацию и записывать информацию с/на носитель хранения. Альтернативно, носитель хранения может быть неотъемлемой частью процессора. Процессор и носитель хранения могут находиться в специализированной интегральной схеме (“ASIC”). Альтернативно, процессор и носитель хранения могут быть реализованы как дискретные компоненты. Например, фиг. 7 иллюстрирует примерную архитектуру компьютерной системы, которая может представлять собой или быть интегрирована в один из вышеописанных компонентов и т.д. Фиг. 7 не предусматривает какого–либо ограничения объема использования или функциональности вариантов осуществления описанной заявки. Вычислительная система 700 может быть реализована и/или может выполнять любую функциональность, изложенную выше в настоящем документе.

Вычислительная система 700 может включать в себя компьютерную систему/сервер, который применяется с различными другими универсальными или специализированными средами или конфигурациями вычислительной системы. Примеры хорошо известных вычислительных систем, сред и/или конфигураций, которые могут подходить для использования в качестве вычислительной системы 700, включают в себя, но без ограничения, системы персональных компьютеров, системы серверных компьютеров, простые клиенты, полнофункциональные клиенты, портативные устройства или ноутбуки, планшеты, смартфоны, базы данных, мультипроцессорные системы, системы на основе микропроцессоров, телевизионные приставки, программируемую потребительскую электронику, сетевые PC, системы миникомпьютеров, системы компьютеров–мэйнфреймов, среды распределенных облачных вычислений и тому подобное, которые могут включать в себя любую из приведенных выше систем или устройств и тому подобное.

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

Как показано на фиг. 7, вычислительная система 700 представлена в форме универсального вычислительного устройства. Компоненты вычислительной системы 700 могут включать в себя, но без ограничений, сетевой интерфейс 710, один или несколько процессоров или блоков 720 обработки, вывод 730, который может включать в себя порт, интерфейс и т.д., или другие аппаратные средства для вывода сигнала данных на другое устройство, такое как дисплей, принтер и т.д., и устройство 740 хранения, которое может включать в себя системную память или тому подобное. Хотя не показано, вычислительная система 700 может также включать в себя системную шину, которая соединяет различные компоненты системы, включая системную память, с процессором 720.

Устройство хранения 740 может включать в себя множество считываемых компьютерной системой носителей. Такие носители могут представлять собой любые доступные носители, доступ к которым осуществляется компьютерной системой/сервером, и это может включать в себя как энергозависимые, так и энергонезависимые носители, съемные и несъемные носители. Системная память в одном варианте осуществления реализует диаграммы последовательностей операций согласно другим чертежам. Системная память может включать в себя считываемые компьютерной системой носители в форме энергозависимой памяти, такие как память с произвольным доступом (RAM) и/или кэш–память. В качестве другого примера, устройство 740 хранения может считывать и записывать на несъемные, энергонезависимые магнитные носители (не показаны и обычно называются “накопителем на жестком диске”). Хотя не показано, могут быть обеспечены накопитель на магнитном диске для считывания и записи с/на съемный, энергонезависимый магнитный диск (например, “флоппи–диск”) и накопитель на оптическом диске для считывания и записи с/на съемный, энергонезависимый оптический диск, такой как CD–ROM, DVD–ROM или другие оптические носители. В таких примерах, каждый может быть соединен с шиной посредством одного или нескольких интерфейсов носителей данных. Как будет дополнительно изображено и описано ниже, устройство 740 хранения может включать в себя по меньшей мере один программный продукт, имеющий набор (например, по меньшей мере один) программных модулей, которые сконфигурированы, чтобы выполнять функции различных вариантов осуществления заявки.

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

Хотя не показано, вычислительная система 700 может также осуществлять связь с одним или несколькими внешними устройствами, такими как клавиатура, устройство указания, дисплей и т.д.; одним или несколькими устройствами, которые позволяют пользователю взаимодействовать с компьютерной системой/сервером; и/или любыми устройствами (например, сетевой картой, модемом и т.д.), которые позволяют вычислительной системе 700 осуществлять связь с одним или несколькими другими вычислительными устройствами. Такая связь может осуществляться посредством интерфейсов I/O. Кроме того, вычислительная система 700 может осуществлять связь с одной или несколькими сетями, такими как локальная сеть (LAN), общая глобальная сеть (WAN) и/или общедоступная сеть (например, Интернет), посредством сетевого интерфейса 710. Как изображено, сетевой интерфейс 710 может также включать в себя сетевой адаптер, который осуществляет связь с другими компонентами вычислительной системы 700 посредством шины. Хотя не показано, другие компоненты аппаратных средствах и/или программного обеспечения могут использоваться во взаимосвязи с вычислительной системой 700. Примеры включают в себя, но без ограничения: микрокод, драйверы устройства, резервные блоки обработки, массивы внешних накопителей на дисках, системы RAID, накопители на магнитной ленте и системы архивного хранения данных и т.д.

Со ссылкой на фиг. 7, сетевой интерфейс 710 может принимать от цифрового кошелька, исполняющегося на мобильном устройстве, запрос отправки, чтобы отправить платеж со счета–отправителя, включенного в цифровой кошелек, на счет–получатель. В этом примере, процессор 720 может исполнять протокол аутентификации между мобильным устройством и эмитентом счета–отправителя. В качестве другого примера, сетевой интерфейс 710 может принимать от системы мобильной точки продаж (mPOS) продавца, исполняющейся на мобильном устройстве, запрос отправки, чтобы отправить платеж со счета–отправителя на счет–получатель, ассоциированный с mPOS.

В любом случае, процессор 720 может управлять сетевым интерфейсом 710, чтобы списать запрошенный платеж от эмитента счета–отправителя на спонсорскую систему посредством платежной сети на основе информации эмитента счета–отправителя, включенной в запрос отправки. Здесь, списание платежа посредством платежной сети может переводить ответственность за возврат платежа в отношении списанного платежа от эмитента счета–отправителя к спонсорской системе в ответ на успешное исполнение протокола аутентификации. Кроме того, процессор 720 может управлять сетевым интерфейсом 710, чтобы перечислить запрошенный платеж от спонсорской системы на эмитент счета–получателя посредством платежной сети на основе информации эмитента счета–получателя, включенной в запрос.

Будет легко понятно, что описания и примеры в настоящем документе, как в общем описано и проиллюстрировано на чертежах, могут быть организованы и созданы во множестве различных конфигураций. Таким образом, подробное описание вариантов осуществления не предназначено ограничивать объем заявки как заявлено, но является только представлением выбранных вариантов осуществления заявки. Специалист в данной области техники с легкостью поймет, что приведенное выше может быть реализовано при помощи этапов, выполняемых в другом порядке, и/или при помощи элементов аппаратных средств в конфигурациях, которые отличаются от раскрытых конфигураций. Поэтому, хотя заявка была описана на основе некоторых предпочтительных вариантов осуществления, специалистам в данной области техники будет понятно, что определенные модификации, вариации и альтернативные конструкции будут очевидными.