Ни для кого не секрет, что существует известный набор электронных платёжных систем:

- 2CheckOut
- 2Checkout. Version 2
- 3Delta Systems
- A1M Platform
- AccessPoint (MerchantManager)
- ANZ eGate
- AsiaDebit
- AuthorizeNet.eCheck
- AuthorizeNet: AIM
- AuthorizeNet: SIM
- Bank of America
- Bean Stream
- BiBiT
- BluePay
- Caledon
- Cambist
- Cardia
- Cardia Shop 2.0
- Censeo (dialog)
- Censeo (no dialog)
- CentiPaid
- Clear Commerce (PayFuse)
- CyberCash
- CyberPac (LaCaixa)
- CyberSource
- DataTrans
- DeltaPAY
- DirectOne
- Direct Payment Solution: PX POST
- DPI Link (Server based solution)
- DPI Link. Hosted payment page
- E-Dinar
- E-Gateway (Mantis Technologies)
- E-Gold
- EasyPay
- ECHOnline
- EFSnet
- ePDQ
- Epoch Systems
- eProcessingNetwork. Transparent.
- eSec.Direct
- eSec.ReDirect
- eSelect plus
- eWAY.Shared payment
- eWAY.XML payment
- Ezic. Direct mode V3.x
- EZTP
- FirePay
- GestPay
- GlobalCommerce
- GoChargeIt
- GoEmerchant
- GoEmerchant XML
- GZS:PayMaster
- HSBC Secure E-Payment Service
- iDeb
- Innovative E-Commerce
- IntelliPay: ExpertLink
- InternetSecure
- IO*NGATE
- iTransact (ProcessUSA). XML scheme
- Jettis
- LinkPoint (Card Service International)
- Lynk Systems
- Money Bookers
- MultiCards
- MultiPay
- NetBanx
- Netbilling
- NetPay
- NetRegistry e-commerce
- Nochex
- Ogone
- Ogone (web)
- Pasat Internet
- PayBox
- PayByCheck
- PayByCheck.XML
- PayGate
- PayGateway
- Payment Resources Int
- PayNet
- PayPal
- PaySystems
- PaySystems Client
- PayWeb
- PayZip.Net: Server2Server
- PayZip.Net: Web2Web
- PlugnPay. Remote Auth method
- PlugnPay. Smart Screen method
- PRI. POST Interface
- PRI. WEB Interface
- PRI. XML Interface
- Protx VSP Direct
- Protx VSP Form
- ProxyPay3
- PSiGate
- PSW Billing
- RTWare: ADC Direct Response
- Saferpay
- Scopus Tecnologia
- SECPay
- SecurePay
- SECURETRADING
- SkipJack
- Slim CD
- Smart people
- SmartPag
- SurePay
- Triple Deal
- Trolley Gateway
- TrustCommerce
- USAePay
- uSight
- VaultX
- Velocity Pay
- VeriSign Link
- VeriSign PayFlow Pro
- viaKlix
- viaKlix 2.0
- Way2Pay
- WebCraft
- Wells Fargo
- World Swift
- WorldPay
- WTSbank
- YellowPay
- YourPay
- ZipZap


ВОПРОС
--------------------------------------------
Кто нибудь работал с унивирстальной библиотекой, позволяющей прикрутить ХОТЯ БЫ ОСНОВНЫЕ ИЗ НИХ, к софту (включая обработку платежей, исключений, проверки и т.п., а не тупую отсылку данных, хотя подойдёт и это )?
--------------------------------------------

может pecl?
http://pecl.php.net/packages.php?catpid … me=Payment
сам не пробовал, но там и с киберкеш есть, и трасткоммёрс =)

да список внушительный..

Сейчас на работе работаю с LinkPoint. Простая пересылка данных.

Плюс:
1. Голова не болит, потому что у себя в БД не хранишь номера кредитных карточек, а значет не отвечаешь за их безопастность и конфеденциальность.

2. Клиент доверяет серцифецированному сайту.
(Хотя я как посмотрю, интернет коммерция так развилась, что люди вписывают свои номера куда угодно.) Но главное иметь SSL протокол.
(по этому поводу много звонков было, люди спрашивали почему они не видят "замочек" на своем броузере.)

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



LinkPoint - там все простейше. Кажется можно сделать так, что клиент вообще не увидет никакого LinkPoint'a.

PayPal - имею аккаут, побаловался, но ничего серьезного не делал.
популярен среди e-bay продавцов. Непонравилось то, что покупатель первый раз должен зарегистрироваться там. Без регистрации нельзя просто оплатить. (вроде так было)

ViaKlix - пробовал, чего то не очень понравилось. Не очень гибкая система. Может плохо пробовал. Но вижу в списке появилась viaKlix 2.0

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

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

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

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

1. Отсылаешь им данные методом POST
2. Сервис снимает деньги и переводит на твой счет
3. Получаешь данные (методом POST) обратно на свою страницу.

Чаше всего получаешь в добавок кучу переменных, среди которых будет типа Transaction_Status

Если Transaction_Status:
Approved - показываешь страничку "спасибо", ставишь в свей БД галочку
Declined - показываешь страничку "сорри"
Fraud (optional) - берешь на заметку этого клиента, и не связываешься больше с ним.

Отсылать и принимать данные методом POST - ИМХО ненадо никаких библиотек. Это несложно ручками написать.
У большинства платежных систем - очень неплохой и подробный мануал. И не так сложно как кажется.
Самое главное выяснить, работает система с твоим банком.

PayPal, к примеру (при регистрации) шлет на твой счет несколько центов. После этого они ждут от тебя подтверждения (сколько ты получил). И только после этого регистрируют тебя как Verify Member.

Вообще, я вижу несколько путей при работе с платежными системами:

1.
Отсылаешь покупателя на платежную систему.
Он заполняет все формы там.
После транзакции он автоматически вернется на твой сайт (страничка "спасибо"). Это самое простое и безопастное для тебя.


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


3.
Можно собрать всю информацию + всю инфо о карточке на своем сайте и отослать ее самому методом POST.
Тогда покупатель не увидит платежной системы. Все будет происходить "за кулисами". Ему будет казаться, что он все время находился на твоем сайте.
При этом надо иметь в наличии SLL протокол (сертификат).
И почитать мануал насчет безопастности.
(инфо о карточке ты не сохраняешь в БД, а только отсылаешь со своего сайта)


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

Здесь нужно подумать:
1. доверяешь ли ты хостингу, где твоя БД лежит
2. БД - закриптовать.
3. PHP скрипты скомпилировать тоже не помешает (особенно где лежат пароли)
4. И самое главное от законодательства страны:
несешь ли ты ответсвенность, если хакеры взломают твою БД.

AlexShop писал(а):

4. И самое главное от законодательства страны: несешь ли ты ответсвенность, если хакеры взломают твою БД.

Ух ты! А что есть и такое?

незнаю.. наверно нет. Это я так на всякий случай сказал.

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

P.S.
На микроволновках не зря пишут - "не сушите животных". Производители защищаются как могут.

Так и тут, подумать о себе никогда не помешает.

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

AlexShop писал(а):

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

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

может быть.. незнаю,
скорее так оно и есть.

может все это описывается в длинющих текстах, где надо галочку поставить (и которые никто так и не читает)?
Надо глянуть что они там пишут.

Xo6oT писал(а):

Ух ты! А что есть и такое?

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

Crazy писал(а):

Xo6oT писал(а): Ух ты! А что есть и такое? Если клиент откажется от платежа и банк или платежная система смогут доказать, что ты не предпринял необходимых мер обеспечения безопасности -- вполне можешь оказаться крайним.

На сколько я знаю в практике (по крайней мере США и Европа) такого еще не было. Хотя не исключаю такого. Плюс ко всему одно дело пропустить фраудовый заказ, а другое - что у тебя украли базу. Второе в принципе доказать оочень сложно, т.к. вероятность 99.9%, что кард холдер вбивал уже свою карту в другие сайты. Соответственно нужно проверять их все. А как проверять? Это вообще практически нерезрешимый вопрос. Т.к. уязвимости есть у всех и доказать, что база была выкрна именно у вас и именно при помощи определенной уязвимости - невозможно в принципе.
Кстати, если мне не изменяет память, владелец сайта не несет ответственности за то, что он пропустил фрауд. Т.к. лично он сам не снимал деньги со счета. Это сделал банк через специальный сервисЭ а он лишь сделал запрос.

Xo6oT писал(а):

На сколько я знаю в практике (по крайней мере США и Европа) такого еще не было.

Насколько ты знаешь?

Crazy писал(а):

Xo6oT писал(а): На сколько я знаю в практике (по крайней мере США и Европа) такого еще не было. Насколько ты знаешь?

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

Господа, вы конечно всё правильно говорите "выбирай, что больше тебе подходит и т.п.", но я выпускаю софтовые коробочные продукты И выбирать будут клиенты. Моя задача лишь предоставить им максимальную возможность выбора, вот для чего и ищу библиотеку

andygray писал(а):

Господа, вы конечно всё правильно говорите "выбирай, что больше тебе подходит и т.п.", но я выпускаю софтовые коробочные продукты И выбирать будут клиенты. Моя задача лишь предоставить им максимальную возможность выбора, вот для чего и ищу библиотеку

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

Xo6oT, читай внимательно:
я продаю _коробочные_продукты_. типо виндовз, слышал? мс блокнот, x-Cart etc.

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

читаем дальше. у меня продукт купило 100 клиентов. каждый организовал на базе моего софта сервис, продающий порно, музыку, отсканнированные тексты древних писаний и т.п. у каждого из них 1000 человек в день проходить через сайт. около 10К/сутки на все сто продуктов. 90% посетителей - штаты, остальные - западная европа.

читаем? каждый _мой_ клиент хочет обеспечить максимально удобный вариант оплаты для _своих_ клиентов. моя задача - дать ему эту возможность.

вывод напрашивается, или мне его формализовать самому?

andygray писал(а):

Xo6oT, читай внимательно: я продаю _коробочные_продукты_. типо виндовз, слышал? мс блокнот, x-Cart etc. допустим, я продаю систему, закрывающую для юзеров зоны на сайте (файлы и т.п.). я утрирую конечно. эта система делает две вещи - закрывает зоны и файлы и позволяет посетителям сайта клиента купить их. читаем дальше. у меня продукт купило 100 клиентов. каждый организовал на базе моего софта сервис, продающий порно, музыку, отсканнированные тексты древних писаний и т.п. у каждого из них 1000 человек в день проходить через сайт. около 10К/сутки на все сто продуктов. 90% посетителей - штаты, остальные - западная европа. читаем? каждый _мой_ клиент хочет обеспечить максимально удобный вариант оплаты для _своих_ клиентов. моя задача - дать ему эту возможность. вывод напрашивается, или мне его формализовать самому?

Мы походу друг друга не понимаем. Как мне кажется ты путаешь платежные системы с сервисами, обрабатывающими кредитные карты, коих в твоем списке 90%. Ты просто прикручиваешь свой мерчант акк к одной из систем (VeriSign, Authorize.NET, 2CheckOut) и деньги автоматом поступают на твой счет. Смысл использовать сразу несколько систем?

andygray писал(а):

я продаю _коробочные_продукты_. типо виндовз, слышал? мс блокнот, x-Cart etc.

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

Кстати, я не понял автору нужны все эти палежные системы для оплаты покуупок у него на сайте, или же для его клиентов в их разработках?

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

Xo6oT, как я и писал выше - для клиентов моих клиентов. Мои клиенты - это владельцы e-commerce ресурсов. Их клиенты - конечные покупатели. Так яснее?

andygray писал(а):

Crazy, коробка подразумевает _решение_, а не указание пути к нему

Да, я знаком с этим заблуждением.

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

andygray писал(а):

Crazy, коробка подразумевает _решение_, а не указание пути к нему Достаточное не всегда совпадает с необходимым и уж далеко с конкурентоспособным, что тоже приходится учитывать. Поэтому решение, когда владелец софта галочками включает поддерживаемые системы, а для его клиентов автоматически генерятся кнопки на покупку и т.п. - лучшее решение. Xo6oT, как я и писал выше - для клиентов моих клиентов. Мои клиенты - это владельцы e-commerce ресурсов. Их клиенты - конечные покупатели. Так яснее?

Да - теперь понятно

andygray писал(а):

фраза, вырванная из конекста, всегда будет вызывать эмоции и трактования

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

Господа! Я бы призвал вас не горячиться, а вернуться к вполне здравой мысли:

Цитата:

Для этого не нужно в коробку класть интерфейс ко всем платежным системам. Достаточно положить в коробку API и документацию для написания/подключения адаптеров

- andygray, давайте попробуем без эмоций с этого момента?

Акела писал(а):

Господа! Я бы призвал вас не горячиться, а вернуться к вполне здравой мысли: Цитата: Для этого не нужно в коробку класть интерфейс ко всем платежным системам. Достаточно положить в коробку API и документацию для написания/подключения адаптеров - andygray, давайте попробуем без эмоций с этого момента?

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

Акела писал(а):

Господа! Я бы призвал вас не горячиться

Лично мне -- просто интересно, как же именно была понята моя фраза.

(сократил текст)

andygray,
врятли есть такая библиотека.
Я бы посоветовал бы вам выбрать парочку популярных платежных сервисов и самому ручками все написать. Это будет по силам.


Вся работа состоит в том что бы сделать "Спасибо" страничку.
Потому что отправить покупателя на платежную систему (ПС) - для этого много ненадо (просто сделать линк на нужную ПС).
А вот принять обратно данные (переменные), распознать их и записать результат в свою БД - в этом есть задача.

Я вижу два пути.
1. Либо все переменные описать в "Спасибо" страничке.
2. Либо сделать абстрактный класс - где владелец е-магазина сам читает мануал и сам назначает названия переменным в удобном интерфейсе. В таком случае, если с умом подойти, мне кажется можно работать с любой ПС (которая работает по этому принципу).

В любом случае, владелец магазина должен зайти в контрольную панель ПС и прописать пару вещей:
1. страница Referrer (откуда от приходит на ПС)
2. где находится "Спасибо" страничка.
То есть, полным чайником владелец магазина быть не может. Он все равно должен разбираться немного в ПС.

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

Либо самое лучшее
Делаешь абстрактный класс - и хранишь все названия переменных удобным способом (в массиве)

К примеру:

Paypal
переменная: result
Значения: Approved, Declined, Fraud

Linkpoint
переменная: transaction_result
Значения: YES, NO, BAD

Worldpay
…..

и т.д.

AlexShop, пока все ругаются, давайте поговорим. Мне очень интересна эта тема. Не могли бы Вы привести для всех четырёх упомянутых Вами пунктов наиболее типичные примеры. Я не очень хорошо разбираюсь в этой теме и был бы очень благодарен за такие пояснения.

тоже самое делаешь с датой платежа, именем покупателя, адрес.

Paypal
переменная: customer_first_name

Linkpoint
переменная: first_name

Worldpay
переменная: billing_name1

Ты должен знать
1. как все эти переменные называются,
2. принять их методом POST на страничке "Спасибо"
3. Корректно записать их в БД

В этом есть основная задача.

AlexShop, это понятно. Можно разницу по способам, разделённым Вами же на четыре разные пути работы с системаи? Про переменные не надо, я догадаюсь, интересен принцип в Вашем понимании.

Акела писал(а):

AlexShop, пока все ругаются, давайте поговорим. Сне очень интересна эта тема. Не могли бы Вы привести для всех четырёх упомянутых Вами пунктов наиболее типичные примеры. Я не очень хорошо разбираюсь в этой теме и был бы очень благодарен за такие пояснения.

п1.
Любой продавец на Ebay - который пользуется Paypal.
Все данные вводятся на PayPal сайте.
или например Ulead.com


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

п3, п4
Любой магазин, где вводишь данные прямо на сайте и ты не видишь самой ПС. Но так как ты этого не видишь - это не значит что ты там не присутствовал.

если взять например большие сайты Corel, Amazon.com - то там наверняка они сами снимают деньги без ПС.

Но например в LinkPoint - есть возможность собрать все данные, самому передать. И после этого тебя сразу перебрасывают на страничку "спасибо" или "извините".
А самого LinkPoint не видно. Только броузер будет думать дольше обычного. И никто не догадается что LinkPoint снимает деньги, если не посмотреть куда ведет <form action=… >
(конечно, позднее это отобразится на ежемесячной распечатке из банка).

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

(извиняюсь если сумбурно написано.. )