Pull to refresh

Comments 20

В своё время делали интеграцию с Альфа-Банком напрямую. То, что сделали вы в своем SDK выглядит гораздо проще, чем то, что пришлось перелопатить нам.

Успехов в развитии!
Экран ввода данных карты среди изображений заметил, а что с 3-D Secure?
3-D Secure — это единственный шаг процесса оплаты, который нельзя встроить «в тело» приложение. Для проведения проверки с помощью протокола 3DS в приложении вызывается браузер с индивидуально сгенерированной страницей банка-эмитента банковской карты.
Как смотрит Apple на то, что не получает 30% с покупок?
Грустно, мы полагаем :)
Но, как подробно описано в части «Какие приложения вообще могут принимать платежи в iOS приложениях не через App Store?», заставить всех делиться 30% прибыли они не могут. Ведь найдется крайне мало типов бизнеса с маржинальностью выше 30%.
То есть можно в игровом приложении организовать продажу маек с напечатанным на груди игровыми достижениями и ссылкой на программу.
С учетом доставки майка будет стоить пользователю не менее $20.
Да без проблем. Любой части гардероба :)

В соответствии с требованиями российских банков-эквайеров потребуется еще простенький сайт, на котором будет перечень маек, информация о приложении, условия доставки и оплаты, контактная информация и информация об ИП (юридическом лице). Пользователям приложения об этом интернет-магазине знать вовсе не обязательно, но для процесса подключения сайт потребуется (см. раздел поста «Что кроме технической интеграции?»).

А сколько будет стоить майка — зависит от любви пользователей к игровому приложению и региону доставки :)
Вообще, к мобильным приложениям имеет отношение стандарт PCI PA DSS, а не PCI DSS (это к сайтам). И данный стандарт и его требования все еще достаточно «аморфны» (применимы только к реализации представления WebView). Надеемся, что Security Standards Council, который пройдет этой осенью, расставит все точки над «i» в отношении сертификации мобильных приложений.

В целом, с приложениями ситуация аналогична сайтам. Если владелец интернет-магазина хочет самостоятельно собирать и передавать платежные данные (в том числе — размещать форму полностью на своей стороне, самостоятельно ее настраивать и т.д.), мы отправляем его получать PCI DSS Level 4. Та же ситуация — с мобильными приложениями.

Получение PCI DSS 4-го уровня — это, кстати, не страшно, не больно и не дорого, как показывает практика наших клиентов. Что будет с PA DSS — покажет время. Так как рынку нужны понятные стандарты, надеемся, что это время не за горами :)
А как можно организовать привязку карты (даже с 3d-secure) так, чтобы в следующий раз не пришлось получать смс-код, а было бы достаточно отпечатка пальца, например, на iPhone? Для такси софта.
Для этого достаточно не проводить авторизацию транзакции по 3D-Secure, как это делается на iPhone. Даже если карта «подписана» на 3D-Secure (карта является «3ds enrolled»), то авторизацию можно проводить без 3D-Secure на уровне процессора/эквайера.

Привязку карты в этом случае делать возможно, данный функционал мы поддерживаем на ряде проектов в РФ и за рубежом. В приведенном примере с Уральскими авиалиниями, использование 3D-Secure оправдано из-за высоких показателей фрода в авиаиндустрии и «дорогих» чарджбеков. Последнее обусловленно высоким средним чеком, фактически стоимостью авиабилета.

Для такси-софта привязка карты и авторизация без 3D-Secure возможна. Обращайтесь :)
Вы предлагаете пароль (privateKey) хранить прямо в приложении? Неужели у пользователей нету никакой возможности его оттуда вытащить, чтобы вызвать метод Refund и вернуть себе деньги после получения товара или услуги?
Добрый день!

Отличный вопрос! Его ждали :)
Возможность вытащить есть, разумеется, при желании. Мы об этом думали, и реализовали отдалено напоминающую авторизацию Google, когда для каждого приложения можно задавать отдельный пароль. Для мобильного приложения заводится специальный MerchantId (и соответственно PrivateKey) с ограниченным функционалом: методы void (отмена транзакции) и refund (полный возврат или частичный возврат) отключаются. Доступнен только метод auth. Мы не думаем, что кто-то из пользователей просто будет платить деньги с карты, как бы «ни за что».
Так можно погубить конкурента.
Ну банки не любят фрод и чарджбеки.
Можно по этому ключу провести несколько транзакций а потом опротестовать. Каждый раз служба безопасности банка будет запрашивать у мерчанта обоснование для проведения платежа и не получив его в n-й раз может сказать «Спасибо, досвидания».
Позвольте не согласиться. Что вы предлагаете — не самый эффективный метод борьбы с конкурентами, не говоря уже о его незаконности.

И можно чуть-чуть упростить задачу. Согласитесь, ведь можно просто зайти к мерчанту на сайт, не обязательно с мобильным приложением, взять его платежную страницу и написать скрипт post на нее данных карт. Верно? Т.е. не тратить время на вытаскивание private key из приложения.

Теперь, почему это неэффективное вредительство:

1. Таких операций должно быть много, существенно, n >> 100.
2. Значит карт для оплаты нужно найти тоже много, дорого :)
3. Написать скрипт для автоплатежей. Что делать если 3D-Secure, например, у Уральских Авиалиний я не знаю, часть платежей точно не пройдет.

Пункты 1-3 займут достаточно времени и денег. И не совсем сработают и вот почему — для борьбы с такого рода фродом у нас работает анти-фрод онлайн система. В общем мерчант не пострадает.

P.S.: СБ банка не запрашивает каждый раз у мерчата обоснование.
Согласитесь, ведь можно просто зайти к мерчанту на сайт
Нет. Если платить через сайт, то обоснование будет(ведь все системы сайта сработают). Если платить напрямую сайт об этом может даже не догадываться.
В остальном конечно согласен.

p.s. Упс. Промахнулся.
Я не полностью описал кейс: на сайт к мерчанту зайти только для того, чтобы получить URL плтаежной страницы.
А про оплаты с сайта через заказ и т.д. вы правы.
Only those users with full accounts are able to leave comments. Log in, please.