Написание собственной комплексной системы обработки платежей

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

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

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

На практике платежная система общается с банком-эмитентом и получает там авторизацию. Я думаю, что я мог бы использовать для этого простую таблицу БД с номерами счетов и балансом. т. е. достаточно ли у клиента денег или нет.

Я хочу, чтобы мое основное внимание в этом проекте было сосредоточено на написании бэкэнд-сервера, чтобы он был надежным и одновременно обрабатывал запросы. Я также хочу сосредоточиться на шифровании, безопасности и т. д. между клиентом и сервером. Я хотел бы изучить правила соответствия PCI и т. д.

Сейчас начало ноября, а крайний срок для всего проекта - середина марта 2012 года.

Что вы, ребята, думаете о моей идее, и как вы думаете, смогу ли я добиться чего-то стоящего, учитывая время?


person jim    schedule 04.11.2011    source источник
comment
Планируете ли вы также создать обработчик сообщений, совместимый с ISO 8583 (это ядро ​​задач авторизации)? Планируете ли вы также добавить поддержку 3DSec (VISA) или SecureCom (MSC)?   -  person BigMike    schedule 04.11.2011


Ответы (2)


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

Я бы предложил создать определение веб-службы с использованием IIS/.Net или Tomcat/JBoss/Java, чтобы определить, как будет работать ваша авторизация и расчет. Вы можете реализовать практически все, что требует PCI DSS, используя инструменты, доступные в основных библиотеках .Net/Java, без необходимости прибегать к сторонним библиотекам.

person Community    schedule 04.11.2011
comment
Хорошо, я немного почитал о PCI DSS. Мне бы очень хотелось написать что-нибудь совместимое, что, я думаю, принесет моему проекту серьезное признание. Мне не удалось найти какие-либо документы о требованиях к утвержденным программам. Любые документы, которые я нашел, были связаны с инфраструктурой продавцов и т. д. Любые ссылки на такие документы или какие-либо рекомендации? Спасибо. - person jim; 05.11.2011
comment
Вам нужно ознакомиться с PA-DSS (Стандарт безопасности данных платежных приложений, ранее известный как PABP). Это тип сертификации, который вам нужен, если вы являетесь издателем программного обеспечения, которое создает программное обеспечение для обработки кредитных карт. PCI-DSS, как вы видели, охватывает как программное обеспечение, так и инфраструктуру. - person ; 06.11.2011
comment
Круто, я обнаружил это вскоре после публикации моего последнего комментария. Похоже, это может быть достижимо. Спасибо за вашу помощь :) - person jim; 06.11.2011

Очень похожий вопрос возникал раньше, и я ответил здесь

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

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

Вместо этого я бы сосредоточился на проблемах, связанных с соответствием стандарту PCI-DSS. Шифрование данных карты — это самое простое. Написание системы безопасного управления ключами является гораздо более сложной задачей. Общая цель состоит в том, чтобы зашифровать данные вашей карты в базе данных и позволить вашим продавцам ссылаться на эти данные карты с помощью уникальных идентификаторов токенов. Это общая модель, которую адаптируют PSP, чтобы идентификатор токена мог безопасно передаваться вашим продавцам и от них, в то время как сами данные карты хранятся в безопасности и расшифровываются только во время связи с банком продавца (для авторизации/расчета и т. д.)

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

Удачи, это отличная идея с широким спектром возможностей.

person PaulG    schedule 16.11.2011