Comments 51
Но в данный момент ни для России, ни для Украины платежи не доступны, толку с ней знакомиться?
24 сентября узнаем, доступны или не доступны :) Официально объявили, что это ошибка, но обе страны таки все еще находятся в списках.
На Хабре зарегестрированы пользователи не только из России или Украины (а так же работающие не только с этими двумя странами — в той же Европе данная система весьма популярна).
з.ы. Теги тащат.
з.ы. Теги тащат.
много людей из этих стран просят своих знакомых открыть карточку и отдать им. Или же сами при удобном случае открывают карту в инностранном банке. Потом работают с ней через пейпал.
Есть вариант получить карту от пайонера, карту вам они пришлют. А потом попробовать ее использовать в пейпал. Сам не пробовал, поэтому утверждать по поводу действенности данного метода не имею возможности.
Есть вариант получить карту от пайонера, карту вам они пришлют. А потом попробовать ее использовать в пейпал. Сам не пробовал, поэтому утверждать по поводу действенности данного метода не имею возможности.
Для России можно воспользоваться услугами платежных систем для оплаты PayPal.
Очень качественно оформленная статья. Да и тема думаю скоро будет очень актуальная.
Огромное спасибо за статью. Как раз занимаюсь внедрением системы платежей через PayPal для западного веб-магазина, теперь все стало гораздо понятнее. Была бы карма — плюсанул бы.
Согласен что у пейпала найужаснейшая документация. У того же плимуса почти те же возможности, но дока там на порядки качественнее и понятнее. А за статью спасибо — однозначно в избранное.
Спасибо, очень хорошая статья, но пока что для России не совсем актуально: Oplata.info гораздо удобнее. Количество российских пользователей PayPal пока что незначительно.
К сожалению автор статьи не до конца разобрался в вопросе. Учитывая тот факт, что еще часть нюансов пропала в процессе перевода, статья можнт скорее запутать, начинающего изучать PayPal API. Попробую прояснить некоторые моменты.
1. У PayPal есть три самых популярных API. Это Website Payments Standard, Express Checkout и PayPal Payments Pro.
Website Payments Standard – самый простой и массовый способ. Позволяет оплатить покупку как через PayPal аккаунт, так и кредитной картой(если PP аккаунта нет). В процессе оплаты переходим на сайт PayPal, там оплачиваем покупку и потом возвращаемся в магазин, где видим страницу подтверждения оплаты.
Этот API действительно прост. В своей простейшей форме нам нужно всего лишь отослать данные(email продавца, сумму и еще пару полей) POST запросом на PayPal. И всё.
Если же нам нужно узнавать о статусе платежа, то нужно использовать IPN: Instant Payment Notifications, PayPal шлет в бэкграунде нотификации об изменении статуса заказа.
Это самый распространенный способ принимать PayPal, поэтому непонятно почему статья начинает с более сложных штук, таких как Express Checkout.
Express Checkout: – более продвинутая штука. Требует или Premier или Business аккаунт.
Обычно используется интернет-магазинами, чтобы сделать процесс покупки более быстрым. Главный смысл такой: если у вас _уже_ есть PayPal аккаунт, то вам больше не надо заводить регистрации в магазине. Достаточно нажать на кнопку. Шаги примерно такие:
— жмем кнопку «Express Checkout by PayPal». Магазин делает запрос к PayPal, получает ссылку на которую нужно переслать клиента.
— Клиент переходит на сайт PayPal, где логинится с помощью своего PayPal аккаунта. Сразу же после этого он возвращается в магазин. На этом этапе никаких снятий денег еще нет.
— Магазин получает информацию о вернувшимся клиенте и, используя API, получает инфу о email и адресе доставки этого клиента.
— Клиент нажимает кнопку «Завершить заказ». Магазин посылает в бэкграунде API запрос к PayPal, деньги снимаются, потом магазин автоматически создает заказ, используя email и адрес доставки с предыдущего шага.
Плюсы для клиента очевидны: ему достаточно сделать 3 легкий шага для размещения заказа. Нажать кнопку «Express Checkout», залогинится в PayPal, нажать кнопку «Завершить заказ». Не надо вводить email, адреса и т.д.
Но у этого способа есть и минусы. Главный из которых, на мой взгляд, это то, что PP _требует_ иметь PayPal аккаунт, чтобы использовать Express Checkout. Надеюсь они это изменят в будущем. Другой минус: намного более сложная интеграция.
PayPal Payments Pro: данный способ используется для принятия кредитных карт. Т.е. пользователь даже может и не знать, что используется PayPal. Магазин берет данные кредитки, делает API запрос на PP в бэкграунде, получает ответ: снялись деньги или нет.
Выглядит просто, но есть одна тонкость.
— т.к. пользователь вводит кредитки на вашем сайте, то магазин обязан быть PCI-DSS cертифицирован. Если используется некий скрипт магазина(коммерческий или бесплатный), то этот скрипт должен быть также PA-DSS сертифицирован.
2.
Автор не прав, что эти API выполняют одну и ту же функцию. Mass Payments это штука, чтобы одновременно послать деньги куче людей. Например выплатить зарплату, отдать выигрыш победителям, выплатить комиссионные всем своим партнерам.
Adaptive Payments это же PayPal «на стероидах». Позволяет делать разные клевые штуки. Например вы это магазин-агрегатор, где разные мерчанты могут выкладывать свои товары. Например пользователь покупает товар от 2 _разных_ продавцов за общую сумму в $100 и идет оплачивать на PayPal. Можно сделать так, чтобы $100 сразу же распределились по PP аккаунтам продавцов, а вам перечислилсь комиссия.
3.
Наоборот. Если используется PayPal Pro или Express Checkout, то есть два типа авторизации:
— Подпись. Выглядит как строка с символами.
— Сертификат. Файл сертификата, который где-то у вас хранится.
Один аккаунт может быть настроен только на один тип авторизации. Как правильно сейчас все используют подпись, она банально удобнее.
4.
Как раз наоборот. «Прямой платеж», т.е. PayPal Pro, не требует от покупателя иметь PayPal аккаунт.
1. У PayPal есть три самых популярных API. Это Website Payments Standard, Express Checkout и PayPal Payments Pro.
Website Payments Standard – самый простой и массовый способ. Позволяет оплатить покупку как через PayPal аккаунт, так и кредитной картой(если PP аккаунта нет). В процессе оплаты переходим на сайт PayPal, там оплачиваем покупку и потом возвращаемся в магазин, где видим страницу подтверждения оплаты.
Этот API действительно прост. В своей простейшей форме нам нужно всего лишь отослать данные(email продавца, сумму и еще пару полей) POST запросом на PayPal. И всё.
Если же нам нужно узнавать о статусе платежа, то нужно использовать IPN: Instant Payment Notifications, PayPal шлет в бэкграунде нотификации об изменении статуса заказа.
Это самый распространенный способ принимать PayPal, поэтому непонятно почему статья начинает с более сложных штук, таких как Express Checkout.
Express Checkout: – более продвинутая штука. Требует или Premier или Business аккаунт.
Обычно используется интернет-магазинами, чтобы сделать процесс покупки более быстрым. Главный смысл такой: если у вас _уже_ есть PayPal аккаунт, то вам больше не надо заводить регистрации в магазине. Достаточно нажать на кнопку. Шаги примерно такие:
— жмем кнопку «Express Checkout by PayPal». Магазин делает запрос к PayPal, получает ссылку на которую нужно переслать клиента.
— Клиент переходит на сайт PayPal, где логинится с помощью своего PayPal аккаунта. Сразу же после этого он возвращается в магазин. На этом этапе никаких снятий денег еще нет.
— Магазин получает информацию о вернувшимся клиенте и, используя API, получает инфу о email и адресе доставки этого клиента.
— Клиент нажимает кнопку «Завершить заказ». Магазин посылает в бэкграунде API запрос к PayPal, деньги снимаются, потом магазин автоматически создает заказ, используя email и адрес доставки с предыдущего шага.
Плюсы для клиента очевидны: ему достаточно сделать 3 легкий шага для размещения заказа. Нажать кнопку «Express Checkout», залогинится в PayPal, нажать кнопку «Завершить заказ». Не надо вводить email, адреса и т.д.
Но у этого способа есть и минусы. Главный из которых, на мой взгляд, это то, что PP _требует_ иметь PayPal аккаунт, чтобы использовать Express Checkout. Надеюсь они это изменят в будущем. Другой минус: намного более сложная интеграция.
PayPal Payments Pro: данный способ используется для принятия кредитных карт. Т.е. пользователь даже может и не знать, что используется PayPal. Магазин берет данные кредитки, делает API запрос на PP в бэкграунде, получает ответ: снялись деньги или нет.
Выглядит просто, но есть одна тонкость.
— т.к. пользователь вводит кредитки на вашем сайте, то магазин обязан быть PCI-DSS cертифицирован. Если используется некий скрипт магазина(коммерческий или бесплатный), то этот скрипт должен быть также PA-DSS сертифицирован.
2.
Этот вариант в принципе выполняет ту же функцию, что и предыдущий, но с некоторыми отличиями (я вроде бы уже упомянул о том, что PayPal API запутанный и полный излишеств).
Автор не прав, что эти API выполняют одну и ту же функцию. Mass Payments это штука, чтобы одновременно послать деньги куче людей. Например выплатить зарплату, отдать выигрыш победителям, выплатить комиссионные всем своим партнерам.
Adaptive Payments это же PayPal «на стероидах». Позволяет делать разные клевые штуки. Например вы это магазин-агрегатор, где разные мерчанты могут выкладывать свои товары. Например пользователь покупает товар от 2 _разных_ продавцов за общую сумму в $100 и идет оплачивать на PayPal. Можно сделать так, чтобы $100 сразу же распределились по PP аккаунтам продавцов, а вам перечислилсь комиссия.
3.
Электронная подпись PayPal API. Параметр следует использовать только в том случае, если вы используете сертификат для авторизации;
Наоборот. Если используется PayPal Pro или Express Checkout, то есть два типа авторизации:
— Подпись. Выглядит как строка с символами.
— Сертификат. Файл сертификата, который где-то у вас хранится.
Один аккаунт может быть настроен только на один тип авторизации. Как правильно сейчас все используют подпись, она банально удобнее.
4.
Прямой платеж позволяет полностью контролировать весь процесс перевода средств прямо на вашем сайте. По какой-то непонятной причине, в этом случае покупатели без PayPal-аккаунта не смогут оплачивать услуги и товары на вашем сайте, но зато можно будет сделать весь процесс максимально простым, что положительно скажется на мнении пользователей.
Как раз наоборот. «Прямой платеж», т.е. PayPal Pro, не требует от покупателя иметь PayPal аккаунт.
Еб#ть…
Снимаю шляпу.
Но статью писал не я, я лишь перевел :) И лично я вынес из нее уже достаточно необходимой мне информации и понял принцип взаимодействия с PP.
Завтра все недочеты подправлю в соответствии с тем, что вы написали :)
Спасибо за столь подробный комментарий!
Снимаю шляпу.
Но статью писал не я, я лишь перевел :) И лично я вынес из нее уже достаточно необходимой мне информации и понял принцип взаимодействия с PP.
Завтра все недочеты подправлю в соответствии с тем, что вы написали :)
Спасибо за столь подробный комментарий!
Завтра все недочеты подправлю в соответствии с тем, что вы написали
Обращаю внимание читающих на то, что недочёты всё ещё на месте, в частности, утверждение, что прямой платёж требует регистрации покупателя в PayPal.
Так же обращаю внимание, что имеется ошибка в запросе на подтверждение транзакции.
Кроме перечисленных параметров:
// Завершаем транзакцию
$requestParams = array(
'PAYMENTREQUEST_0_PAYMENTACTION' => 'Sale',
'PAYERID' => $_GET['PayerID']
);необходимы параметры PAYMENTREQUEST_0_AMT и TOKEN.
Кроме того, если вы работаете с песочницей, для перенаправления на сайт PayPal следует использовать песочный адрес:
header( 'Location: www.sandbox.paypal.com/webscr?cmd=_express-checkout&token=' . urlencode($token) );
Спасибо. А не подскажете, какой интерфейс стоит использовать для, например, автоматического пополнения баланса со счетов PayPal? В приложении есть внутренний баланс и когда он становится равным 0, то хотелось бы пополнить его на 10 баксов автоматически. В Authorize.Net такая фича есть, в PayPal пока не нашел.
Навскидку вижу три решения:
1. Хранить кредитки у себя или в спец. хранилище(у Authorize.Net есть такой сервис) и чарджить их самому через PayPal Pro. Правда в этом случае PayPal Pro не так уж и нужен, если используем Authorize.Net для хранения кредиток, логично им и чарджить.
2. Enhanced recurring payments дает возможность использовать подписки с различной суммой. Пользователь должен согласится только на макс… сумму и частоту чарджа.
3. Adaptive Payments позволяет делать автоматические платежи, насколько я помню. Но пользователь должен сделать pre-approve на всю возможную сумму.
1. Хранить кредитки у себя или в спец. хранилище(у Authorize.Net есть такой сервис) и чарджить их самому через PayPal Pro. Правда в этом случае PayPal Pro не так уж и нужен, если используем Authorize.Net для хранения кредиток, логично им и чарджить.
2. Enhanced recurring payments дает возможность использовать подписки с различной суммой. Пользователь должен согласится только на макс… сумму и частоту чарджа.
3. Adaptive Payments позволяет делать автоматические платежи, насколько я помню. Но пользователь должен сделать pre-approve на всю возможную сумму.
Спасибо! Могли бы оформить как топик!
>> Mass Payments это штука, чтобы одновременно послать деньги куче людей.
А есть возможность послать деньги одному человеку без MassPayments?
Если делать MassPayments, то логи транзакций на самом сайте PayPal нечитаемые
А есть возможность послать деньги одному человеку без MassPayments?
Если делать MassPayments, то логи транзакций на самом сайте PayPal нечитаемые
PayPal это зло. Неделя моей жизни выброшенная на ветер.
— В версии SOAP API для PHP5 используются старые бибюлиотеки PEAR не совместимые с PHP5
— Иерархия классов в SOAP совершенно непонятна, что к чему приаттачить не разберешься.
Я вот не разобрался и потому никому не советую её использовать. NVP проще и лучше документирован.
Но и там есть проблемы… Описания очень пространные, примеры — это гремучая смесь из HTML, PHP, Javascript, да и они не покрывают нужный функционал. Сайт с документацией x.com пестрит ссылками на 404 страницы, некоторые материалы, кроме как в кеше гугла не увидишь. Да и те же recurring payments, которые я добавлял пару дней, как оказались стоят дополнительно 30 баксов в месяц.
И что обидно, интегрировали PayPal только ради PayPal аккаунтов. Знал бы я заранее такие расклады, убедил бы начальство принимать только кредитки через другого процессора и не париться :(
Так что если вам нужен сложный функционал оплаты (повторяющиеся платежи, автоматические платежи по какому-то событию, пр.) — советую избежать прямого контакта с PayPal.
— В версии SOAP API для PHP5 используются старые бибюлиотеки PEAR не совместимые с PHP5
— Иерархия классов в SOAP совершенно непонятна, что к чему приаттачить не разберешься.
Я вот не разобрался и потому никому не советую её использовать. NVP проще и лучше документирован.
Но и там есть проблемы… Описания очень пространные, примеры — это гремучая смесь из HTML, PHP, Javascript, да и они не покрывают нужный функционал. Сайт с документацией x.com пестрит ссылками на 404 страницы, некоторые материалы, кроме как в кеше гугла не увидишь. Да и те же recurring payments, которые я добавлял пару дней, как оказались стоят дополнительно 30 баксов в месяц.
И что обидно, интегрировали PayPal только ради PayPal аккаунтов. Знал бы я заранее такие расклады, убедил бы начальство принимать только кредитки через другого процессора и не париться :(
Так что если вам нужен сложный функционал оплаты (повторяющиеся платежи, автоматические платежи по какому-то событию, пр.) — советую избежать прямого контакта с PayPal.
Скажите, чем обусловлен выбор SOAP?
Да и обычно SOAP-интерфейсы понятнее потому что они предоставляют структуру классов. Например, в Authorize.Net не было никаких проблем разобраться с ними. В NVP ты должен знать кучу параметров, правильно их задать, ничего не забыть. Писать самому GET-запрос, запоминать всех внутренние параметры, мне показалось не столь интересным занятием.
Так что я сначала перешел с NVP на SOAP, а потом как увидел, какой там бардак — перешел обратно. Проболема в том, что даже если даются примеры в статьях — о SOAP напрочь забывают.
Так что я сначала перешел с NVP на SOAP, а потом как увидел, какой там бардак — перешел обратно. Проболема в том, что даже если даются примеры в статьях — о SOAP напрочь забывают.
Туториал познавательный, спасибо. Даже ошибку одну нашел в своей старой системе :) +
Друзья, ну почему же все так писают кипятком от PayPal? Что в нем такого, что нет в других платежных системах, которые существуют на рынке? И особенно на Российском? Или может это мода на «американские штучки»?
Хороший вопрос! И мне хотелось чтобы у нас было нечто подобное, но никто(ни ЯД, ни WM, ) так и не осмелился посягнуть на лавры роспэйпала, а с выходом нового закона, не понятно как это реализовывать.
Paypal завоевал популярность на волне eBay. Не думаю что американские заказчики сайтов и их потребители согласятся отойти и на йоту в сторону от безопасных Paypal, Visa, Master Card, AE, WU.
На рынке США есть нишевые ПС, с изюмом в виде мобильности(Square), анонимности, привязки к сети магазина(Amazon Payments). В России нет такого рынка, плюс ПС обирают в равной степени пользователей и торговцев. Поэтому вероятно, зайдя в среднестатистический интернет-магазин в России вас ошеломят не только цены, но и оформив заказ вам предложат либо самовывоз, либо курьерскую доставку.
Paypal завоевал популярность на волне eBay. Не думаю что американские заказчики сайтов и их потребители согласятся отойти и на йоту в сторону от безопасных Paypal, Visa, Master Card, AE, WU.
На рынке США есть нишевые ПС, с изюмом в виде мобильности(Square), анонимности, привязки к сети магазина(Amazon Payments). В России нет такого рынка, плюс ПС обирают в равной степени пользователей и торговцев. Поэтому вероятно, зайдя в среднестатистический интернет-магазин в России вас ошеломят не только цены, но и оформив заказ вам предложат либо самовывоз, либо курьерскую доставку.
Автор, а почему заголовки картинками?
Очень вовремя опубликована статья.
Спасибо :-)
Спасибо :-)
Кроме этих методов есть еще несколько из семейства Payflow Edition. Там имеются методы с поддержкой оплаты на своем сайте, но, в тоже время, с соблюдением PCI стандартов.
Там имеются методы с поддержкой оплаты на своем сайте, но, в тоже время, с соблюдением PCI стандартов.
1. Все платежные шлюзы соблюдают PCI-DSS стандарты. Это их обязанность.
2. Требование соблюдать PCI стандарты также всегда лежит на мерчанте, если он принимает кредитки на своем сайте. Т.е. нету метода оплаты, который автоматически сделает вас PCI-DSS validated/certified. Можно только сделать так, чтобы PCI-DSS к вам не применялось вообще (PayPal Standard) или же упростить сертификацию (например есть только передавать номер кредитки, но не хранить её).
Если хочется принимать оплату кредитками на своем сайте, но заморачиваться с PCI-DSS не хочется — нужно использовать не Payflow, а Paypal Pro Hosted Edition. Он использует iframes, чтобы показывать форму ввода кредитки на вашем в iframe и типа это позволяет избежать сложной сертификации.
Удобная штука — но доступна в ограниченном ряде стран пока. В US например не доступна ещё.
У шлюзов так и есть, но в магазине — это совсем необязательно. Кпримеру: вы используете PayPal Direct — значит вы должны забрать у пользователя кредитку и вручную передать ее на АПИ пейпала. Т.е. ваше приложение работает с кредитками и в некоторых странах должно подлежать сертификации. Вот именно тут поможет Payflow Link. Ваше приложение просто напросто не будет знать ничего о кредитках (т.е. его не нужно сертифицировать и платить за это деньги), но в тоже время поля для ввода платежной информации будут располагаться в вашем дизайне.
но в магазине — это совсем необязательно.
Если магазин хранит, обрабатывает или передает номера кредитных карточек — PCI-DSS сертификация обязательна.
Вот именно тут поможет Payflow Link. Ваше приложение просто напросто не будет знать ничего о кредитках (т.е. его не нужно сертифицировать и платить за это деньги), но в тоже время поля для ввода платежной информации будут располагаться в вашем дизайне.
Да, вы правы. Payflow Link – аналог Pro Hosted, то же решение через iframes.
Если магазин хранит, обрабатывает или передает номера кредитных карточек — PCI-DSS сертификация обязательна.
На сколько я знаю, сам совет его просто рекомендует, а обязательным его могут сделать либо законы страны, где расположен продавец, либо сам процессинговый центр, с которым продавец так или иначе имеет дело. И даже в последнем случае иногда возможна работа без сертификации с определенным штрафами, либо объемами.
На сколько я знаю, сам совет его просто рекомендует, а обязательным его могут сделать либо законы страны, где расположен продавец, либо сам процессинговый центр, с которым продавец так или иначе имеет дело.
Ага, совет разрабатывает стандарт, сами требования выдвигают Visa/Mastercard к своим партнерам, которые уже требуеют этого от конечных мерчантов.
Насколько я помню в US требование уже в силе для новых и существующих мерчантов с 1 июля 2010, в Европе/Азии — для новых мерчантов с 1 июля 2010, для существующих с 1 июля 2012.
И даже в последнем случае иногда возможна работа без сертификации с определенным штрафами, либо объемами.
По моему опыту такая работа возможно только, когда банк/платежный шлюз закрывают на это глаза, например, боясь растерять мерчантов. Штрафы там кстати нефиговые, от 10,000 евро по тому, что я видел.
coding.smashingmagazine.com/2011/09/05/getting-started-with-the-paypal-api/
Почему не оформлена как перевод?
Почему не оформлена как перевод?
Потому, что! О БОЖЕ! это не обязательно. В футере топика указаны все данные о переводе.
Вы всегда так нервно реагируете на вопросы? =)
кто-то знает/иммет опыт можно ли выводит через PayPal и есть ли API?
Кто знает, работают ли Paypal Adaptive Payments с Россией? Есть ли какие-нибудь подводные камни?
Sign up to leave a comment.
Знакомимся с PayPal API