Проектирование модуля приема платежей в электронном магазине через ПИС WebMoney

  • Вид работы:
    Дипломная (ВКР)
  • Предмет:
    Информационное обеспечение, программирование
  • Язык:
    Русский
    ,
    Формат файла:
    MS Word
    787,21 Кб
  • Опубликовано:
    2012-11-12
Вы можете узнать стоимость помощи в написании студенческой работы.
Помощь в написании работы, которую точно примут!

Проектирование модуля приема платежей в электронном магазине через ПИС WebMoney














Проектирование модуля приема платежей в электронном магазине через ПИС WebMoney

Содержание

Введение

Аналитическая часть

1.1Экономическая сущность задачи автоматизации приема электронных платежей в системах интернет-магазинов

1.2.Характеристика комплекса задач, задачи и обоснование необходимости автоматизации

1.2. Выбор комплекса задач автоматизации и характеристика существующих бизнес процессов. Определение места проектируемой задачи в комплексе задач

1.2.2. Обоснования необходимости использования вычислительной техники для решения задачи

1.3 Развёрнутая постановка целей, задачи и подзадач автоматизации

1.3.1 Цели и назначение автоматизированного варианта решения задачи

1.3.2 Общая характеристика организации решения задачи на ЭВМ

Проектная часть

2.1 Информационное обеспечение задачи

2.1.1 Информационная модель и её описание

2.1.2 Используемые классификаторы и системы кодирования

2.1.3 Характеристика нормативно-справочной и входной оперативной информации

2.1.4 Характеристика базы данных

2.1.5 Характеристика результатной информации

2.2 Программное и технологическое обеспечение задачи

2.2.1 Общие положения программного обеспечения

2.2.2 Схема взаимосвязи программных модулей

2.2.3 Схемы технологического процесса сбора, передачи, обработки и выдачи информации

Заключение

Список использованной литературы

Приложение 1. Параметры обеспечения работы сервера интернет-магазина со службой WebMoney

Введение

Электронная коммерция - это дистанционная продажа/продвижение товаров и услуг с помощью современных средств связи, в частности - через глобальную сеть Интернет. Стремительное развитие Интернет позволяет смоделировать любой тип систем, а также построить принципиально новые решения, поддерживающие и облегчающие принципы электронной коммерции. Это делает Интернет наиболее перспективным средством произведения торговых операций. В совокупности с протоколами HTTP, CGI, языками JavaScript, SQL, мультимедийными технологиями Macromedia, Adobe и рядом других технологий, Интернет предоставляет поистине неограниченные возможности для создания операций купли-продажи товаров посредством электронной коммерции. Именно поэтому в данной сфере использования всемирной сети в настоящее время уделяется всё большее внимание. Производя выбор товара, покупатель имеет возможность подробно ознакомиться с предложенным выбором товаров, а так же с подробным описанием товара и его функциональными особенностями. Так же покупатель имеет возможность осуществить поиск по всей базе товаров и выбрать подходящий для себя товар посредством задания подробных параметров поиска. После выбора товара покупатель может занести его в корзину покупок и осуществить новый поиск другого товара. Впоследствии пользователь может заказать сразу все товары из корзины, которые будут ему доставлены в ближайшее время. К достоинствам методов электронной коммерции перед обычными магазинами можно отнести то, что просмотр, выбор и покупка товара осуществляется, не выходя из дома.

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

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

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

Таким образом, для представленной курсовой работы определены объект, предмет и цель исследования.

Объектом исследования является система оплаты товаров в интернет-магазинах с использованием ПИС WebMoney.

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

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

Аналитическая часть

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

Осуществление продаж через Интернет - одна из сторон электронной коммерции. Все системы торговли через Интернет можно классифицировать как web-витрины, Интернет-магазины и Торговые Интернет Системы (ТИС). На сегодняшний день в России преобладают web-витрины, Интернет-магазины и ТИС пребывают в меньшинстве. Web-витрина представляет собой совокупность каталога, системы навигации и оформления заказа (с последующей передачей менеджеру для дальнейшей обработки), т.е. при помощи web-витрины организовывается торговля на заказ. Интернет-магазины и ТИС могут осуществлять полный торговый цикл в онлайновом режиме, но ТИС дополнительно полностью интегрирована в систему автоматизации внутреннего документооборота компании [15].

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

Представим концепцию информационных потоков при функционировании типового интернет-магазина с физической доставкой товара, связанную с обслуживанием и регистрацией поступающих заказов. Рассмотрим общий алгоритм работы менеджеров по обслуживанию заказов, который фактически никак не зависит от того, в какой форме собираются и обрабатываются информационные данные. Блок-схема алгоритма представлена на Рисунке 1.1 [23]:

Рис. 1.1. Схема взаимодействия покупателя с системой продаж интернет-магазина

Для наглядности представим схему обслуживания клиентов в системе типового интернет-магазина с физической доставкой товаров в нотификации IDEF0:

Рис. 1.2. IDEF0 модель формирования и исполнения заказа в интернет-магазине с физической доставкой товара

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

Одним из наиболее современных принципов организации ПИС является использование для организации расчетов так называемых электронных денег. Электронные деньги полностью моделируют реальные деньги. При этом эмиссионная организация - эмитент - выпускает их электронные аналоги, называемые в разных системах по-разному. Далее, они покупаются пользователями, которые с их помощью оплачивают покупки, а затем продавец погашает их у эмитента. При эмиссии каждая денежная единица заверяется электронной подписью, которая проверяется выпускающей структурой перед погашением. Главное отличие электронных денег от реальных состоит в том, что первые предоставляют, по сути, электронные денежные обязательства выпустившей их стороны, но настоящими деньгами с юридической точки зрения являться не могут. Применяющийся же термин «деньги» показывает, что электронные деньги в значительной степени наследуют свойства реальных наличных денег, главное из которых - анонимность, то есть на них не указано, кто и когда их использовал. Некоторые системы, по аналогии, позволяют покупателю получать электронную наличность так, чтобы нельзя было определить связь между ним и деньгами. Это осуществляется с помощью метода слепой подписи. Стоит еще отметить, что при использовании электронных денег отпадает необходимость в аутентификации, поскольку система основана на выпуске денег в обращение [27].

Общая схема платежа с помощью электронных денег представлена на рис. 1.3.

Рис. 1.3. Общая схема платежа с помощью электронных денег [28]

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

. Покупатель заранее обменивает реальные деньги на электронные.

. Покупатель перечисляет на сервер продавца электронные деньги за покупку.

. Деньги предъявляются эмитенту, который проверяет их подлинность.

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

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

Эмитировать электронные наличные могут как банки, так и небанковские организации. В России наиболее популярной системой электронных денег, обеспечивающая до 70% расчетов в системе электронной торговли, является система WebMoney.позволяет множеству различных продавцов одновременно оперировать в одной электронной платежной системе, взаимодействуя на основе универсальных денежных единиц, принимаемых в оборот любым из этих продавцов. Кроме продавцов, в системе существуют рядовые пользователи. Пользователями могут выступать юридические и физические лица или программные продукты, представляющие их, например, Интернет-магазины. С точки зрения продавца все пользователи системы полностью равноправны.

В системе WebMoney принципиально невозможен случайный или предумышленный обман любого участника платежной системы продавцом или другим участником благодаря тому, что каждая операция обязательно сопровождается электронными цифровыми подписями всех ее участников. Специальное программное обеспечение - «Кошелек» - фактически хранит (наряду с собственно электронными деньгами) договоры купли продажи, подписанные электронными цифровыми подписями участников операции. Денежные средства пользователя (покупателя или продавца) могут находиться на счете в банке системы WebMoney или непосредственно на компьютере пользователя в «Кошельке». Счет системы WebMoney может управляться только через Интернет при помощи того «Кошелька», с помощью которого он был открыт - сам банк не может управлять этим счетом. На владельца «Кошелька» накладывается полная ответственность за его сохранность как средства управления счетом и совершения сделок при помощи электронных денег. На денежные средства, находящиеся на счете, могут начисляться банковские проценты, например, как на депозитные счета [29].

Непосредственно электронные деньги в системе WebMoney появляются в момент перевода денег со счета системы на платежную книжку в «Кошельке» пользователя. Использование процедуры слепой подписи обеспечивает возможность пользователям платежной системы получать электронные денежные обязательства, которые не могут быть не признаны банком.

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

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

Рассмотрим более подробно, как происходит взаимодействие участников системы между собой, а также с самой системой [30]:

. Покупатель переводит деньги в банк системы, устанавливает на своем компьютере программное обеспечение электронного «Кошелька» и получает эмитированные банком цифровые сертификаты.

. Покупатель выбирает товар в электронном магазине и отсылает ему заказ.

. «Кошелек» продавца отсылает «Кошельку» покупателя требование об оплате, содержащее подписанный электронной цифровой подписью текст договора.

. «Кошелек» покупателя предъявляет своему владельцу текст договора. Если покупатель соглашается платить (при достаточном количестве денег у него), то «Кошелек» покупателя отправляет «Кошельку» продавца электронные деньги и подписанный электронной цифровой подписью покупателя договор.

. Банк, получив от него электронные деньги, проводит их авторизацию.

. В случае положительного результата авторизации банк зачисляет соответствующую сумму денег на счет продавца в системе WebMoney. Сообщение об этом передается «Кошельку» продавца вместе с электронным чеком для покупателя.

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

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

1.2 Характеристика комплекса задач, задачи и обоснование необходимости автоматизации

Фактически последовательность действий при приеме платежа через систему WebMoney на стороне back-офиса интернет-магазина в ручном режиме (т.е. без использования системы автоматизированного приема платежей) представляется в виде следующей последовательности действий [30]:

согласование заявки с клиентом

выставление счета

согласование способа оплаты заказа через ПИС WebMoney

оператор сообщает клиенту номер кошелька интернет-магазина в системе WebMoney

клиент переводит на электронный кошелек интернет-магазина оговоренную сумма

оператор осуществляет контроль поступления денежных средств на счета интернет-магазина

оператор передает данные по заказу в отдел выполнения заказов.

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

Сначала рассмотрим процедуры, реализуемые на стороне интернет-магазина при организации и проведении расчетов с клиентами в ситуации КАК ЕСТЬ, т.е. в случае отсутствия системы автоматизированного приема платежей клиентов, использующих для расчетов ПИС WebMoney. Отметим, что детализации подлежат два блока, представленных выше на рис. 1.2.: блок Подготовки счета для клиента и блок Контроля оплаты товара. Проведем декомпозицию схемы рис. 1.2. с целью определить весь комплекс задач, связанных с автоматизацией процессов обслуживания приема платежей в интернет-магазине с использованием ПИС WebMoney в части анализа двух указанных блоков IDEF0 модели.

Декомпозиция блока Подготовка счета для клиента представлена на рис. 1.4.

Рис. 1.4. Укрупненная схема основных бизнес процессов при формировании счета на оплату заказа в системе интернет-магазина в ситуации КАК ЕСТЬ (отсутствие автоматизированной системы приема платежей WebMoney )

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

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

общая сумма сделки

номер кошелька интернет-магазина, на которые следует перевести полную сумму сделки (как правило, это рублевый кошелек, но по запросу клиента оплата может производиться также в долларах США или же в евро)

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

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

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

Однако уже при реализации процессов, связанных с блоком Контроля оплаты заявок, на стороне сервиса интернет-магазина складывается ситуация, требующая активного участия сотрудников. Это связано с тем, что при оплате клиентами счетов через ПИС WebMoney данные об этом не поступают в базу данных интернет-магазина, но становятся доступными лишь в рамках работы с WebMoney Keeper в системе пользователя данной ПИС. Это означает, что контроль поступления денежных средств на кошельки WebMoney Keeper должен осуществляться операторами интернет-магазина обязательно вручную, как следствие, вручную же, на основании полученных через WebMoney Keeper данных, операторы должны вводить данные об оплате в базу данных интернет-магазина, затем в бухгалтерскую систему предприятия и передавать сведения об исполнении оплаченного заказа в службу доставки. Естественно, что подобная последовательность работ вызывает задержки при отгрузке, возможны ошибки при оформлении заказов и при внесении данных в бухгалтерский комплекс интернет-магазина.

Еще сложнее обстоит ситуация при оплате счета на стороне клиента. Рассмотрим её подробнее, проведя декомпозицию блока Оплата счета клиентом.

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

Рис. 1.5. IDEF0 модель оплаты заказа на стороне клиента

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

при выборе клиентом оплаты с использованием webMoney Keeper формировать счет на оплату с детализацией пунктов оплаты и прочих сведений, представляющих интерес для клиента

автоматически открывать на рабочем компьютере клиента используемый им Webmoney Keeper

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

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

.2.2 Обоснования необходимости использования вычислительной техники для решения задачи

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

Предлагаемый проект автоматизации позволит существенно упростить процесс работы по обеспечению автоматизированного приема платежей клиентов интернет-магазина с использованием электронных платежных систем, в частности, ПИС Webmoney, а именно обеспечит выполнение следующих принципиальных положений [13]:

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

существенно снизится среднее время по обслуживанию заявок клиентов

повысится процент оплаченных заявок

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

Снижаются необходимые для обслуживания интернет-магазина объемы живого труда сотрудников интернет-магазина.

Снижается временные затраты на работу с документами в базе данных интернет-магазина

Обеспечивается исчерпывающее хранение архива документов.

Упрощается процедура контроля исполнительной дисциплины.

Можно выделить следующие преимущества работы с автоматизированной системой приема платежей в системе Webmoney:

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

Снижаются затраты живого труда сотрудников на подготовку счетов на оплату заказов.

Повышается эффективность системы хранения данных в базе данных предприятия.

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

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

Эти преимущества весьма ощутимы, учитывая объем заявок и высокий процент оплаты заказов с использованием ПИС WebMoney (прежде всего со стороны юридических лиц). По предварительным оценкам, автоматизация работы по приему платежей, выполняемых через ПИС WebMoney, позволит сократить временные затраты на обслуживание системы интернет-магазина примерно на 12-15%. Кроме того, можно ожидать, что в результате автоматизации будут созданы условия работы на стороне клиента интернет-магазина, которые обеспечат рост количества оплаченных заявок с существующих 45% от числа размещенных до 55-60% от числа размещенных заявок с оплатой через через ПИС WebMoney, как это наблюдается в среднем в интернет-магазинах среднего размера (осуществляющих от 1000 до 10 тыс. торговых транзакций в сутки) [30].

В стандартном электронном магазине, в котором используется так называемая корзина товаров, пошаговый процесс оплаты покупки с использованием ПИС WebMoney должен выглядеть примерно так:

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

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

Клиент получает счет в своем WM Keeper и оплачивает его.

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

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

1.3 Развёрнутая постановка целей, задачи и подзадач автоматизации

.3.1 Цели и назначение автоматизированного варианта решения задачи

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

обеспечение повышения количества оплаченных через ПИС WebMoney заявок;

снижение затрат живого труда сотрудников интернет-магазина на формирование счетов на оплату и контроль оплаты заказов;

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

В результате внедрения автоматизированной системы приема платежей через ПИС WebMoney изменится схема обработки заявок и контроля платежей по ним, из неё выпадет целый блок работ. Новая схема «КАК ДОЛЖНО БЫТЬ» представлена ниже на рис. 1.6.

Рис. 1.6.IDEF0 модель обслуживания клиентов «КАК ДОЛЖНО БЫТЬ»

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

.3.2 Общая характеристика организации решения задачи на ЭВМ

При проектировании модуля автоматизированного приема платежей через ПИС WebMoney в основе системы должна лежать сложившаяся структура интернет-магазина. В основе программного комплекса интернет-магазина единственным вариантом программирования серверов для придания им динамичности в настоящее время определен подход, использующий технологию CGI (для исполнения скриптов могут использоваться при этом самые различные технологии: ASP, языки программирования серверов PHP, perl и др.). Будем далее предполагать, что технологически интернет-магазин организован именно по технологии CGI, а в качестве информационного хранилища данных используется база данных SQL. С помощью сценариев для сервера для организации работы магазина можно получить доступ к файлам, базам данных и другим ресурсам, хранимым на сервере, а также к централизованным ресурсам сервера, таким как электронная почта или факс-служба. [13].

Упрощённая схема магазина, функционирующего по технологии CGI, представлена на рисунке:

Рис. 1.7. Схема работы интернет-магазина - клиент - сайт, виртуальный магазин- используемый веб-сервер

Порядок работы с системой выглядит следующим образом:

Клиент (А) обращается к статическим HTML-страницам, расположенным на сайте (В).

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

На основе этих данных динамически формируются таблицы цен по секциям магазина и (пока ещё пустая) виртуальная корзина товаров клиента (А).

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

Интернет-магазин состоит из трех частей:

Интернет-каталог;

виртуальная корзинка и механизм авторизации покупателей;

справочная часть Интернет-магазина.

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


Рис. 1.8. Виртуальная покупательская корзинка [23]

Теперь определим технологию взаимодействия модуля приема платежей с серверной системой ПИС WebMoney. Отметим, что могут использоваться только те технологии, которые официально поддерживаются платежной системой. В настоящее время существует 3 способа автоматического приема WebMoney на сайте:Merchant Interface &Buy Interface

Выписка WM-счета с последующей проверкой оплаты. Реализуется с помощью XML-интерфейсов X1 и X3.

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

Автоматизация приема WM-платежей позволит:

) выполнять заказ моментально после его оплаты;

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

Общий принцип работы системы, использующей XML-интерфейсы для установления связи с платежным сервером системы WebMoney, WebMoney, представлен на рис.1.9. На сайте интернет-магазина формируется необходимая информацию о заказе (точка А) и система отправляет ее на адрес автоматизированной обработки интернет-платежей в системе WebMoney по адресу https://merchant.webmoney.ru (т.н. Мерчант-сервер). Одновременно с этим и покупатель попадает на этот сайт для совершения платежа. Мерчант-сервер авторизует покупателя, предлагает выбрать способ оплаты, проверяет наличие нужной суммы на кошельке или WM-карте, т.е. проводит ряд необходимых идентификаций и проверок. После этого Мерчант-сервер списывает WM с кошелька или карты покупателя. В тот же момент уплаченная сумма поступает на кошелек интернет-магазина. Мерчант-сервер уведомляет сайт интернет-магазина о том, что покупка успешно произведена или о том, что возникла какая-либо ошибка (точка D).

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

Рис.1.9. Схема взаимодействия сайта интернет-магазина с Мерчант

сервером

Рассмотрим более детально все этапы соединения по протоколу http с Мерчант-сервером системы WebMoney

. Формирование запроса клиентом. (Браузер формирует запрос из URL, набранного пользователем, из щелчка на ссылке либо из данных формы.)

. Установка соединения с сервером. (Если установить соединение не удается, то на этом HTTP-транзакция закончится и клиент выдаст пользователю сообщение об ошибке.)

. Посылка запроса и ожидание ответа от сервера. (Все, что требуется от клиента, это чтобы запрос был в корректном формате.)

. Сервер принимает запрос. (Об этом и следующем этапе клиенту ничего не известно.)

. Сервер обрабатывает запрос.

. Генерация ответа.

. Прием ответа клиентом.

. Разрыв соединения.

. Обработка данных клиентом. (Вывод или сохранение данных.)

При установке соединения с сервером сначала происходит трансляция символьного доменного имени в IP-адрес, а затем осуществляется непосредственно создание TCP/IP-соединения с данным IP. Когда данные HTTP-запроса посланы серверу, клиент просто ожидает, пока не придет ответ. Пока нет обращений от клиентов, сам HTTP-сервер просто «спит» в ожидании запросов. После того как сервер выдал ответ, он разрывает соединение и вновь «погружается в сон». Естественно отметить, что в случае возникновения ошибки HTTP-транзакция может закончиться на любом из этих этапов.

Все девять этапов HTTP-соединения показаны на рис. 1.10.

Рис. 1.10. Этапы HTTP-соединения при запросе htm страниц на Мерчант-сервере ПИС WebMoney

Схема взаимодействия «клиент-сервер» для случая, когда URL указывает на CGI-обработчик, показана на рис. 1.11. [17, стр. 122]

Рис. 1.11. Этапы HTTP-соединения при обращении к CGI-скрипту

Проектная часть

.1 Информационное обеспечение задачи

.1.1 Информационная модель и её описание

Работа программного комплекса автоматического приема платежей клиентов через ПИС WebMoney естественным образом распадается на две составляющие:

. обслуживание базы данных и выполнение запросов к данным

. формирование динамических html-страниц и обмен данными с пользователями.

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

После того как покупатель определился с номером заказа и с тем, сколько и за что он готов заплатить, ему предлагается произвести оплату в WebMoney Transfer со своего электронного кошелька через cервис Мерчант WebMoney.

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

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

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

Источником данных для обеспечения работы модуля автоматизированного приема платежей в интернет-магазине служит SQL-база данных магазина, в которой происходит накапливание всей оперативной и нормативно-справочной информации по работе магазина. Кроме того, необходимо добавить в базу отдельную таблицу, в которой будет сохраняться специфическая для расчетов через ПИС WebMoney информация: номера кошельков клиентов, отклики Мерчант-сервера и т.п. Источниками данных являются внешние пользователи - клиенты интернет-магазина, использующие для расчетов ПИС webMoney, и передающие в систему по различным каналам (прежде всего - через интернет) информационные файлы и заполняющие предложенные экранные формы.

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

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

 

Рис. 2.1. Схема данных программного модуля приема платежей

2.1.2 Используемые классификаторы и системы кодирования

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

Данные системы интернет-магазина представляют собой хранящиеся в SQL-базе данных сведения о:

товарах, их описания и цены

товарных категориях, их описания

пользователях интернет-магазина (зарегистрированных)

сформированных корзинах товаров в связи с пользователями

проведенных платежах за товары

отгрузке товаров по уже оплаченным счетам.

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

Однако необходимость работы с ПИС WebMoney подразумевает использование некоторых соглашений, которые будут описаны ниже. Основными позициями, используемыми при обмене данными с webMoney merchant, являются [30]:

LMI_PAYMENT_AMOUNT - Поле, которое содержит сумму платежа. Дробная часть отделяется точкой.

LMI_PAYMENT_DESC (или LMI_PAYMENT_DESC_BASE64) - Поле, которое содержит примечание платежа. Должно содержать текст, желательно - наименование товара или услуги, которая продается. Максимальная длина - 255 символов.

LMI_PAYEE_PURSE - кошелек интернет-магазина. Должен состоять из буквы (Z-, R- и т.д.) и 12 цифр. По значению этого поля Мерчант распознает, в пользу какого продавца (иначе говоря, на чей кошелек) производится платеж.

Заметим, что поля LMI_PAYMENT_AMOUNT, LMI_PAYMENT_DESC, LMI_PAYEE_PURSE должны называться именно так, и никак иначе. При этом поля LMI_PAYMENT_AMOUNT и LMI_PAYEE_PURSE являются обязательными.

Поле id - содержит id выбранного покупателем товара. Берется из таблицы Товары.

Поле email - покупатель указывает здесь свой email.

LMI_PAYMER_NUMBER - номер WM-карты или чека Paymer, если покупатель выбрал оплату WM-картой.

LMI_PAYEE_PURSE - кошелек продавца, на который покупатель совершил платеж.

LMI_HASH - контрольная подпись.

LMI_SYS_TRANS_DATE - дата и время совершения платежа с точностью до секунд.

.1.3 Характеристика нормативно-справочной и входной оперативной информации

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

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

Таблица Товары (реальное название может быть произвольным, в зависимости от системы организации магазина), содержащую обязательные сведения о товаре:

идентификатор (id - обязательный)

наименование

категория (если используется)

артикул (если используется)

стоимость

количество на складе (если используется)

способ доставки (если используется)

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

идентификатор клиента

ФИО

электронный адрес (поле email - обязательный)

телефон для связи (если используется).

Для поkля ФИО (имя и фамилия покупателя соответственно) определена максимальная длина поля 127 символов, этого должно быть достаточно для большинства потенциальных покупателей, излишнее увеличение связано с тем, что иногда пользователи вводят и имя, и фамилию в одном поле.

Поле Email определено длиной 64 символа. Возможно, это излишне, так как большинство адресов не превышают 15-30 символов, но представим, что кто-то с очень длинным адресом захочет купить товар в этом магазине. В случае с информацией о покупателях лучше перестраховаться и предусмотреть такую возможность. Поле Phone (номер телефона для подтверждения заказа) используется для хранения как номера телефона, так и кода города/страны (например, 7-(812)-312-00-00), если пользователь ввел эту информацию.

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

Эти данные являются основой для функционирования Корзины, описываемой таблицей Корзина:

текущий IP покупателя

SessionKey - уникальный код для авторизации

идентификатор выбранных товаров

способ доставки

способ оплаты

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

текущий IP покупателя

SessionKey - уникальный код для авторизации

LMI_PAYMENT_AMOUNT - сумма платежа, которую оплачивает покупатель.

LMI_PAYER_WM - WMID покупателя.

LMI_PAYMER_NUMBER - номер WM-карты или чека Paymer, если покупатель выбрал оплату WM-картой.

LMI_PAYER_PURSE - кошелек покупателя, с которого он совершил платеж.

LMI_HASH - контрольная подпись..

LMI_SYS_TRANS_DATE - дата и время совершения платежа с точностью до секунд.

.1.4 Характеристика базы данных

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

Рис. 2.2. Модель логической структуры Интернет-магазина с модулем автоматического приема платежей

2.1.5 Характеристика результатной информации

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

Рассмотрим подробнее результаты выполнения cgi-запросов этих форм:

Форма запроса платежа

Эта форма передает запрос с веб-сайта продавца в сервис Web Merchant Interface через веб-браузер покупателя. Она должна имееть следующие атрибуты и поля:- https://merchant.webmoney.ru/lmi/payment.asp- POST- поля, передаваемые в форме

Фрагмент "Формы запроса платежа" без замены URL представлен ниже [29]:

<html>

<head> ... </head>

<body> ... <form method="POST" action="https://merchant.webmoney.ru/lmi/payment.asp">

<input type="hidden" name="LMI_PAYMENT_AMOUNT" value="12.08">

<input type="hidden" name="LMI_PAYMENT_DESC" value="платеж по счету">

<input type="hidden" name="LMI_PAYMENT_NO" value="1234">

<input type="hidden" name="LMI_PAYEE_PURSE" value="Z145179295679">

<input type="hidden" name="LMI_SIM_MODE" value="0">

<input type="hidden" name="FIELD_1" value="VALUE_1">

<input type="hidden" name="FIELD_2" value="VALUE_2">

... <input type="hidden" name="FIELD_N" value="VALUE_N">

... </form> .. </body>

</html>

Форма предварительного запроса

Эта форма передает продавцу параметры выполняемого платежа непосредственно перед его выполнением. Она имеет следующие атрибуты и поля:- Result URL- POST- поля, передаваемые в форме

Если флаг передачи параметров установлен, веб-сайт продавца должен вернуть сторку "YES" в ответе для того, чтобы сервис Web Merchant Interface смог продолжить выполнение платежа. Если веб-сайт продавца вернет что-либо другое - платеж выполнен не будет, а ответ будет показан покупателю в сообщении об ошибке.

Фрагмент html-кода для объекта "Формы предварительного запроса" представлен ниже:

<head> ... </head>

<body> ... <form method="POST" action="<Result URL>">

<input type="hidden" name="LMI_PREREQUEST" value="1">

<input type="hidden" name="LMI_PAYMENT_AMOUNT" value="1.0">

<input type="hidden" name="LMI_PAYEE_PURSE" value="R397656178472">

<input type="hidden" name="LMI_MODE" value="1">

<input type="hidden" name="LMI_PAYER_WM" value="809399319852">

<input type="hidden" name="FIELD_1" value="VALUE_1">

<input type="hidden" name="FIELD_2" value="VALUE_2">

... </form> .. </body>

</html>

Форма оповещения о платеже

Эта форма передает продавцу реквизиты выполненного платежа в момент его совершения. Она имеет следующие атрибуты и поля:- Result URL- POST- поля, передаваемые в формекод объекта "Форма оповещения о платеже" представлен ниже:

<html>

<head> ... </head>

<body> ... <form method="POST" action="<Result URL>">

<input type="hidden" name="LMI_PAYMENT_AMOUNT" value="1.0">

<input type="hidden" name="LMI_PAYMENT_NO" value="1">

<input type="hidden" name="LMI_PAYEE_PURSE" value="R397656178472">

<input type="hidden" name="LMI_MODE" value="1">

<input type="hidden" name="LMI_SYS_INVS_NO" value="281">

<input type="hidden" name="LMI_SYS_TRANS_NO" value="558">

<input type="hidden" name="LMI_PAYER_PURSE" value="R397656178472">

<input type="hidden" name="LMI_PAYER_WM" value="809399319852">

<input type="hidden" name="LMI_SYS_TRANS_DATE" value="20020314 14:01:14">

<input type="hidden" name="LMI_HASH" value="114128B8AEFD8CAA76D3CF75B9AEBC17">

<input type="hidden" name="FIELD_1" value="VALUE_1">

<input type="hidden" name="FIELD_2" value="VALUE_2">

... </form> .. </body>

</html>

Форма выполненного платежа

Эта форма передает реквизиты выполненного платежа на веб-сайт продавца после успешного выполнения операции. Данные передаются через веб-браузер покупателя только в том случае, если выбран метод вызова Success URL "GET" или "POST". Форма имеет следующие атрибуты и поля:- Success URL- метод вызова Success URL- поля, передаваемые в форме

Код объекта "Формы выполненного платежа" представлен ниже:

<html>

<head> ... </head>

<body> ... <form method="<метод вызова Success URL>" action="<Success URL>">

<input type="hidden" name="LMI_PAYMENT_NO" value="1">

<input type="hidden" name="LMI_SYS_INVS_NO" value="281">

<input type="hidden" name="LMI_SYS_TRANS_NO" value="558">

<input type="hidden" name="LMI_SYS_TRANS_DATE" value="20020814 14:01:14">

<input type="hidden" name="FIELD_1" value="VALUE_1">

<input type="hidden" name="FIELD_2" value="VALUE_2">

... </form> .. </body>

</html>

Форма невыполненного платежа

Эта форма передает реквизиты невыполненного платежа на веб-сайт продавца. Данные передаются через веб-браузер покупателя только в том случае, если выбран метод вызова Success URL "GET" или "POST". Она имеет следующие атрибуты и поля:- Fail URL- метод вызова Fail URL- поля, передаваемые в форме - такие же как и для выполненного платежа.

Код объекта "Формы невыполненного платежа" представлен ниже:

<html><head> ... </head>

<body> ... <form method="<метод вызова Fail URL>" action="<Fail URL>">

<input type="hidden" name="LMI_PAYMENT_NO" value="1">

<input type="hidden" name="LMI_SYS_INVS_NO" value>

<input type="hidden" name="LMI_SYS_TRANS_NO" value>

<input type="hidden" name="LMI_SYS_TRANS_DATE" value>

<input type="hidden" name="FIELD_1" value="VALUE_1">

<input type="hidden" name="FIELD_2" value="VALUE_2">

... </form> .. </body> </html>

При выполнении платежа Web Merchant Interface высылает оповещение о платеже через "Форму оповещения о платеже" на Result URL, указанный продавцом. Значение параметра "Secret Key" должно быть известно только сервису Web Merchant Interface и продавцу. Исходя из этого, Secret Key может использоваться для аутентификации источника, приславшего данные о платеже. Продавец, может провести аутентификацию несколькими методами в зависимости от того, обеспечивает Result URL секретность или нет:

Высылая оповещение о проведение платежа, сервис Web Merchant Interface передает реквизиты платежа и контрольную подпись, позволяющую проверять неизменность передаваемых данных. Продавец может выполнить проверку целостности в зависимости от того обеспечивает Result URL секретность или нет.

Контрольная подпись данных о платеже позволяет продавцу проверять как источник данных, так и целостность данных, переданных на Result URL через "Форму оповещения о платеже". При формировании контрольной подписи сервис Web Merchant Interface "склеивает" значения полей, передаваемых "Формой оповещения о платеже", в одну строку в следующем порядке:

Кошелек продавца (LMI_PAYEE_PURSE);

Сумма платежа (LMI_PAYMENT_AMOUNT);

Внутренний номер покупки продавца (LMI_PAYMENT_NO);

Флаг тестового режима (LMI_MODE);

Внутренний номер счета в системе WebMoney Transfer (LMI_SYS_INVS_NO);

Внутренний номер платежа в системе WebMoney Transfer (LMI_SYS_TRANS_NO);

Дата и время выполнения платежа (LMI_SYS_TRANS_DATE); Key (LMI_SECRET_KEY);

Кошелек покупателя (LMI_PAYER_PURSE); покупателя (LMI_PAYER_WM).

.2 Программное и технологическое обеспечение задачи

.2.1 Общие положения программного обеспечения

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

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

Рис. 2.3. Схема диалога при работе с модулем автоматизации платежей на стороне клиента

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

Рис. 2.5. Схема диалога модуля автоматического приема платежей на стороне ИС интернет-магазина

2.2.2 Схема взаимосвязи программных модулей

Для обеспечения приема WM на веб-сайте интернет магазина через сервис Web Merchant Interface необходимо выполнить два шага:

Создать 3 HTML страницы с внедренными PHP-кодами скриптов взаимодействия с мерчант-сервером - платежную страницу, страницу успешно выполненного платежа и страницу невыполненного платежа (pay.html, success.html и fail.html). Данные страницы содержат все ключевые элементы для обеспечения приема платежей через Merchant WebMoney на сайте интернет-магазина.

Настроить сервис Web Merchant Interface для обработки платежей, выполняемых клиентом на кошелек интернет-магазина. В результате будет реализована возможность приема платежей на выбранный кошелек и подтверждения о выполнении платежа покупателем на e-mail.

Для передачи информации между веб-сайтом продавца и сервисом Web Merchant Interface используются пять основных HTML-формы [См. 16]:

Форма запроса платежа - генерируется веб-сайтом продавца для формирования запроса на проведение платежа в сервисе Web Merchant Interface и передачи его через веб-браузер покупателя.

Форма предварительного запроса - генерируется сервисом Web Merchant Interface для передачи параметров предварительного запроса на выполнение платежа на веб-сайт продавца, если установлен флаг Передавать параметры в предварительном запросе. Если флаг не установлен - не используется (запрос выполняется без параметров). Запрос передается без использования веб-браузера покупателя.

Форма оповещения о платеже - генерируется сервисом Web Merchant Interface для передачи оповещения о платеже на веб-сайт продавца. Оповещение передается без использования веб-браузера покупателя.

Форма выполненного платежа - генерируется сервисом Web Merchant Interface в случае успешного выполнения платежа и передается на веб-сайт продавца через веб-браузер покупателя.

Форма невыполненного платежа - генерируется сервисом Web Merchant Interface в случае невыполнения платежа и передается на веб-сайт продавца через веб-браузер покупателя.

В интернет-магазине пошаговый процесс оплаты через Merchant WebMoney после внедрения модуля автоматизированного приема платежей будет выглядеть следующим образом:

После того как покупатель сформировал корзину товаров и определился с покупкой, на одном из этапов оформления заказа ему предлагается выбрать способ оплаты посредством WebMoney Transfer.

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

Клиент получает счет в своем WM Keeper и оплачивает его.

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

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

Помимо регистрации в WebMoney Transfer, для приема платежей через сервис Web Merchant Interface продавец должен настроить ряд параметров, регулирующих порядок приема платежей и оповещения продавца о факте проведения платежа. Полный перечень параметров и их назначение приведено в Приложении 1. Алгоритм выполнения платежа представлен на рисунке 2.6.

Рис. 2.6. Алгоритм взаимодействия модулей при выполнении платежа [См. 15]

.2.3 Схемы технологического процесса сбора, передачи, обработки и выдачи информации

Для использования Web Merchant Interface интернет-магазин (его WMID) должно иметь персональный аттестат. Перед началом использования модуля автоматизированного приема платежей на стороне интернет-магазина на странице Настройки нужно подключить к Мерчант-серверу кошелек и установить некоторые опции. Для этого напротив соответствующего выбираем опцию "настроить" и открываем страницу с настройками. Приводим ее ниже:

Рис.2.7. Установка настроек при подключении кошелька к Мерчант-серверу

Первое, что видит покупатель, попав на сайт сервиса Мерчант-сервера:

Рис.2.8. Первая страница сервиса Мерчант.

Здесь видно сумму будущего платежа, кошелек и WMID продавца, торговое имя и название товара или услуги.

Чтобы инициировать платеж, в точке А (см. рис.1.7) нужно передать Мерчант-серверу ряд параметров, для того чтобы он знал, какую сумму и в пользу какого продавца списывать с кошелька покупателя. Какие именно действия пользователя будут предшествовать точке А - решать дизайнеру интернет-магазина. Главное, когда покупатель нажмет кнопку в точке А и перейдет на Мерчант-сервер для оплаты, обязательно нужно иметь информацию об этом пользователе и его покупке. В интернет-магазине ООО «Меркатор» это решается следующим способом: Покупатель формирует "корзину покупок" и заполняет информацию о себе, а ваш сайт подсчитывает и сохраняет стоимость его заказа. Для этого используется в базе данных должна таблица с характеристиками товаров:

Нажав кнопку [Оплатить], покупатель попадает на следующую страницу:

Рис.2.9. Страница Мерчанта с выбором способа авторизации и оплаты

Здесь он выбирает способ оплаты - с Keeper Classic, Light. Авторизуемся Кипером Classic и попадаем на следующую страницу:

Рис.2.10. Страница Мерчанта с выбором кошелька.

Здесь покупатель выбирает кошелек, с которого будет списана стоимость покупки.

В случае, если Мерчант получил от Result URL ответ "YES", средства списываются с кошелька плательщика и тут же поступают на ваш. В случае получения другого ответа Мерчант прерывает платеж, средства с кошелька плательщика не списываются, а на экран выводится текст ошибки:

электронный платеж автоматический модуль

Рис.2.11. Мерчант получил от Result URL ошибку и прервал выполнение платежа.

После успешного платежа покупатель попадает на такую страницу:

Рис.2.12. Последняя страница Мерчанта после оплаты.

Это точка D схемы на рис.1.7. При нажатии на кнопку [Вернуться на сайт] Мерчант перенаправляет пользователя на Success URL. Этой странице Мерчант передает форму выполненного платежа, содержащую несколько "системных" параметров, а также все остальные "несистемные" параметры, которые были переданы Мерчанту еще в точке А в форме запроса платежа. В нашем случае это id и email.

Для детализации технологических процессов обработки информации в модуле автоматического приема платежей на стороне сервиса интернет-магазина составим в соответствии с исходными данными (дерево диалога и сценарий диалога) схему технологического процесса обработки информации:

Рис. 2.13. Схема технологического процесса обработки информации на стороне интернет-магазина. Работа с интерфейсом интернет-магазина. Часть 1.

Рис. 2.14. Схема технологического процесса обработки информации. Работа с интерфейсом интернет-магазина. Часть 2.

При организации работ с модулями М2 и М3 технологический процесс работы с информацией организуется аналогичным образом, схемы в основном идентичны приведенным на рис. 2.15. Основной интерес представляет работа с процессами более высокого уровня. Рассмотрим блок М1131, непосредственно связанный с проведением анализа поступивших платежей и направлением данных в обработку отделом доставки.

 

Рис. 2.15. Схема технологического процесса обработки информации. Модуль М113

Заключение

В представленной курсовой работе было осуществлено программное проектирование модуля автоматического приема платежей в составе комплекса электронной торговли интернет-магазина по продаже товаров с физической доставкой, организованного на базе SQL-базы данных с использованием cgi-технологии генерации динамических интернет-страниц на стороне сервера, осуществляемых с использованием платежных интернет-систем, прежде всего - ПИС WebMoney.

В первой главе настоящей курсовой работы были рассмотрены следующие вопросы:

. Проведен анализ системы работы типового интернет-магазина, анализ системы приема и обработки электронных платежей в ситуации КАК ЕСТЬ, т.е. без использования модуля автоматизации приема платежей.

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

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

В проектной части курсовой работы были решены следующие вопросы:

проведено проектирование информационной и даталогической моделей программного модуля автоматического приема электронных платежей ПИС WebMoney, описание входных, нормативно справочных и результатных информационных массивов функционирования модуля.

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

разработана технологическая схема процесса сбора, передачи, обработки и выдачи информации.

Таким образом, поставленные перед курсовым проектом задачи выполнены полностью, а цель курсового проектирования достигнута.

Список использованной литературы

ГОСТ 2.105-95. Единая система конструкторской документации. Общие требования.- Взамен ГОСТ 2.105-79, ГОСТ 2.906-71. Введ. 1.07.96.-М.: ИПК Издательство стандартов, 1996.-36с.

ГОСТ 19.791-01 (ИСО 5807-85). Единая система программной документации. Схемы алгоритмов, программ, данных и систем. Условные обозначения и правила выполнения.- Взамен ГОСТ 19.002-80, ГОСТ 19.003-80. Введ. 1.01.01.- М.: ИПК Издательство стандартов, 2001.-26с.

Аткинсон Л. MySQL. Библиотека профессионала, М., Изд-во O’Reilly, 2006, 316 стр.

Атре Ш. Структурный подход к организации баз данных. - М.: Финансы и статистика, 2003. - 320 с.

Атре Ш. Структурный подход к организации баз данных. - М.: Финансы и статистика, 2003. - 320 с.

Балабанов И.Т. - Торговля через виртуальный магазин /«Электронная коммерция»/ 2004г. С.195-197

Благодатских В.А. Экономика, разработка и использование программного обеспечения ЭВМ: Учебник.-М.: Финансы и статистика, 2002. - 288с

Васкевич Д. Стратегии клиент/сервер. - К: «Диалектика», 2006, 244 стр.

Григоренко Г.П., Данелян Т.Я. Системы автоматизированной обработки экономической информации (САОЭИ): Учебное пособие/Моск. эконом. - стат. ин-т. - М., 2002-126с.

Гурвиц Г. А. Разработка приложения в среде клиент-сервер, ДВГУПС 2005, 204 с.

Иванцов А.А., Серегин С.П., Программирование интерфейсов под Windows, DHV, СПб, 2006, 214 стр.

Имери В. Бизнес в Internet - технологические аспекты. - К.; М.; СПб., 2003. - 336 стр.

Информационные Системы в экономике: Учебник / Под ред. проф. В.В. Дика - Москва.:Финансы и Статистика, 1996. - 340 стр.: ил.

Карминский А. М., Нестеров П. В. Информатизация бизнеса. - М.: Финансы и статистика, 2007. - 416 с.: ил.

Куницына Л.Е. Информационные технологии и системы в экономике: Методический комплекс.- Ростов-на-Дону: РГЭА, 1998.-175с

Мамаев Е. В. Microsoft SQL Server 2005, СПБ.: Питер 2001, 1280 с.

Маргелов В.В., API-интерфейсы доступа к базам данных, М., Byte-reviews, М., 2003, 316 стр.

Мелюхин И. Электронные деньги и банковские операции в компьютерных сетях // Мировая экономика и международные отношения. - 2006. - С. 118-125

Паршенцев А.А. Проблема и перспективы развития электронных магазинов // Маркетинг в России и за рубежом. - 2005. - № 3. - С. 84-89

Пашутин Н.Ю., Архитектурные решения электронной коммерции, IT-Magazine, 2005, стр. 60-71

Проектирование экономических информационных систем: Учебник / Е.А. Петров, Г.М. Смирнов, А.А. Сорокин, Ю.Ф. Тельнов. - М.: Финансы и статистика, 2006 - 286 с

Сакун Ю. Электронная коммерция// ИнфоБизнес. - 2005. - №5. - С. 28 - 30

Симонович С.В. Язык структурированных запросов SQL, СПб «Питер», 2005.

Сухоруков А. Технологии работы CGI/СПб, BHV - 2003, 224 стр.

Шпагина М. Новое измерение PHP //IT. - 2006. - № 24

Юкович Н. Электронная торговля в глобальной сети // Домашний компьютер. - 2007. - №7 - 8. - С. 51 - 55://www.rbcnet.ru/publ/commerce/e-com-r.htm (по материалам доклада, подготовленного Американской Торговой Палатой в России при участии Торгово-Промышленной Палаты РФ), 2008 г..webmonet.ru/merchant/usr/index17.asp.webmonet.ru/merchant/usr/145668897/ew.asp

Приложение 1

Параметры обеспечения работы сервера интернет-магазина со службой WebMoney

Название параметра

Формат

Описание

Result URL

255 символов (case sensitive)

URL (на веб-сайте продавца), на который сервис Web Merchant Interface посылает HTTP POST или SMTP-оповещение о совершении платежа с его детальными реквизитами. Если продавец не определил этот URL, он не будет оповещаться сервисом о совершенных платежах. URL должен начинаться с префикса "http://", "https://" или "mailto:". В последнем случае оповещение будет высылаться на e-mail, указанный после префикса, - например, при указании mailto:shop@address.com оповещение будет выслано на e-mail shop@address.com).  При использовании префикса "http://" или "https://" сервис посылает оповещение по портам 80 и 443 соответственно. Причем вызов Result URL выполняется два раза. Первый раз непосредственно перед выполнением платежа (для проверки работоспособности веб-сайт продавца), второй раз сразу после успешного выполнения платежа (для передачи параметров платежа). При первом вызове, если установлен флаг Передавать параметры в предварительном запросе, параметры предаются с использованием Формы предварительного запроса. Если флаг не установлен - вызов идет без параметров. При втором вызове параметры передаются через Форму оповещения о платеже.

Success URL

255 символов (case sensitive)

URL (на веб-сайте продавца), на который будет переведен интернет-браузер покупателя в случае успешного выполнения платежа в сервисе Web Merchant Interface. URL должен иметь префикс "http://" или "https://".

Метод вызова Success URL

-

Метод (POST, GET или LINK), который будет использоваться при переходе на Success URL.

Fail URL

255 символов (case sensitive)

URL (на веб-сайте продавца), на который будет переведен интернет-браузер покупателя в том случае, если платеж в сервисе Web Merchant Interface не был выполнен по каким-то причинам. URL должен иметь префикс "http://" или "https://".

метод вызова Fail URL

-

Метод (POST, GET или LINK), который будет использоваться при переходе на Fail URL.

Метод формирования контрольной подписи оповещения о платеже

-

Алгоритм, который Web Merchant Interface использует для контроля подлинности оповещения, высылаемого на сайт продавца при выполнении платежа через сервис. Поддерживается два варианта: MD5 и SIGN (рекомендуется).

Тестовый/Рабочий режимы:

-

Флаг, устанавливающий режим обработки платежей в сервисе. В тестовом режиме Web Merchant Interface имитирует выполнение платежей (реально платежи не выполняются). По умолчанию выставляется тестовый режим.

Активность

-

Флаг, разрешающий или запрещающий прием платежей на кошелек продавца через сервис. Если флаг установлен в состояние "Выкл.", Web Merchant Interface во всех случаях будет сообщать покупателю о невозможности выполнения платежа.

Secret Key

50 символов (case sensitive)

Строка символов, добавляемая к реквизитам платежа, высылаемым продавцу вместе с оповещением. Эта строка используется для повышения надежности идентификации высылаемого оповещения. Содержание строки известно только сервису Web Merchant Interface и продавцу!

Высылать Secret Key на Result URL, если Result URL обеспечивает секретность

-

Флаг, сообщающий сервису Web Merchant Interface о том, что Secret Key должен быть добавлен к высылаемому на веб-сайт продавца оповещению о платежах в том случае, если канал обеспечивает безопасную передачу на Result URL (используется протокол SSL, то есть Result URL имеет префикс "https://"). Если Result URL не использует SSL, то Secret Key высылаться не будет, даже если флаг установлен.

Позволять использовать URL, передаваемые в форме

-

Флаг, оповещающий Web Merchant Interface о том, что Result URL, Success URL, метод вызова Success URL , Fail URL и метод вызова Fail URL могут быть изменены в "Payment Request Form".

Передавать параметры в предварительном запросе

-

Флаг, сообщающий сервису Web Merchant Interface о том, что в запросе передаваемом на Result URL веб-сайта продавца непосредственно перед попыткой выполнение платежа необходимо передать параметры через Форму предварительного запроса. В случае если флаг не установлен Предварительный запрос идет без передачи параметров. Если флаг передачи параметров установлен, веб-сайт продавца должен вернуть сторку "YES" в ответе для того, чтобы сервис Web Merchant Interface смог продолжить выполнение платежа. Если веб-сайт продавца вернет что-либо другое - платеж выполнен не будет а ответ будет показан покупателю в сообщении об ошибке.

Высылать оповещение об ошибке платежа на кипер

-

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

1.      

Похожие работы на - Проектирование модуля приема платежей в электронном магазине через ПИС WebMoney

 

Не нашли материал для своей работы?
Поможем написать уникальную работу
Без плагиата!