введение в электронные платежные системы
участники электронных платежей
Электронные платежи, как и любые другие, предусматривают наличие плательщика и получателя платежа. Задачей платежей, как известно, является перемещение денежной суммы от плательщика к получателю. В электронных системах такой перевод сопровождается протоколом электронного платежа. Этот процесс также требует наличия некоторого финансового института, соотносящего данные, которыми стороны обмениваются в платежном протоколе, с реальным перемещением денежных средств. Таким финансовым институтом может служить банк, работающий с реальными денежными средствами, или некоторая организация, выпускающая и контролирующая другие формы представления финансов. В данной статье слово "банк" будет использоваться для обозначения различных видов финансовых институтов, а словосочетание "реальные средства" - применительно ко всем формам представления ценности, используемым финансовыми институтами.
Обычно банки исполняют в платежных протоколах две роли: эмитента (взаимодействующего с плательщиком) и эквайрера (взаимодействующего с получателем платежа). Кроме того, платежной системе необходим арбитр для разрешения возникающих споров.
классификация моделей электронных платежей
Прямые/непрямые системы электронных платежей.Различаются в зависимости от наличия/отсутствия прямой связи между плательщиком и получателем. В непрямой системе платежная операция совершается ее инициатором и ее участниками являются только он сам и банк(и). Второй участник платежа определяется банком по завершении транзакции. Примером прямого платежа является платеж наличными или чеком. Примером непрямого - постоянный наряд-заказ или телеграфный перевод. Большинство современных систем предлагает прямой способ платежа.
Системы заранее оплаченных/текущих/отложенных платежей.Различаются в зависимости от того, в какой момент времени инициатор платежа полагает платеж завершенным и в какой момент времени средства действительно изымаются у плательщика. Заранее оплаченные платежи аналогичны платежам наличными, а текущие и отложенные платежи достаточно сходны по своей природе: в обоих случаях пользователю необходимо иметь некий "счет" в банке, и платеж всегда совершается путем пересылки некоторой "формы" от плательщика получателю (чека, слипа кредитной карты, др.). Их даже можно объединить в единую систему платежей, аналогичных чекам. Таким образом, мы подходим к еще одной возможной классификации…
Системы - аналоги наличных денег и системы - аналоги чеков.Однако деление электронных платежных систем на две эти группы было в ходу в 1996-1998 годах. Сегодня оно уже несколько устарело и сейчас специалисты склонны подразделять системы на более детализированные категории - по механизмам осуществления электронных платежей:
- модель систем хранимых сумм (аналог электронных монет, кредитных карт и наличных денег): системы хранимых сумм позволяют пользователям загружать средства с их банковских счетов на принадлежащие пользователям инструменты - смарт-карты (устройства, в которых электронным образом на встроенном чипе закодирована хранимая сумма) или PC-файлы. При совершении покупки с помощью таких инструментов сначала происходит проверка наличия на них необходимой суммы, затем данная сумма отнимается от текущего остатка покупателя и прибавляется к хранимой сумме "поставщика". Смарт-карты имеют дополнительные преимущества: портативность, возможность совершать покупки и пополнять "счет" как по сети, так и в оффлайне, аутентификация с помощью генерируемой при каждом использовании уникальной "цифровой подписи" и др. Примерами являются: Common Electronic Purse Specification (CEPS), European Electronic Purse (EEP), Mondex, Proton, Visa Cash, WorldPay. PC-файлы хранят денежные суммы непосредственно на персональном компьютерном устройстве (компьютере, телевизионной приставке, PDA) в зашифрованном файле, защищенном известным пользователю паролем и не требуют специального аппаратного обеспечения. Примерами являются: Globe ID Payment System, Millicent, NetBill.
- модель систем электронных чеков: тогда как реальные чеки несколько утратили свои позиции за последние годы, электронные чеки все еще имеют достаточно широкое распространение, поскольку являются практически полными аналогами реальных чеков, сохраняя все их преимущества (например, требуют ограниченной информации о получателе), но при этом применимы для электронных платежей в области B2B и также не нуждаются в обязательном онлайновом режиме плательщика в момент покупки. Примерами являются: Mandate II, eCheck.
- модель систем электронных денежных транзакций: в этой категории обычно гораздо больше различных спецификаций, чем в предыдущих двух. Эта модель сама по себе может быть разбита на несколько групп: по содержанию транзакций (кредитовые, дебетовые, просто записи), сфере действия (например, бизнес-транзакции), видам спонсоров (банки, провайдеры) и в зависимости от того, используется ли в процессе транзакции некий посредник - банк, другой финансовый институт или "виртуальная" организация электронной коммерции. В отличие от предыдущих двух категорий, каждая из этих систем реализует определенный сценарий транзакций, включающий обработку заказов, платежей, инструкции, процедуры и протоколы для перевода средств между счетами. Кроме того, несмотря на то, что данная система требует онлайнового режима от плательщика, получатель платежа может находиться в оффлайне (что исключительно выгодно с точки зрения затрат). Сюда относятся различные платежные среды, системы обмена электронными данными/сообщениями, протоколы и др. Примерами являются: BidPay, BillPoint, Q-Pass, i-Escrow, CyberCash, EDI Messages, Opening Buying on the Internet (OBI), Internet Open Trading Protocol, Java EC Framework.
механизмы поддержки проведения электронных платежей
дистанционное управление финансами (home banking)
Точного определения, что такое home banking, не существует, но обычно процедура дистанционного управления финансами включает в себя:
- загрузку списка банковских счетов;
- загрузку списка кредитных карт;
- переводы денежных средств;
- клиентские платежи;
- бизнес-платежи.
На базе этого механизма работают многие системы электронного банкинга и онлайновые биржи. Примеры стандартов: Bank Internet Payment System (BIPS), Homebanking Computer Interface (HBCI), Open Financial Exchange (OFX).
соглашения о способах оплаты
В электронной среде, так же, как и в реальной, существует необходимость соглашения между плательщиком и получателем о том, какой именно инструмент они собираются использовать для проведения платежных транзакций. Этой цели служат специальные соглашения о способах оплаты. К их числу относятся протокол SET, позволяющий проводить платежные транзакции в зашифрованном виде цифровых подписей. Кроме того, для более мелких сумм используется Общая разметка для микроплатежей Common Markup for Micropayment Per-Fee, позволяющая производить оплату, "кликая" на определенную ссылку, содержащую идентификационную, организационную и финансовую информацию, необходимую для платежа. Система Jalda, также относящаяся к данной категории, ассоциирует клиента с конкретным аккаунтом, а платежи могут расти в зависимости от различных факторов (кликов мышки, запуска поисковой машины, затраченного времени и др.), и достигать любого сколь угодно малого или большого объема, включая и микроплатеж.
системы электронных денежных переводов
По сути данный механизм представляет собой обмен данными между двумя компьютеризированными системами, обрабатывающими финансовые транзакции и информацию о них. Аналогом этих систем в реальном мире могут служить системы для межбанковских расчетов, например, система SWIFT. Однако в электронной среде такие системы используются и для других платежей, в частности - для работы биржевых трейдеров и для home banking. Так как большинство таких систем использует EDI, примерами стандартов в данном случае могут служить UN/EDIFACT EDI Payment messages и SWIFT EDI Bank-to-Bank messages.
электронный бумажник
Электронный бумажник представляет собой приложение или службу, помогающую покупателям проводить онлайновые транзакции, храня информацию о выставленных счетах, доставке, и платежах, и используя эту информацию для заполнения контрольных страниц продавца. Электронные бумажники реализуются различными способами: как встроенные компоненты или вспомогательные приложения для броузеров, как отдельные клиентские приложения или в качестве серверных приложений. Тем не менее, несмотря на такое многообразие, все их можно разделить на две группы - клиентские и серверные. Соответственно этому делению, существует приложения, независимые от продавца, и приложения, работающие только с конкретным торговцем. Обычно предлагаемые электронные бумажники связаны с торговым порталом. В качестве примера стандартов в данной области можно назвать ECML - Язык разметки для электронной коммерции.
требования к платежным системам
требования по безопасности
Поскольку Интернет одновременно является и чрезвычайно эффективным коммуникативным средством и средой, вызывающей достаточно большое недоверие у пользователей, безопасность электронных платежей является весьма серьезным критерием успеха конкретной системы и использующего ее электронного бизнеса. Важно, чтобы при любой реализации в системе не оставалось плохо защищенных участков, способных привести к крупномасштабному мошенничеству. Поэтому основными требованиями по безопасности здесь являются:
- исключения возможности списания средств с аккаунта плательщика третьими лицами; обеспечение возможности легитимного подтверждения плательщиком перед третьими лицами (например, судом) факта совершения платежа, его получения получателем и назначения данного платежа (например, получения товара надлежащего качества;;
- обеспечение возможности легитимного подтверждения получателем перед третьими лицами факта получения платежа и его назначения;
- обеспечение возможности легитимного подтверждения эмитентом факта проведения всех авторизованных транзакций по данному аккаунту действительным владельцем данного аккаунта;
- обеспечение гарантий, что перемещаемая с аккаунта сумма не будет украдена в момент передачи и попадет точно и исключительно по назначению;
- исключение возможностей подделки квитанций эмитента пользователям;
- обеспечение разрешения всех спорных вопросов между эмитентом и пользователями исключительно электронным образом с помощью сообщений с цифровой подписью;
- обеспечение возможности разрешения спорных вопросов между пользователями без участия эмитента; система в целом должна быть устойчива к мошенническим действиям, в том числе - в случае форс-мажорных обстоятельств;
требования по конфиденциальности
И Интернет в целом, и любые платежи всегда тесно связаны с понятием конфиденциальности. Поэтому необходимо, чтобы платежная система сама по себе не навязывала пользователям никаких нарушений конфиденциальности, а предоставление расширенной и дополнительной информации всегда оставлялось на усмотрение пользователя. Таким образом, требования по конфиденциальности включают в себя:
- исключение возможности получения информации о действиях пользователей сторонними наблюдателями;
- обеспечение необходимой степени анонимности плательщика для получателя платежа;
- исключение возможности получения эмитентом информации о назначении платежа;
- исключение возможности получения эмитентом информации о том, с каким из поступлений на аккаунт получателя связано каждое из списаний с аккаунта плательщика.
требования по реализации
Требования к реализации обычно направлены на простоту и надежность работы системы, поскольку отказы в таких решениях могут привести к большим финансовым потерям сторон. Требования по реализации обычно заключаются в следующем:
- Система должна быть простой - как с точки зрения пользователей, так и для разработчиков. Простота системы удешевляет и ускоряет ее реализацию и техническую поддержку, способствует расширению сообщества применяющих ее организаций и привлекает потребителей.
- Система должна базироваться на хорошо проверенной и надежной технологии, что также будет залогом простоты ее реализации и уверенности в достаточном уровне безопасности.
- Система должна иметь возможность работать с пользователями извне организации, использующей данную платежную систему, так как очевидно, что множество потенциальных пользователей не являются сотрудниками этой организации.
прочие требования
Помимо изложенных выше требований, к любой платежной системе применимы традиционные для любой онлайновой системы требования по гибкости, масштабируемости и эффективности.
способы реализации платежных систем
По принципам реализации электронные платежные системы также можно разделить на две основные категории: управляемые самим онлайновым продавцом и управляемые провайдером коммерческого сервера (CSP).
Первый путь предпочтительнее, если у вас достаточно ресурсов для самостоятельного управления такой системой, и вы предпочитаете сами принимать решения на каждом этапе реализации вашей системы. Этот путь сложнее с точки зрения разработки, но наиболее эффективен в плане стоимости, так как организация в этом случае экономит существенные средства на обработке платежей, которые часто, к тому же зависят от объемов продаж. Такая экономия может окупить все исходные вложения в реализацию собственной системы.
Обращение к услугам CSP имеет смысл при недостатке или недостаточной квалификации персонала с точки зрения реализации собственной платежной системы, а также при ограниченных объемах продаж, предполагающих достаточно небольшую комиссию за их обработку. Кроме того, CSP, как правило, имеют улучшенную защиту (что, тем не менее, следует подробно выяснить при обращении к конкретному CSP), а многие из них предлагают клиентам и услуги по web-дизайну. Однако если ваш CSP является одновременно и местным провайдеров Интернет-сервиса, есть вероятность, что ваш сайт окажется слишком медленным для посетителей, поскольку вы будете делить ресурс сервера со множеством местных dial-up-пользователей. Необходимо также учесть, какие из предлагаемых провайдером услуг вам нужны, а от каких вы можете безболезненно отказаться. И наконец, следует сказать, что оба способа не являются взаимоисключающими. Вы можете соединять их произвольным образом для максимизации прибыли. Однако, здесь необходимо учитывать, что столь неявные "поборы" за техническую поддержку существенно возрастают по мере усложнения сайта.
по материалам клуба знатоков DWH, OLAP и Internet
Сетевые решения. Статья была опубликована в номере 01 за 2002 год в рубрике технологии