1. Хранить кредитки у себя или в спец. хранилище(у Authorize.Net есть такой сервис) и чарджить их самому через PayPal Pro. Правда в этом случае PayPal Pro не так уж и нужен, если используем Authorize.Net для хранения кредиток, логично им и чарджить.
2. Enhanced recurring payments дает возможность использовать подписки с различной суммой. Пользователь должен согласится только на макс… сумму и частоту чарджа.
3. Adaptive Payments позволяет делать автоматические платежи, насколько я помню. Но пользователь должен сделать pre-approve на всю возможную сумму.
К сожалению автор статьи не до конца разобрался в вопросе. Учитывая тот факт, что еще часть нюансов пропала в процессе перевода, статья можнт скорее запутать, начинающего изучать 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.
Этот вариант в принципе выполняет ту же функцию, что и предыдущий, но с некоторыми отличиями (я вроде бы уже упомянул о том, что 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 аккаунт.
Заниматься же демагогией с человеком верующим — извините, у меня нет времени.
Было бы здорово, если бы вы нашли время привести хотя бы один вменяемый аргумент. А то все ваши доводы на ссылки и факты имеют вид «этого не бывает, така как я знаю, что этого не бывает».
Ох, лол. Вы много тут написали, на личности перешли, а так и не удосужились погуглить что такое Quantcast и каковы методики расчета статистики у них.
Вы перед тем как что-то разжевывать, вспомните, что пару комментариев назад вы на полном серьезе утверждали, что тот факт, что статистика по top10K и top1M не совпадает это неправильно и такого быть не должно:
Достаточно сравнить данные по топ10к и топ-миллиону, чтобы увидеть что они полностью друг другу не соответствуют. Ну это совершенно базовые, элементарные понятия статистики; если бы выборка делалась правильно, то есть случайно и не предвзято, тогда топ10к соответствовал бы топ миллиону с точностью до десятых процента, и тогда можно было бы экстраполировать результаты на весь интернет. Здесь же этого нет даже близко. Это цифры ни о чем, понимаете?
Как-то сложно воспринимать вас всерьез после этого. Даже не после этой вашей ошибки(все ошибаются), а того факта, что вы отказываетесь ее признать.
Про амазон с ебеем я уже писал.
Вот еще один пример того, что не нужно всегда думать, что окружающие все идиоты, а вы несете свет истины.
Например ваш eBay сам по себе не дает сделать standalone shopping cart, поэтому его в обзоре и нет. Зато два других решения от eBay: ProStores и GSI Commerce(их недавно купил ebay) там вполне присутсвуют.
Гораздо правильней было бы например придраться к тому, что в списке отсутствует BigCommerce — он достаточно крупный игрок на рынке.
Если честно возникает ощущение, что вы не совсем владеете темой о которой спорите. Это опять же нормально(никто не может знать все, у нас у всех ограниченные уровни компетенции), но зачем тогда спорить?
1. Опеределять движок по URL действительно так еще задача. Поэтому только по URL никто не определяет. Например WordPress опеределяется по одному взгляду на HTML source.
Почему бы вам просто не потестировать их методику самому? builtwith.com/
2. Достаточно сравнить данные по топ10к и топ-миллиону, чтобы увидеть что они полностью друг другу не соответствуют. Ну это совершенно базовые, элементарные понятия статистики; если бы выборка делалась правильно, то есть случайно и не предвзято, тогда топ10к соответствовал бы топ миллиону с точностью до десятых процента, и тогда можно было бы экстраполировать результаты на весь интернет. Здесь же этого нет даже близко. Это цифры ни о чем, понимаете? Они никак не описывают реальность.
Как раз тот факт, что статистика по top10K и top1M разная полностью очевидно и правильно. Сайты, которые входят в top10K по посещаемости используют другие решения чем обычные малые бизнесы. Например решения от Oracle, IBM и Ebay(все эти решения в топе для top10K сайтов)
Не представляю, как можно посчитать подобную статистику.
Видимо вы не работали c разными движками интернет-магазинов. Для коробочных продуктов все достаточно просто определяется.
«Топ 10000 сайтов» для всего интернета вызывает смех — как они составляли этот топ?
Меня удивлияет ваше нежелание нажать на ссылку «FAQ» на той странице и потратить 3 минуты на чтение. Все ваши вопросы там уже отвечены. Они проиндексировали 90 миллионов сайтов, топ взят по статистике от Quantcast
В данном случае сфейлили разработчики Shop-Script, которые сделали возможность просмотра деталей заказа без логина по специальной ссылке, но забыли закрыть подобные ссылки от индексации.
Если Руслан будет читать комментарии, то хотелось бы задать вопрос: Планируется ли переход от табличной верстки в дивовой? Если да, то когда?
Отвечу за Руслана: -)
Безусловно div-ная верстка это клёво и правильно. Если например посмотреть на сайт Эквида, то увидим, что он на div-ах и без таблиц. Все современно.
У самого же Эквида немного другие требования. Виджет должен работать на любой странице и в любом браузере. Не важно какая у страница верстка(правильная или с ошибками), не важно какой у страницы доктайп(его может и не быть), не важно какии у страниц CSS стили, не важно что за браузер(да, виджет работает в IE6) — магазины должны отображаться правильно и одинаковым образом.
При таких условиях верстка таблицами это «бронебойный» способ такой одинаковости достичь.
Уже нет. Есть требования PCI-DSS/PA-DSS, если магазин их не выполняет, то его ждут большие беды, если вдруг его взломают и кредитки «утекут».
А вот каким образом попадают на платежные страницы всякие там бэджи типа «Verfied by VISA»
Этот бейдж не имеет отношения к безопасности самого магазина. Visa конечно не проверяет сама магазин. Это всего лишь говорит о том, что поддерживается защитная технология «Verfied by Visa», когда каждую транзакцию надо подтверждать паролем.
О, с этим тоже интересная история. Статистика показывает, что наибольший процент конвертации у следующих типов пользователей:
— пришел, посмотрел планы, сразу подписался на платный
— пришел, запустился на бесплатном, магазин начал приносить прибыль, проапгрейдился
Так вот время до успеха у каждого магазина разное, тут уж от клиента и магазина зависит. Мы на этом можем конечно влиять (делая качественный продукт и предлагая отличный сервис), но опосредовано.
По очень грубым моим прикидкам: где-то месяц-два. За это время чувак осваивается и решает нужен ли ему платный аккаунт, может ли он его себе позволить.
Процент конвертации бесплатных пользователей в платные(если у вас Freemium) обычно 6% — 10%
Мы не исключение: -) Было забавно, когда мы подсчитали статистику у себя и обнаружили, что у остальных (сторонних) проектов примерно такие же числа.
1. Хранить кредитки у себя или в спец. хранилище(у Authorize.Net есть такой сервис) и чарджить их самому через PayPal Pro. Правда в этом случае PayPal Pro не так уж и нужен, если используем Authorize.Net для хранения кредиток, логично им и чарджить.
2. Enhanced recurring payments дает возможность использовать подписки с различной суммой. Пользователь должен согласится только на макс… сумму и частоту чарджа.
3. Adaptive Payments позволяет делать автоматические платежи, насколько я помню. Но пользователь должен сделать pre-approve на всю возможную сумму.
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 аккаунт.
Было бы здорово, если бы вы нашли время привести хотя бы один вменяемый аргумент. А то все ваши доводы на ссылки и факты имеют вид «этого не бывает, така как я знаю, что этого не бывает».
Вы перед тем как что-то разжевывать, вспомните, что пару комментариев назад вы на полном серьезе утверждали, что тот факт, что статистика по top10K и top1M не совпадает это неправильно и такого быть не должно:
Достаточно сравнить данные по топ10к и топ-миллиону, чтобы увидеть что они полностью друг другу не соответствуют. Ну это совершенно базовые, элементарные понятия статистики; если бы выборка делалась правильно, то есть случайно и не предвзято, тогда топ10к соответствовал бы топ миллиону с точностью до десятых процента, и тогда можно было бы экстраполировать результаты на весь интернет. Здесь же этого нет даже близко. Это цифры ни о чем, понимаете?
Как-то сложно воспринимать вас всерьез после этого. Даже не после этой вашей ошибки(все ошибаются), а того факта, что вы отказываетесь ее признать.
Про амазон с ебеем я уже писал.
Вот еще один пример того, что не нужно всегда думать, что окружающие все идиоты, а вы несете свет истины.
Например ваш eBay сам по себе не дает сделать standalone shopping cart, поэтому его в обзоре и нет. Зато два других решения от eBay: ProStores и GSI Commerce(их недавно купил ebay) там вполне присутсвуют.
Гораздо правильней было бы например придраться к тому, что в списке отсутствует BigCommerce — он достаточно крупный игрок на рынке.
Если честно возникает ощущение, что вы не совсем владеете темой о которой спорите. Это опять же нормально(никто не может знать все, у нас у всех ограниченные уровни компетенции), но зачем тогда спорить?
Почему бы вам просто не потестировать их методику самому? builtwith.com/
2.
Достаточно сравнить данные по топ10к и топ-миллиону, чтобы увидеть что они полностью друг другу не соответствуют. Ну это совершенно базовые, элементарные понятия статистики; если бы выборка делалась правильно, то есть случайно и не предвзято, тогда топ10к соответствовал бы топ миллиону с точностью до десятых процента, и тогда можно было бы экстраполировать результаты на весь интернет. Здесь же этого нет даже близко. Это цифры ни о чем, понимаете? Они никак не описывают реальность.
Как раз тот факт, что статистика по top10K и top1M разная полностью очевидно и правильно. Сайты, которые входят в top10K по посещаемости используют другие решения чем обычные малые бизнесы. Например решения от Oracle, IBM и Ebay(все эти решения в топе для top10K сайтов)
Это количество платных клиентов(их сейчас уже больше, конечно). Общее количество аккаунтов, зарегистрированных за все время уже около 80,000
Это количество платных клиентов(их сейчас уже больше, конечно). Общее количество аккаунтов, зарегистрированных за все время уже около 80,000
Видимо вы не работали c разными движками интернет-магазинов. Для коробочных продуктов все достаточно просто определяется.
«Топ 10000 сайтов» для всего интернета вызывает смех — как они составляли этот топ?
Меня удивлияет ваше нежелание нажать на ссылку «FAQ» на той странице и потратить 3 минуты на чтение. Все ваши вопросы там уже отвечены. Они проиндексировали 90 миллионов сайтов, топ взят по статистике от Quantcast
Именно, в рунете. В мире OpenCart входит в top10: trends.builtwith.com/shop
yandex.ru/yandsearch?text=ukey%3Dorder_status+%22%D0%9F%D0%BE%D0%BB%D1%83%D1%87%D0%B0%D1%82%D0%B5%D0%BB%D1%8C%3A+%22+site%3Aherbal-vd.ru&lr=195
В результате сотни магазинов раскрыли данные тысяч своих клиентов: yandex.ru/yandsearch?text=ukey%3Dorder_status+%22%D0%9F%D0%BE%D0%BB%D1%83%D1%87%D0%B0%D1%82%D0%B5%D0%BB%D1%8C%3A+%22&lr=195
Скорее всего каждый магазин на Shop-Script у которого данная фича включена подвержен проблеме.
Отвечу за Руслана: -)
Безусловно div-ная верстка это клёво и правильно. Если например посмотреть на сайт Эквида, то увидим, что он на div-ах и без таблиц. Все современно.
У самого же Эквида немного другие требования. Виджет должен работать на любой странице и в любом браузере. Не важно какая у страница верстка(правильная или с ошибками), не важно какой у страницы доктайп(его может и не быть), не важно какии у страниц CSS стили, не важно что за браузер(да, виджет работает в IE6) — магазины должны отображаться правильно и одинаковым образом.
При таких условиях верстка таблицами это «бронебойный» способ такой одинаковости достичь.
Кое-какие вопросы все таки остались: habrastorage.org/storage1/04486301/5bf8d781/5c77a473/410be987.png: -)
Уже нет. Есть требования PCI-DSS/PA-DSS, если магазин их не выполняет, то его ждут большие беды, если вдруг его взломают и кредитки «утекут».
А вот каким образом попадают на платежные страницы всякие там бэджи типа «Verfied by VISA»
Этот бейдж не имеет отношения к безопасности самого магазина. Visa конечно не проверяет сама магазин. Это всего лишь говорит о том, что поддерживается защитная технология «Verfied by Visa», когда каждую транзакцию надо подтверждать паролем.
— пришел, посмотрел планы, сразу подписался на платный
— пришел, запустился на бесплатном, магазин начал приносить прибыль, проапгрейдился
Так вот время до успеха у каждого магазина разное, тут уж от клиента и магазина зависит. Мы на этом можем конечно влиять (делая качественный продукт и предлагая отличный сервис), но опосредовано.
По очень грубым моим прикидкам: где-то месяц-два. За это время чувак осваивается и решает нужен ли ему платный аккаунт, может ли он его себе позволить.
Мы не исключение: -) Было забавно, когда мы подсчитали статистику у себя и обнаружили, что у остальных (сторонних) проектов примерно такие же числа.