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

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

Рубрика Программирование, компьютеры и кибернетика
Вид дипломная работа
Язык русский
Дата добавления 16.12.2012
Размер файла 1,9 M

Отправить свою хорошую работу в базу знаний просто. Используйте форму, расположенную ниже

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

<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);

Secret Key (LMI_SECRET_KEY);

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

WMId покупателя (LMI_PAYER_WM).

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

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

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

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

Размещено на http://www.allbest.ru/

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

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

Размещено на http://www.allbest.ru/

Рис. 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.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.

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

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

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

Была сформулирована задача на разработку программного модуля приема и обработки электронных платежей ПИС 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

Баронов В.В. Автоматизация управления предприятием. - М.: ИНФРА-М, 2000. - 239 с., стр. 218

Благодатских В.А. Экономика, разработка и использование программного обеспечения ЭВМ: Учебник.-М.: Финансы и статистика, 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

http://www.rbcnet.ru/publ/commerce/e-com-r.htm (по материалам доклада, подготовленного Американской Торговой Палатой в России при участии Торгово-Промышленной Палаты РФ), 2008 г.

www.webmonet.ru/merchant/usr/index17.asp

www.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. Размещено на www.allbest.ru


Подобные документы

Работы в архивах красиво оформлены согласно требованиям ВУЗов и содержат рисунки, диаграммы, формулы и т.д.
PPT, PPTX и PDF-файлы представлены только в архивах.
Рекомендуем скачать работу.