Библиотека Интернет Индустрии I2R.ru

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

Присутствующие сегодня на рынке электронные платежные системы можно разделить на ряд категорий - как по поставщикам, так и согласно особенностям реализации. Каждая категория имеет своих лидеров и аутсайдеров, но пока ясно, что компаний, доминирующих на всем рынке в целом, еще нет, а наличные деньги, чеки и реальные кредитные карты широко используются параллельно своим электронным аналогам. Банки же традиционно осторожны к экспериментам с различными новыми решениями. Тем не менее, ожидается, что финансовые институты сыграют решающую роль в признании этих решений рынком электронных платежных систем. Актуальными пока остаются проблемы безопасности в электронных системах, традиционно являющиеся одним из ключевых вопросов финансового бизнеса (см. Журнал Клуба знатоков №№ 3 и 4 за 2001 год). Кроме того, для всех этих предложений пока не разработана жесткая система стандартов, которые так же повлияли бы на развитие и принятие электронных платежных систем. Пока организационная часть данной отрасли находится в стадии становления, и ее участки еще нуждаются в серьезной защите.

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

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

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






• Системы заранее оплаченных/текущих/отложенных платежей. Различаются в зависимости от того, в какой момент времени инициатор платежа полагает платеж завершенным и в какой момент времени средства действительно изымаются у плательщика. Заранее оплаченные платежи аналогичны платежам наличными, а текущие и отложенные платежи достаточно сходны по своей природе: в обоих случаях пользователю необходимо иметь некий "счет" в банке, и платеж всегда совершается путем пересылки некоторой "формы" от плательщика получателю (чека, слипа кредитной карты, др.). Их даже можно объединить в единую систему платежей, аналогичных чекам. Таким образом, мы подходим к еще одной возможной классификации…



• Системы - аналоги наличных денег и системы - аналоги чеков. Однако деление электронных платежных систем на две эти группы было в ходу в 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, не существует, но обычно процедура дистанционного управления финансами включает в себя:

• загрузку списка банковских счетов;
• загрузку списка кредитных карт;
• переводы денежных средств;
• клиентские платежи;
• бизнес-платежи.

Соглашения о способах оплаты
В электронной среде, так же, как и в реальной, существует необходимость соглашения между плательщиком и получателем о том, какой именно инструмент они собираются использовать для проведения платежных транзакций. Этой цели служат специальные соглашения о способах оплаты. К их числу относятся протокол 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-пользователей. Необходимо также учесть, какие из предлагаемых провайдером услуг вам нужны, а от каких вы можете безболезненно отказаться.

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