Pull to refresh

Comments 29

Прикольно, в избранное добавило 78 человек, а «за» проголосовало всего 9.
Квинтэссенция хабра, блин.

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

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

Основным недостатком, как мне кажется, является задержка между платежом и IPN подтверждением. Обычно не более 1 минуты, но иногда бывает и больше.
Не соглашусь с вами. Имею опыт работы с многими платежными системами. И paypal, особенно приведенный вами метод в статье, является одним из самых простых и хорошо документированных. Мгновенным подтверждением платежа может являться, разве что, переход клиента обратно с paypal'а на заданный return url, но и в этом случае нет гарантии, что клиент вообще перейдет обратно.
Если работаете с европейскими / американскими клиентами, paypal будет очень полезен.
Наверное, да. Сейчас мне тоже кажется, что ничего сложного. Но когда только начинал эту схему делать, очень не хватало руководства, где весь процесс был бы описан от начала до конца. Есть вообще такое?

Мгновенным подтверждением платежа может являться, разве что, переход клиента обратно с paypal'а на заданный return url


Насколько я понимаю, PDT нечто подобное и делает. Жаль, что раньше я про него не знал…

Если работаете с европейскими / американскими клиентами, paypal будет очень полезен.


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


Видимо, зависит от того, что именно вам нужно. У paypal'a, можно сказать, есть 2 вида интеграции. Простой — когда вы просто ставите их кнопочку на свой сайт, которая делает редирект и всё происходит на стороне paypal'а. И по-интереснее: когда почти всё происходит на стороне вашего сайта. По первому, я думаю, вряд ли какие-то трудности могут возникнуть. Да и второй достаточно хорошо документирован на их девелопер ресурсе.

Да, как раз с ними и работаю. Заметил, что Paypal достаточно популярен в Европе. В общем-то, я вынужден был его использовать


Пластиковые карты и paypal, как правило, вполне достаточно для 95% зарубежных клиентов. По крайней мере, за всё время работы, никто не предлагал нам других вариантов.
в любом случае браво за статью. про запутанность документации подтверждаю, но это у них стиль такой ;)
Вопрос, который меня давно мучает. Что лучше использовать IPN или PDT?
К сожалению с PDT лично я не работал, только с IPN. Вот открыл документацию, и с ходу не понятно, в чем разница.
На первый взгляд они просто дублируют друг друга.
Но на самом деле есть разница. И похоже их следует использовать совместно.

Фишка IPN в том, что он передает больше информации, присылает уведомления об изменении, отмене, истечении подписки, возврате платежа и т.д.
И, в общем, он всем хорош, если бы не задержка. Сейчас я вынужден после успешного платежа показывать пользователю, которого paypal перенаправил обратно на сайт, сообщение. Мол «твоя подписка создается, можешь пока тут кнопки понажимать, по сайту погулять». А я подожду, пока Paypal наконец пришлет мне IPN запрос, я его обработаю и, если все нормально — создам подписку. А если нет, то не создам.

Фишка PDT в том, что он работает сразу и позволит этого избежать. Можно сразу же получить подтверждение, что платеж прошел успешно. Но он не так надежен. Пользователь может и не перейти обратно на сайт.

Подробнее описано здесь:
stackoverflow.com/questions/2836779/ipn-vs-pdt-in-paypal
www.paysketch.com/paypal-pdt-vs-ipn
Не забудьте указать, что пользоваться пейпалом надо с указанием России (если работаете из России), а в России надо регистрировать юрлицо для ведения бизнеса, а пейпал Россия молча без оповещения об ошибках не принимает деньги от бизнес аккаунтов.
Спасибо за ценное замечание.

Проект, в котором я все это реализовывал пока что не имеет российского представительства, поэтому я с этой проблемой не столкнулся.
Боюсь, у меня на данный момент нет опыта использования Paypal для ведения бизнеса в России.

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

Когда я создал business account, paypal стал требовать от меня множество персональных данных. Я не стал их заполнять и соответственно не могу принимать платежи. Но мне и не нужно. Этот аккаунт мне был нужен в основном для тестироваания.
Да нельзя работать с пейпал россия. Вообще, никак.

Во-первых, они не принимают платежи от business аккаунтов.

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

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

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

У нас к счастью стабильно доля пейпала в оплате падает и я надеюсь, что она сойдет на нет. Это поганая система, а пейпал Россия ещё и совково-поганая.
А что нужно использовать?
Прием карточек, конечно. Варианты есть.

Пейпал — только как крайне резервный способ.
И что, люди охотно светят свои карточки на малоизвестном сайте?
У меня не малоизвестный сайт, так что ответить вам не смогу.
Наверное имеет смысл просто использовать какую-нибудь другую платежную систему, например робокассу(не реклама, просто первое, что приходит в голову). Сам, правда, ею не пользовался.
Ну или другую какую-нибудь. И это скорее всего будет проще.
Людям не нужно будет светить карточки на малоизвестном сайте.

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

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

Вроде есть российские платежные системы с поддержкой рекуррентных платежей(например здесь обсуждается). Я с ними не работал, к сожалению
Страйп не работает с компаниями в России. Мы работаем с Cloudpayments и с Fastspring. Fastspring очень плох, но он принимает пейпал.
Мы работаем с ecommpay и signedpay. Ecommpay, вроде, хороши. Но поддержка у них не очень, туговата.
Спасибо за статью.

Вот интересно: в IPN приходит параметр verify_sign, однако, в обработке уведомления нет проверки его валидности. Насколько я знаю, все платежные системы подписывают свои уведомления схожим параметром, который формируется по определенным алгоритмам; и уже проверка его на валидность является необходимым и достаточным условием валидности самого уведомления.

И в документации я не нашел информации, связанной с этим.
В документации сказано только что verify_sign — это цифровая подпись, которая используется PayPal при проверке транзакции.
Сказано, что это какой-то хэш, но алгоритм не уточняется. Небольшое обсуждение здесь

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

Мы отправляем данные IPN запроса в Paypal и получаем ответ VERIFIED либо INVALID. Этого должно быть достаточно.

Правда, если перехватить IPN запрос и отправить его повторно, ответ будет VERIFIED(хотя запрос отправил не Paypal, а я через CURL). Но в случае, если запрос подделан или изменен, то ответ будет INVALID.
Вы называете это понятная статья?

$userService = new UserService();


Что это за UserService() нарисовался? Ни слова не сказано об этом классе, зато он используется в примерах вашего кода.
1) это сервис, который, судя по названию работает с пользователями
2) судя по вызываемым методам все для чего он нужен в рамках примера — получать информацию о пользователе по его id.

Еще вопросы?
Sign up to leave a comment.

Articles