Прежде чем переходить к детальному рассмотрению Payment SDK для iOS и обсуждению специфики требований к App Store, мы хотим поделиться с вами статистикой PayOnline по мобильным платежам за последние три года.
Взрыв мобильного трафика в 2013 — 2015
Когда в начале 2010-х мы запускали продукт для приема платежей с мобильных устройств и из мобильных приложений Pay-Mobile, мы даже не подозревали, какой дикий рост покажет мобильный трафик уже в ближайшие несколько лет.
Сегодня из каждого утюга несется история о начале эпохи мобильной коммерции, но получить адекватные, точные, а главное —локализованные на Россию статистические данные получается с трудом. Вводя в Google запрос «доля iOS в России», мы получаем множество приблизительных цифр, основанных на мировой статистике и показателях продаж устройств по отчетам крупнейших торговых сетей.
К счастью, мы ежедневно обрабатываем десятки тысяч платежей и имеем доступ к реальным показателям того, с чего же россияне платят в Интернете. Сегодня мы покажем вам данные с 2013 по 2015 год, за которые считанные проценты оплат с мобильных устройств превратились в пятую часть нашего платежного трафика.
В 2013 году мобильный трафик рос более чем в 2 раза быстрее «десктопного», а в 2014 — более чем в 6 раз. И, судя по всему, в ближайшие годы это движение не остановить. На диаграмме ниже представлены показатели мобильного трафика за последние 3 года с разделением по ключевым мобильных операционным системам.
Отметим, что эти цифры распределены по устройствам, с которых были успешно совершенны платежи через PayOnline. Чистый коммерческий трафик без примеси интернет-серферов и пользователей бесплатных приложений :)
Переходим к Payment SDK PayOnline для iOS
Payment SDK для приложений iOS позволяет разработчикам легко и непринужденно интегрировать прием платежей по банковским картам в мобильное приложение. Зачем разработчику приложения Payment SDK можно прочитать в материале, который мы опубликовали в блоге в начале года.
Что самое главное? Главное, что интегрировав прием платежей с помощью SDK для iOS, вы избежите WebView. Все элементы процесса оплаты встраиваются в мобильное приложение и кастомизируются под его дизайн.
Объясняя в двух словах: SDK позволяет избежать погружения в пучины интеграции с платежным шлюзом, реализации протокола безопасности 3-D Secure и других нецелевых расходов времени и сил. Но прежде чем переходить к вопросам интеграции, стоит разобраться в непростых правилах Apple по отношению к сторонним платежным сервисам в приложениях.
Какие приложения вообще могут принимать платежи в iOS приложениях не через App Store?
Вопрос о том, можно ли вообще принимать платежи в iOS приложениях волнует умы разработчиков и владельцев не первый год, вызывая многочисленные дискуссии.
Чтобы разобраться в этом вопросе, мы обратились к первоисточнику — «App Store Review Guidelines», главе 11 «Purchasing and currencies».
11.1 Apps that unlock or enable additional features or functionality with mechanisms other than the App Store will be rejected
11.2 Apps utilizing a system other than the In-App Purchase API (IAP) to purchase content, functionality, or services in an App will be rejected
11.3 Apps using IAP to purchase physical goods or goods and services used outside of the App will be rejected
11.4 Apps that use IAP to purchase credits or other currencies must consume those credits within the App
11.5 Apps that use IAP to purchase credits or other currencies that expire will be rejected
11.6 Content subscriptions using IAP must last a minimum of 7 days and be available to the user from all of their iOS devices
11.7 Apps that use IAP to purchase items must assign the correct Purchasability type
11.8 Apps that use IAP to purchase access to built-in capabilities provided by iOS, such as the camera or the gyroscope, will be rejected
11.9 Apps containing content or services that expire after a limited time will be rejected, except for specific approved content (e.g. films, television programs, music, books)
11.10 Insurance Apps must be free, in legal-compliance in the regions distributed, and cannot use IAP
11.11 In general, the more expensive your App, the more thoroughly we will review it
11.12 Apps offering subscriptions must do so using IAP, Apple will share the same 70/30 revenue split with developers for these purchases, as set forth in the Program License Agreement
11.13 Apps that link to external mechanisms for purchases or subscriptions to be used in the App, such as a «buy» button that goes to a web site to purchase a digital book, will be rejected
11.14 Apps can read or play approved content (specifically magazines, newspapers, books, audio, music, video and cloud storage) that is subscribed to or purchased outside of the App, as long as there is no button or external link in the App to purchase the approved content. Apple will only receive a portion of revenues for content purchased inside the App
11.15 Apps may only use auto-renewing subscriptions for periodicals (newspapers, magazines), business Apps (enterprise, productivity, professional creative, cloud storage), and media Apps (video, audio, voice), or the App will be rejected
11.16 Apps may enable additional approved features or functionality when used in combination with specific approved physical products (such as a toy) as long as the additional features and functionality are either completely dependent on such hardware (for example an App that is used to control a telescope) or also available through the App without the physical products, such as by way of reward for achievement or by use of IAP
11.17 Apps may facilitate transmission of approved virtual currencies provided that they do so in compliance with all state and federal laws for the territories in which the app functions
Если не вдаваться в дословный перевод, суть требований Apple такова: все товары и услуги виртуального и цифрового плана должны быть оплачены через App Store. Иначе приложение будет удалено.
Таким образом, наш Payment SDK не смогут использовать владельцы игровых, развлекательных приложений, продавцы цифрового контента и т.д. Вопрос виртуальных товаров является пограничным, но чаще всего также решается в пользу приема платежей через App Store. Так, например, интернет-магазин цифровых книг ЛитРес принимает платежи в приложении на Android через PayOnline, а вот на iOS — через App Store.
Другое дело, если вы сделали мобильное приложение для своего интернет-магазина, туристического агентства или авиакассы. Результатом сделки между вами и вашим покупателем является физический товар или физический документ, подтверждающий право пользования услугой. В таком случае вы можете спокойно интегрировать прием платежей через сторонний платежный сервис и оперативно получать средства на свой счет в банке, не теряя время и деньги на недоброй комиссии App Store.
Как работает Payment SDK PayOnline для iOS?
Для подключения SDK необходимо добавить в проект библиотеку libPayOnlineSdk.a и папку PayOnlineSdk, содержащую header-файлы (скачать библиотеку можно здесь).
Для выполнения платежа нужно:
1. Создать объект конфигурации PayOnlineConfiguration.
PayOnlineConfiguration *payOnlineConfiguration = [PayOnlineConfiguration configurationWithMerchantId:12345 privateKey: @"12-34-5"];2. Реализовать методы протокола PayOnlineDelegate.
@implementation ViewController
...
#pragma mark - PayOnlineDelegate methods
(void)payOnlineSuccess:(PayOnlinePayResponse *)response { // платеж прошел успешно }
(void)payOnlineDeclined:(PayOnlinePayResponse *)response { // платеж отклонен }
// необходима проверка 3DS
(void)payOnlineThreeDsRequired:(PayOnlinePayResponse *)response { // создаем и показываем встроенный браузер UIWebView *webView = [[UIWebView alloc] initWithFrame:self.view.bounds]; [self.view addSubview:webView]; // открываем страницу банка-эмитента во встроенном браузере [self.processing navigateToAcsUrl:response delegate:self webView:webView]; }
(void)payOnlineError:(PayOnlineError *)error { // ошибка }
@end3. Создать объект платежа PayOnlinePayRequest.
PayOnlinePayRequest *payRequest = [[PayOnlinePayRequest alloc] init];
payRequest.email = @"test@payonline.com";
payRequest.cardNumber = @"4444333322221111";
payRequest.ip = @"127.0.0.1";
payRequest.cardExpMonth = 1;
payRequest.cardExpYear = 2015;
payRequest.cardHolderName = @"NAME SURNAME";
payRequest.cardCvv = 123;
payRequest.amount = [NSDecimalNumber decimalNumberWithString:@"120.00"];
payRequest.currency = PayOnlineCurrencyRub;
payRequest.orderId = @"order12345";4. Создать объект PayOnlineProcessing на основе конфигурации среды выполнения и вызвать метод pay.
PayOnlineProcessing *processing = [PayOnlineProcessing processingWithConfig:payOnlineConfiguration];
[processing pay:payRequest delegate:payOnlineDelegate];5. Работа метода pay завершится вызовом одного из методов payOnlineDelegate.
Пример реализации — мобильное приложение «Уральских авиалиний» для iOS
Одним из первых клиентов нашей компании, использовавшим SDK для интеграции платежного сервиса в мобильное приложение под iOS, стала авиакомпания «Уральские авиалинии».
В результатах поиска выбираем подходящий рейс:
Подтверждаем количество пассажиров и стоимость:
Вводим данные о пассажире:
И данные плательщика. На введенный адрес электронной почты PayOnline отправит платежную квитанцию сразу после завершения оплаты:
После этого билет бронируется, чтобы в тот момент, когда вы совершаете оплату, никто не купил ваш билет прямо «у вас перед носом» (что может быть особенно обидно, если билет был последний):
И, наконец, оплата. Как вы видите, дизайн платежной формы ничем не отличается от оформления остальных экранов мобильного приложения. А лаконичность формы позволяет минимизировать долю отказов на стадии оплаты:
Экран обработки оплаты также соответствует общему дизайну приложения:
Экран завершения оплаты мы не сделали, так как в на тот момент Екатеринбург лететь никто не собрался :)
Но данные мониторинга ежедневно сообщают об успешных платежах через приложение.
Что кроме технической интеграции?
Юридическое лицо
Заключить договор с PayOnline может только юридическое лицо или индивидуальный предприниматель.
Сайт
Проще всего подключить прием платежей в мобильном приложении, если у вас уже есть интернет-магазин или иной коммерческий сайт. В ходе подключения приема платежей через процессинговый центр (или через банк напрямую) вам будет выдан так называемый «терминал» — идентификатор вашего сайта. Напрямую с мобильными приложениями подавляющее большинство банков в России не работает. Их подключают после сайта и выдают на приложение дополнительный терминал.
Поэтому, если у вас нет сайта, для безболезненного и простого подключения приема платежей в приложениях вам потребуется сделать простой сайт-визитку, соответствующий минимальным требованиям.
Ставка комиссии
Ставка комиссии определяется индивидуально в зависимости от оборота платежей в приложении и уровня рисков с вашем сегменте бизнеса. Логика понятна: выше оборот — ниже ставка, выше риски — выше ставка.
Выплаты
Средства перечисляются на ваш расчетный счет в банке на 2-й или 6-й день (в зависимости от выбранного базового платежного продукта).
Вот и все, что мы хотели рассказать сегодня о Payment SDK для iOS и специфике настройки приема платежей в мобильных приложениях на iOS. С удовольствием ответим на ваши вопросы в комментариях!
Комментарии (20)
tanz_sullamora
10.06.2015 13:33Экран ввода данных карты среди изображений заметил, а что с 3-D Secure?
PayOnline Автор
10.06.2015 13:403-D Secure — это единственный шаг процесса оплаты, который нельзя встроить «в тело» приложение. Для проведения проверки с помощью протокола 3DS в приложении вызывается браузер с индивидуально сгенерированной страницей банка-эмитента банковской карты.
Anakros
10.06.2015 14:29+1Как смотрит Apple на то, что не получает 30% с покупок?
PayOnline Автор
10.06.2015 14:32+1Грустно, мы полагаем :)
Но, как подробно описано в части «Какие приложения вообще могут принимать платежи в iOS приложениях не через App Store?», заставить всех делиться 30% прибыли они не могут. Ведь найдется крайне мало типов бизнеса с маржинальностью выше 30%.
PapaBubaDiop
10.06.2015 16:24То есть можно в игровом приложении организовать продажу маек с напечатанным на груди игровыми достижениями и ссылкой на программу.
С учетом доставки майка будет стоить пользователю не менее $20.PayOnline Автор
10.06.2015 16:41+1Да без проблем. Любой части гардероба :)
В соответствии с требованиями российских банков-эквайеров потребуется еще простенький сайт, на котором будет перечень маек, информация о приложении, условия доставки и оплаты, контактная информация и информация об ИП (юридическом лице). Пользователям приложения об этом интернет-магазине знать вовсе не обязательно, но для процесса подключения сайт потребуется (см. раздел поста «Что кроме технической интеграции?»).
А сколько будет стоить майка — зависит от любви пользователей к игровому приложению и региону доставки :)
rainwall
10.06.2015 16:25На приложение с приемом платежей нужно же получать PCI DSS?
PayOnline Автор
10.06.2015 17:24+1Вообще, к мобильным приложениям имеет отношение стандарт PCI PA DSS, а не PCI DSS (это к сайтам). И данный стандарт и его требования все еще достаточно «аморфны» (применимы только к реализации представления WebView). Надеемся, что Security Standards Council, который пройдет этой осенью, расставит все точки над «i» в отношении сертификации мобильных приложений.
В целом, с приложениями ситуация аналогична сайтам. Если владелец интернет-магазина хочет самостоятельно собирать и передавать платежные данные (в том числе — размещать форму полностью на своей стороне, самостоятельно ее настраивать и т.д.), мы отправляем его получать PCI DSS Level 4. Та же ситуация — с мобильными приложениями.
Получение PCI DSS 4-го уровня — это, кстати, не страшно, не больно и не дорого, как показывает практика наших клиентов. Что будет с PA DSS — покажет время. Так как рынку нужны понятные стандарты, надеемся, что это время не за горами :)
z0rgoyok
10.06.2015 23:51А как можно организовать привязку карты (даже с 3d-secure) так, чтобы в следующий раз не пришлось получать смс-код, а было бы достаточно отпечатка пальца, например, на iPhone? Для такси софта.
PayOnline Автор
11.06.2015 07:41+1Для этого достаточно не проводить авторизацию транзакции по 3D-Secure, как это делается на iPhone. Даже если карта «подписана» на 3D-Secure (карта является «3ds enrolled»), то авторизацию можно проводить без 3D-Secure на уровне процессора/эквайера.
Привязку карты в этом случае делать возможно, данный функционал мы поддерживаем на ряде проектов в РФ и за рубежом. В приведенном примере с Уральскими авиалиниями, использование 3D-Secure оправдано из-за высоких показателей фрода в авиаиндустрии и «дорогих» чарджбеков. Последнее обусловленно высоким средним чеком, фактически стоимостью авиабилета.
Для такси-софта привязка карты и авторизация без 3D-Secure возможна. Обращайтесь :)
stepik777
11.06.2015 00:52+1Вы предлагаете пароль (privateKey) хранить прямо в приложении? Неужели у пользователей нету никакой возможности его оттуда вытащить, чтобы вызвать метод Refund и вернуть себе деньги после получения товара или услуги?
PayOnline Автор
11.06.2015 07:28Добрый день!
Отличный вопрос! Его ждали :)
Возможность вытащить есть, разумеется, при желании. Мы об этом думали, и реализовали отдалено напоминающую авторизацию Google, когда для каждого приложения можно задавать отдельный пароль. Для мобильного приложения заводится специальный MerchantId (и соответственно PrivateKey) с ограниченным функционалом: методы void (отмена транзакции) и refund (полный возврат или частичный возврат) отключаются. Доступнен только метод auth. Мы не думаем, что кто-то из пользователей просто будет платить деньги с карты, как бы «ни за что».rainwall
11.06.2015 08:47Так можно погубить конкурента.
PayOnline Автор
11.06.2015 09:07Конкурента кого и как?
rainwall
11.06.2015 09:10Ну банки не любят фрод и чарджбеки.
Можно по этому ключу провести несколько транзакций а потом опротестовать. Каждый раз служба безопасности банка будет запрашивать у мерчанта обоснование для проведения платежа и не получив его в n-й раз может сказать «Спасибо, досвидания».PayOnline Автор
11.06.2015 09:22Позвольте не согласиться. Что вы предлагаете — не самый эффективный метод борьбы с конкурентами, не говоря уже о его незаконности.
И можно чуть-чуть упростить задачу. Согласитесь, ведь можно просто зайти к мерчанту на сайт, не обязательно с мобильным приложением, взять его платежную страницу и написать скрипт post на нее данных карт. Верно? Т.е. не тратить время на вытаскивание private key из приложения.
Теперь, почему это неэффективное вредительство:
1. Таких операций должно быть много, существенно, n >> 100.
2. Значит карт для оплаты нужно найти тоже много, дорого :)
3. Написать скрипт для автоплатежей. Что делать если 3D-Secure, например, у Уральских Авиалиний я не знаю, часть платежей точно не пройдет.
Пункты 1-3 займут достаточно времени и денег. И не совсем сработают и вот почему — для борьбы с такого рода фродом у нас работает анти-фрод онлайн система. В общем мерчант не пострадает.
P.S.: СБ банка не запрашивает каждый раз у мерчата обоснование.
rainwall
11.06.2015 10:07Согласитесь, ведь можно просто зайти к мерчанту на сайт
Нет. Если платить через сайт, то обоснование будет(ведь все системы сайта сработают). Если платить напрямую сайт об этом может даже не догадываться.
В остальном конечно согласен.
p.s. Упс. Промахнулся.PayOnline Автор
11.06.2015 10:23Я не полностью описал кейс: на сайт к мерчанту зайти только для того, чтобы получить URL плтаежной страницы.
А про оплаты с сайта через заказ и т.д. вы правы.
itruf
В своё время делали интеграцию с Альфа-Банком напрямую. То, что сделали вы в своем SDK выглядит гораздо проще, чем то, что пришлось перелопатить нам.
Успехов в развитии!
PayOnline Автор
Спасибо большое!