Как подготовить сайт к приему онлайн-платежей
В условиях карантина многие офлайн-компании переходят в онлайн: фитнес, кафе, аптеки, образовательные проекты, ритейл. Важная часть успешной работы в онлайне — бесперебойный прием онлайн-платежей.
Банки-эквайеры выдвигают ряд требований к сайтам, где планируется подключение интернет-эквайринга. Некоторые компании сталкиваются со сложностями в их соблюдении, а в результате получают отказ от банка. Мы часто помогаем клиентам разобраться в этих правилах и доработать сайт. Делимся с вами чек-листом и рекомендациями, чтобы вы не тратили время и сразу все сделали правильно!
Требования к сайту Предприятия идентичны у большинства банков:
1. Сайт должен иметь статический IP адрес и размещаться на платном хостинге.
2. Сайт не должен содержать информацию, запрещенную к распространению в соответствии с законодательством Российской Федерации и Правилами Платежных систем.
3. Сайт должен быть на русском языке или иметь русскоязычный вариант изложения информации.
С этим вопросом часто возникают сложности, если ваша основная аудитория находится в Европе и платит в евро. Но если вы хотите подключать платежи на российское юрлицо в российском банке, придется сделать версию на русском языке с ценами в рублях. Или вы можете подключить эквайринг сразу в европейском банке. В целом, подробно варианты приема платежей с иностранных карт мы подробно рассмотрели здесь.
4. На Сайте Интернет-магазина Предприятия в обязательном порядке должна быть размещена следующая информация (приводим сразу с примерами на сайтах, где успешно работают наши платежи):
— Данные о юридическом лице Предприятия (наименование, адрес, ИНН, контактный телефон, электронная почта)
— Полное описание потребительских характеристик продаваемых Товаров:
— Способы оплаты Товара:
— Порядок проведения оплаты по банковским картам:
— Порядок возврата Товара:
— Информация о мерах по обеспечению безопасности Операций с использованием Карт:
— Информация, которая предоставляется клиентам по оплате Товаров с использованием Карт/ по возврату Товара, оплаченного по Карте, должна быть согласована с Банком.
— Логотипы платежных систем — VISA, Mastercard, МИР:
— Регистрационная форма для клиента. Это требование есть не у всех банков; оно может быть связано с подключением отдельных платежных инструментов и осуществлением доставки.
5. Перечень Товаров, который вы предоставляете Банку, должен соответствовать перечню Товаров, фактически реализуемых через Интернет-магазин.
Службы безопасности банков следят, чтобы на подключаемом сайте продавалось именно то, что вы описываете при подаче документов. В частности, это касается категорий товаров и услуг.
6. Для лицензируемой деятельности на Сайте должна быть размещена информация о лицензиях, разрешениях от производителя, правообладателя или государственных органов на реализуемые Товары.
7. На Сайте не должно быть неработающих страниц, ссылок, направление которых не соответствует их названию, а также страниц/ссылок, перенаправляющих на другие сайты (без явного указания перенаправления).
Обычно проверяется автоматически. Уверены, что вы и так за этим следите — это полезно и для SEO.
8. Сайт должен находиться в рабочем состоянии, содержать исчерпывающую информацию о предлагаемых Товарах.
Если вы только переходите в онлайн, позаботьтесь о контенте на сайте, содержательных карточках товаров с полной информацией и характеристиками товара. Кстати, это тоже важно не только для подключения платежей, но и для ваших пользователей.
Помимо перечисленных правил, не забывайте про 54-ФЗ и подключение онлайн-касс. Можно озадачиться отдельной покупкой и настройкой, или обратиться в компанию с готовым решением. Например, у нас в Payture есть готовая интеграция с популярными сервисами онлайн-касс, поэтому вы комплектом к интернет-эквайрингу получаете готовые настроенные кассы с онлайн-фискализацией.
Для вашего удобства мы собрали список требований в отдельный чек-лист, который вы можете скачать здесь и проверить свой сайт.
Платежные технологии – просто о сложном. Часть 1
Давайте поговорим о платежных технологиях и что происходит, когда клиент хочет оплатить услугу на сайте или в интернет-Банке, сделать перевод или нам просто необходимо настроить интеграцию с агрегатором, магазином или платежной системой в целях вывода их услуг в своих дистанционных каналах обслуживания.
Здесь будет представлена серия статей, которая поможет начинающим специалистам в ИТ, занимающихся платежными технологиями, ответить на вопрос: «как писать исходящий шлюз с платежной системой или агрегатором», «как решить вопрос с расхождениями при сверках», как реализовать интеграцию с международной платежной системой.
Устраивайтесь поудобнее, будет интересно.
Часть 1: Проведение и подтверждение платежа
Клиент для оплаты услуг как правило авторизуется в интернет-Банке, выпустившим его карту: Банку-Эмитенту его карты.
Далее в интернет-Банке, выбирает услугу для оплаты: пополнение мобильного телефона, оплаты интернета или услуг ЖКУ.
В базе поставщика услуги, например оператора сотовой связи, у клиента есть свой уникальный идентификатор – номер телефона.
Чтобы оплатить услугу клиент вводит свой идентификатор и сумму пополнения, нажимает кнопку «подтвердить платеж».
А дальше ему отображается пред чек с идентификатором пополнения и суммой пополнения. Он подтверждает оплату и далее интернет-Банк отображает ему чек. Клиент радостный уходит. Деньги «моментально» поступают на его номер телефона.
Это для клиента так. А давайте посмотрим, как это выглядит внутри систем.
Наш онлайн обмен сообщениями, будет состоять из нескольких участников:
Витрина – в данном случае, интернет-Банк клиента;
Банк клиента – он же оператор по переводу денежных средств, он же Банк-Эмитент, выпустивший карту клиента, и он же расчетный Банк по переводам средств клиента Сервис-Провайдеру;
Сервис-Провайдер – юридическое лицо, оказывающее услуги зачисления средств Поставщику, его часто называют «Мерчант». Сервис-Провайдер имеет прямые договора со многими поставщиками услуг, и чтобы Банку не настраивать интеграцию с каждым из них, на рынке есть компании-посредники: Сервис- Провайдеры, еще их называют агрегаторами, платежными системами. Они уже настроили интеграцию с Поставщиками услуг и предоставляют большое количество сервисов за определенный процент;
Наш оператор сотовой связи – Поставщик услуг;
И у Сервис-Провайдера и у Поставщика услуг есть свои расчетные Банки. В итоге, Банк Сервис-Провайдера в офлайне перечислит денежные средства на счет Поставщика услуг в целях зачисления на счет клиента. Но об этом в следующих статьях.
Я буду использовать сущности: Банк, Мерчант и Витрина для описания онлайн взаимодействия внутри систем.
Центральной фигурой в нашем взаимодействии является Банк клиента.
У Банка задача не только проверить наличие денежных средств у клиента, но и доставить их Сервис-Провайдеру. Для выполнения этого условия Банк, как правило, пишет два шлюза либо использует текущие:
Входящий: от Витрины к Банку;
Исходящий: от Банка к Мерчанту;
Оба эти шлюза могут работать как по тождественному протоколу, так и по разным.
Мы рассмотрим самый простой вариант: витрина Банка, Банк и Мерчант работают по одному сквозному протоколу, представленному всего двумя методами: check и pay.
Описание процесса проведения и подтверждения платежа в этом случае выглядит следующим образом:
Сиквенс проведения и подтверждения платежа
Описание процесса проведения и подтверждения платежа
Клиент выбирает услугу;
Витрина Банка проверяет наличие услуги у себя в Базе данных;
2.1 Если услуга найдена, формирует запрос в Банк на холдирование денежных средств в Процессинге. Далее формирует запрос на возможность совершение платежа check:
2.2 Если услуга не найдена, завершает процесс ошибкой, клиент уходит;
Витрина инициирует check;
В Банк поступает запрос check. Далее Банк маршрутизирует запрос Мерчанту;
Мерчант принимает запрос, выполняет проверку совершения платежа;
5.1 Если зачисление возможно, отправляет успех, клиенту отображается пречек. Система Банка ожидает подтверждение платежа;
5.2 Если зачисление невозможно, Банк отправляет код ошибки, витрина завершает процесс, проведение невозможно, клиент уходит;
Клиент знакомится с пречеком, нажимает кнопку «подтвердить платеж». Витрина инициирует pay;
Банк присваивает идентификатор транзакции и сразу отправляет ответ на витрину;
Зачисление денежных средств у Мерчанта уже выполняется в офлайне. Банк инициирует pay и, если зачисление возможно, Мерчант присваивает свой идентификатор транзакции и отправляет в Банк успешный ответ. А если зачисление невозможно – спросите Вы? Тогда Мерчант отправляет ответ в Банк с кодом ошибки, и Банк выполняет возврат денежных средств клиенту в автоматическом режиме в тот же день.
Теперь рассмотрит рассмотрим формат запроса и ответа для каждого из методов, за что они отвечают и для чего они нужны
CHECK – проведение платежа
Метод отвечает за возможность совершения платежа. На этом шаге выполняется проверка доступности услуги на витрине, в Банке и у Мерчанта. Мерчант в свою очередь, в онлайне, может сходить к Поставщику и проверить валидность идентификатора пополнения у Поставщика, и, если, он не найден или ошибка, отклонить платеж.
Очень часто на этом шаге закладывают минимальные требования к времени отклика ответа на запрос от Мерчанта, т.к. клиент не будет ждать, пока Витрина Банка, сам Банк и Мерчант проверят доступность услуги.
Отличительной особенностью этого шага является так же расчет комиссии. Комиссии бывают:
Верхняя, или горячая – это комиссия с клиента сверх тела платежа (суммы зачисления);
Нижняя или холодная, это комиссия, которую платит Банку Мерчант;
Смешанная – в этой рубрике мы не будем о них говорить;
В нашем примере на check рассчитывается только комиссия с клиента, нижняя и смешанная комиссии рассчитываются в отдельно. Об этом с следующих статьях.
Структура запроса check/XML, шлюз контура Витрина – Банк:
Time – дата платежа;
type – тип источника списания;
code – код валюты перевода, в примере рубли;
amount – сумма зачисления или, по-другому, тело платежа
commission_amount – сумма с учетом верхней комиссии;
service – цифровой идентификатор услуги, который проверяет есть ли вообще такая услуга в Банке и на витрине;
account – контейнер с идентификатором пополнения, в нашем случае – номер телефона;
Когда клиент на витрине нажимает иконку с оплачиваемой услугой, первое, что выполняет система, это проверяет доступность услуги и если она доступна, то дальше обращается в процессинг для проверки источника списания (поля Type и type_number)
Далее если денежные средства есть, проверяет возможность зачисления денежных средств на номер телефона (phone_number в значении 86248541234)
Подождите, секундочку – спросите вы. Что-то здесь не сходится. Как по маскированному PAN в поле type_number можно проверить наличие денежных средств на карте клиента?
Все верно, внимательные читатели обратили внимание, что по маскированному PAN это сделать нельзя.
Авторизация в процессинге выполняется перед check и это отдельный метод и отдельный процесс, посмотрите выше на диаграмму процесса. На проведении платежа мы уже работаем с маскированным PAN, т.к. на этом шаге мы проверяем возможность проведения платежа, а не наличие денежных средств на карте клиента.
Далее мы формируем запрос Мерчанту.
Мы не указываем ни PAN, ни тип источника списания, нас интересует только возможность совершения платежа для конкретного сервиса.
Структура запроса check/XML, шлюз контура Банк – Мерчант:
В ответе Мерчант возвращает все те же самые поля, но появляется дополнительный контейнер со статусом обработки операции, а также идентификатор транзакции в поле id
Структура ответа check/XML, шлюз контура Мерчант – Банк:
Такой ответ будет означать, что Мерчант готов к подтверждению платежа клиентом.
В ответе мы у нас будет временный id транзакции у Мерчанта, а так же статус обработки платежа: status_id == Success (успех) и код ошибки равный 0 (успех) в поле errorCode
Не всегда к нам приходят успешные статусы транзакций и не всегда у нас отсутствуют коды ошибок, но об этом мы поговорим в следующих статьях.
Мы сохраняем ответ и обогащаем его необходимыми для витрины полями, присваиваем идентификатору транзакции мерчанта – идентификатор в Банке и отправляем ответ на витрину.
Структура ответа check/XML, шлюз контура Банк – Витрина
Клиент видит экранную форму пречека, с который каждый из нас знаком: там будет сумма платежа, дата, а так же идентификатор пополняемой услуги.
Если клиент со всем согласен, он нажимает кнопку «оплатить». Теперь отменить платеж можно только по письменному распоряжению плательщика, как правило – при личном обращении в Банк.
В запросе витрина может передать как все поля из предыдущего ответа check, так и просто сумму платежа и идентификатор транзакции, полученной на предыдущем шаге.
Мы будем использовать первый вариант.
PAY – подтверждение платежа
Структура запроса pay/XML, шлюз контура Витрина – Банк :
Банк регистрирует платеж, и сразу отправляет ответ с промежуточным статусом обработки операции «в проведении» в ответ витрине
Структура ответа pay/XML, шлюз контура Банк – витрина:
Клиенту печатается чек о приеме к исполнению платежа, с печатью Банка и он уходит.
Но вы еще к Мерчанту не сходили, не подтвердили у него оплату, не зарегистрировали у него платеж, а уже отпускаете клиента – снова спросите вы?
Все верно, клиент не будет ждать, пока мы сходим и зарегистрируем платеж у Мерчанта, а он свою очередь к своим поставщикам на удаленные системы. Мы уже проверили возможность совершения платежа в онлайне на предыдущем шаге check, а теперь можем отпустить клиента с печатью Банка «в проведении» и зарегистрировать оплату у мерчанта в офлайне.
Для регистрации оплаты у мерчанта, для переданного id транзакции витрины, находим транзакцию мерчанта из предыдущего шага и с ней уже регистрируем платеж.
Структура запроса pay/XML, шлюз контура Банк – мерчант:
В ответ мерчант сообщает статус обработки транзакции, который может принимать статус успех, в проведении или, если оплата была отклонена, ошибка.
Два статуса финальные, а один промежуточный.
Можно сказать, что на этих статусах обязательства и Банка и Мерчанта перед клиентом завершены.
Да, такое бывает достаточно часто, и для решения этой задачи существует отдельный процесс по запросу финального статуса операции как на стороне витрины, так и на стороне Банка, но об этом в следующих статьях.
Сравнение мобильных платёжных систем Google Pay, Android Pay, Apple Pay и Samsung Pay
Современные телефоны под управлением Android и iOS можно использовать для бесконтактной оплаты покупок через обычные платёжные терминалы (POS‑терминалы). Для этого в специальной программе указываются данные платёжной карты (номер, срок действия, CVV или CVC2-код), а подтверждение оплаты производится на дисплее (ввод ПИН-кода или проверка отпечатка пальца, сканера лица при наличии соответствующего сенсора в телефоне). Обслуживание данной функции выполняется через сервис платёжных систем: Google Pay, Android Pay, Apple Pay и Samsung Play. И хоть задача у них одинаковая, функционал незначительно отличается.
Общая информация о мобильных платёжных сервисах
Принцип работы всех мобильных платёжных сервисов – одинаковый:
Физическая банковская карта при этом не требуется. Отличия между платёжными системами заключаются только в:
Поддержка устройствами
Здесь все предельно просто:
Сравнение показывает, что чаще всего бесконтактная оплата выполняется именно через Apple Pay. Хотя телефонов с Google Pay в мире на порядок больше, но компания намного медленней внедряет свой сервис.
Оплата без интернета
Apple Pay, Samsung Pay поддерживают бесконтактную оплату смартфоном при отсутствии доступа в интернет. Это возможно за счёт того, что в телефонах от Apple и Samsung интегрированы специальные чипы, генерирующие так называемые «цифровые токены». Эти же данные потом сверяются с кодом, сгенерированным платёжным терминалом. Если всё в порядке, то операция подтверждается даже при отсутствии связи с банком.
Google Pay же работает и на тех устройствах, где специального чипа нет. А «цифровой токен» при этом генерируется на серверах Гугл и только после добавляется на смартфон. Одной такой генерации хватает не более чем на 6 покупок без соединения с сервером банка. Все следующие попытки оплатить покупки телефоном будут отклонены (до выхода в интернет).
Перечень поддерживаемых банков
Статистика указывает на то, что лидером по количеству поддерживаемых банков во всём мире является Apple Pay. Незначительно отстаёт Google Pay. Самсунг Пэй аутсайдер, но в некоторых странах для Android-устройств доступен только он (например, Китай, где Гугл вообще не работает, даже его поисковик не доступен).
Но ни одна из рассматриваемых платёжных систем пока что не работает с абсолютно всеми банками. Поэтому перед тем как выбрать для покупки новый телефон следует интересоваться, какие платёжные системы поддерживает тот или иной банк (карточки которых уже есть у пользователя). И выбирать уже исходя из полученных данных.
Используемые методы подтверждения платёжных операций
Все рассматриваемые платёжные системы позволяют пользователю самостоятельно установить предпочтительный метод подтверждения операций. Но у Apple Pay доступно также Face ID (верифицирование через распознавание лица). Для Самсунг и Гугл Пэй имеется на выбор лишь пароль и сканер отпечатков пальцев.
А при выполнении онлайн-оплат у всех систем используется подтверждение транзакции и через связку пароль/сканер с дополнительным вводом кода от банка (его присылают на финансовый номер клиента).
Методы обеспечения безопасности платежей
В этом плане Apple Pay – самый продвинутый. У них не только в смартфонах устанавливается специальный чип для обеспечения безопасной защиты реквизитов банковских карт, но и данные, которые при этом им генерируются, не передаются ни в iOS, ни в iCloud. Поэтому и украсть информацию даже при наличии физического доступа к телефону не получится. Хакерские атаки также невозможны.
Samsung Pay работает схожим образом. Единственная разница – это то, что реквизиты сохраняются дополнительно на серверах Самсунг (для их быстрого восстановления после смены телефона на новый).
Гугл Пэй в плане безопасности считается самым слабым. Но стоит упомянуть, что ещё не было ни единого факта взлома рассматриваемых платёжных систем. Разработчики каждой из них используют самые современные и надёжные варианты защиты и шифрования транзакций и над их усовершенствованием работают сотни лучших программистов. Дополнительно все проводимые платежи защищаются протоколами Visa Secure, Master Pass (как и для обычных транзакций с использованием физической банковской карты).
Итак, нельзя сказать, что Google Pay или платежи через Samsung Pay являются предпочтительным вариантом. Каждая из систем имеет свои сильные и слабые стороны. Продвинутые пользователи рекомендуют не раздумывать над выбором и использовать тот Pay, что лучше оптимизирован для конкретной модели смартфона. Для iPhone – только Эппл Пэй (других вариантов и нет), для Самсунгов – Самсунг Пэй, для остальных телефонов на Андроид – Гугл Пэй (тоже без других вариантов).
Как я перепробовал пять платежных систем для своего сайта
Более трех лет назад я написал пост о выборе платежной системы для приема платежей на своем прошлом проекте. С тех пор прошло довольно много времени и многое в способах приема платежей изменилось. Теперь я расскажу как делал прием платежей на сайте poiskvps.ru.
В настоящее время задача выглядит точно так же: мне нужно было сделать так, чтобы физическое лицо могло принимать платежи у пользователей в автоматическом режиме на своем сайте, имея небольшие обороты.
С технической точки зрения при оплате выполняются следующие операции: пользователю выписывается счет на оплату, пользователь выбирает удобный способ оплаты, переходит на сайт платежной системы, производит оплату и возвращается на сайт. В случае успешной оплаты платежная система оповещает магазин о том, что пользователь оплатил счет.
Яндекс.Деньги
3 года назад эта платежная система не работала с магазинами-физическими лицами. То есть принимать Яндекс.Деньги напрямую можно было только, зарегистрировав юридическое лицо и имея большие обороты. В противном случае платежная система Яндекс.Деньги предлагала работать с различными агрегаторами
Сейчас ситуация изменилась, и Яндекс.Деньги стали работать с физическими лицами без всяких договоров. Единственное условие, для избежания проблем желательно пройти идентификацию.
В настройках кошелька появилось поле, в котором можно задать ссылку для уведомлений о проведенных платежах, а пользователи могут оплатить услуги как Яндекс.Деньгами, так и банковскими картами.
Комиссия у Яндекс.Денег самая низкая из всех платежных систем: за перевод внутренней валюты система берет 0.5% от суммы платежа, при оплате через банковские карты — всего 2%, причем эта комиссия не зависит от суммы платежа. То, что комиссия не зависит от суммы оплаты, выгодно при проведении небольших операций. Например, PayPal помимо 3,9% за операцию берет еще фиксированную сумму 10 рублей за каждую проведенную операцию и при сумме оплаты, например, 100 руб., магазин получит только 86 руб., заплатив почти 14% платежной системе.
Стандартно Яндекс.Деньги предлагают использовать либо “кнопку-приниматель”, либо “форму-приниматель”. В обоих случаях на сайт встраивается фрэйм, который сильно ограничен в возможностях модернизации и изменения дизайна.
Однако если сильно поискать, можно найти документацию для создания своей формы для совершения платежей: money.yandex.ru/i/forms/guide-to-custom-p2p-forms.pdf
Объем документации не большой, и в самом конце можно найти рабочий пример html-кода для интеграции с сайтом:
После того как пользователь совершит платеж, Яндекс.Деньги “перебрасывают” пользователя на заранее заданную страницу, а в это время магазин оповещается об успешном платеже и деньги зачисляются на счет пользователя.
WebMoney
За последние несколько лет со стороны этой платежной системы мало что изменилось. Для приема платежей нужно пройти идентификацию (получить персональный аттестат) и настроить прием платежей на сайте. Документацию можно найти здесь: wiki.webmoney.ru/projects/webmoney/wiki/nastroyka_priema_webmoney_na_sayte_prodavtsa
Пример html кода для интеграции:
Из плюсов данной платежной системы могу отметить наличие “песочницы”, которая делает процесс настройки и отладки более приятным.
За любую операцию система берет стандартную комиссию 0.8% и в отличие от всех других платежных систем эта комиссия берется с покупателя, а не вычитается из суммы, которую получает продавец. Технических сложностей с настройкой платежей у меня не возникало, система работает корректно и не вызывает каких-то проблем. После настройки магазина необходимо пройти модерацию, которая, как правило, осуществляется в течение суток.
QIWI кошелек
От этой платежной системы у меня остались не самые приятные впечатления. Во-первых, совершенно неожиданно была поднята комиссия за совершение операций в три раза: с 1% до 3%, во-вторых техподдержка qiwi оставляет желать лучшего. Ответа можно дожидаться неделями, а качество таких ответов крайне низкое. В какой-то момент на работающем сайте, в котором абсолютно ничего не изменилось, перестали осуществляться платежи через эту платежную систему. Проблема оказалась на стороне qiwi и состояла в неправильной подписи уведомления о платежах. В результате любой запрос от qiwi не проводился в системе из-за некорректной подписи этого запроса. Техподдержка не могла решить проблему в течение полутора недель…
Эта платежная система предлагает использовать либо форму для выставления счета, которая устанавливается на сайт в виде фрэйма, либо аналогично предыдущим ПС использовать html — форму.
Для автоматического оповещения магазина о платежах раньше использовался только SOAP протокол, который, на мой взгляд, менее удобен, чем стандартный вариант с http-запросом. Проблемы с SOAP возникли с момента настройки и возникали в процессе эксплуатации. Не так давно в этой платежной системе появился REST-протокол и работать стало проще. Описание этого протокола можно найти здесь: static.qiwi.com/ru/doc/ishop/protocols/Visa_QIWI_Wallet_Pull_Payments_API.pdf
В итоге: сотрудничать с ПС qiwi не рекомендую, т.к. подключение длительное и сложное, а в случае возникновения проблем на техподдержку не приходится рассчитывать.
РобоКасса
Робокасса не является платежной системой, а представляет собой агрегатор — сервис, через который можно производить оплату различными способами, начиная от WebMoney и заканчивая банками и салонами связи.
Не так давно у Робокассы обновился сайт и стал более удобным для пользователя.
Документация написана достаточно подробно так что проблем с подключением у меня не возникло. Ссылка на документацию: www.robokassa.ru/ru/Doc/ru/Interface.aspx
Из плюсов, аналогично WebMoney, есть песочница и работу можно оттестировать не отправляя реальные деньги.
Робокасса предлагает использовать на своем сайте либо универсальные кнопки, либо html код с расширенными возможностями.
Комиссию РобоКасса берет достаточно большую (иногда до 12%) и что не очень удобно, эта комиссия всегда списывается с пользователя.
RBK Money
Довольно продолжительное время я сотрудничал с RBKMoney. Платежей через эту системы было не много, проблем с настройкой или работой не было, поэтому разрабатывая poiskvps.ru я решил добавить и эту ПС. Из плюсов могу отметить качественную техподдержку — в любое время дня и ночи у них работает онлайн чат, в котором можно поговорить с живым человеком.
К сожалению, 23 мая появилась информация о том, что RBKMoney прекращает сотрудничество с физическими лицами:
Поэтому прием платежей через эту ПС был приостановлен, хотя работать с ними было довольно удобно.
PayPal
Сотрудничество с этой довольно популярной ПС я не начал из-за большого размера комиссии. Фиксированная комиссия в сумме 10 руб. за каждый успешный платеж при небольших суммах операции делает использование этой ПС не выгодным. При оборотах менее 300 тысяч руб. в месяц PayPal берет 3,9% с оборота и 10 руб. за каждую операцию. Соответственно, при проведении операции в размере 100 руб. PayPal удерживает из этой суммы почти 14%. ПС предлагает работу по другим ставкам для микроплатежей (до 300 руб.): 5-6% с оборота и 2 руб. за операцию. Но и это предложение проигрывает другим ПС (например Яндекс.Деньги).
Зато PayPal начал принимать биткоины — правда, пока только в США.
Вывод денег
Ну а теперь самое интересное: на что можно потратить честно заработанное.
Яндекс.Деньги предлагает тратить деньги без комиссии онлайн или выпустить банковскую карту, которой можно расплачиваться в магазинах также без комиссии. За вывод средств на банковский счет комиссия составляет 3% + 15 рублей.
WebMoney предлагает тратить деньги в онлайн магазинах (со стандартной комиссией 0.8%). Также система предлагает переводить деньги банковским переводом без дополнительных наценок. Стоимость платежного поручения всего 15 руб + стандартная комиссия. Деньги зачисляются на счет, как правило в течение суток.
QIWI предлагает единственный способ вывода — на свой же киви кошелек. Далее — тратить в онлайн-магазинах или выпустить банковскую карту для покупок в “реальных” торговых точках.
Робокасса предлагает выводить деньги исключительно на WebMoney, причем комиссию за вывод платить не нужно. Т.е. если на счете в Робокассе есть 1000 руб., то и в кошельке WebMoney окажется 1000 руб.
Итоги
5 место: QIWI
широкая сеть терминалов
высокая комиссия, сложность вывода, плохой саппорт
4 место: PayPal
известная система
большая комиссия на небольших оборотах
3 место: Робокасса
много способов приема платежей
большая комиссия
2 место: WebMoney
Низкая комиссия, дешевый вывод
нужно проходить утомительную идентификацию
1 место: Яндекс.Деньги
низкая комиссия, возможность принимать банковские карты
дорогая «обналичка».
P. S. Спасибо andorro за помощь с подготовкой текста.