Система оплаты android studio

Встраиваем прием платежей в мобильное приложение, или почему можно забыть про PCI DSS и PA DSS

А нужен ли PCI DSS?

Рано или поздно большинство владельцев и разработчиков интернет-магазинов и мобильных приложений, принимающих платежи в онлайне, задаются вопросом: «должен ли мой проект соответствовать требованиям стандартов PCI DSS?».

PCI DSS — это стандарт безопасности, который применяется для всех организаций сферы обработки платежных карт: торговых точек, процессинговых центров, финансовых учреждений и поставщиков услуг, а также других организаций, которые хранят, обрабатывают или передают данные держателей карт и (или) критичные аутентификационные данные.

Стандарт PA-DSS распространяется на поставщиков приложений и иных разработчиков приложений, которые хранят, обрабатывают или передают данные держателей карт и (или) критичные аутентификационные данные.

С веб-сайтом все довольно просто: при интеграции достаточно воспользоваться техническим решением, которое перенаправляет плательщика на форму ввода данных карты, расположенной на сайте PCI DSS сертифицированного платежного шлюза или загружает эту страницу во фрейме также с сертифицированного сайта. В этом случае торговец не подпадает под действия стандарта безопасности, так данные карты не хранятся и не передаются через его сервера, а к фрейму платежного шлюза сайт торговца не имеет доступа в силу политик безопасности web-браузеров.

С мобильным приложением все немного сложнее. Существует популярное заблуждение, что если мобильное приложение запрашивает данные карты, то оно автоматом подпадает под действие стандарта PCI DSS. Но, на самом деле, организация, разрабатывающая стандарты PCI DSS (PCI SSC — Payment Card Industry Security Standards Council) до сих пор не выпустила отдельных требований стандартов для мобильных приложений. А это значит, что стандарт по-прежнему несет не обязательный, а рекомендательный характер для самой популярной категории мобильных приложений, а именно:

Категория 3. Платежные приложения, работающие на каких-либо бытовых карманных устройствах (например, смартфонах, планшетах, КПК), функционал которых ограничен не только принятием платежей.

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

PCI DSS может не распространяться непосредственно на поставщиков платежных приложений, если они не хранят, не обрабатывают или не передают данные держателей карт, или не имеют доступа к данным держателей карт своих клиентов.

Рассмотрим как это реализовано в мобильном SDK платежного сервиса Fondy на примере Android-решения (есть также и iOS SDK).

Решение заключается в том, чтобы данные карты вводились в View, созданным библиотекой SDK, а мобильное приложение использовало публичные методы этого View, для инициализации платежа, стилизации формы и получения информации о завершении оплаты.

Пример demo-приложения для Android

Для начала создадим визуальную структуру нашей платежной формы — layout (кстати, весь исходный код demo-приложения можно найти в github):

Обратите внимание, что все элементы, кроме карточных данных в приложении свои, а форма для ввода номера карты, срока действия и CVV2 инкапсулированы в классе com.cloudipsp.android.CardInputView. Выглядит это примерно так (для тестов можно использовать реквизиты, указанные в документации: https://www.fondy.eu/ru/info/api/v1.0/2):

При этом все элементы, в том числе и принадлежащие классу com.cloudipsp.android.CardInputView, могут быть легко стилизованы под дизайн основного приложения. Также для дальнейшей работы приложения с картами, подключенными к 3DSecure, нам понадобится элемент класса com.cloudipsp.android.CloudipspWebView — это WebView, в котором плательщик будет перенаправлен на сайт своего банка-эмитента для ввода персонального пароля (на данной картинке — страница эмулирующая работу 3dsecure сервера банка эмитента карты:

Теперь перейдем к основному нашему классу, который будет реализовывать логику приложения: public class MainActivity. Инициализируем объект класса Cloudipsp:

Далее навешиваем на объект класса com.cloudipsp.android.Card хендлер для получения результата ввода номера карты:

Теперь мы будем знать, когда пользователь завершит ввод данных, или, в случае ошибки — получим информацию о проблеме. После того, как данные карты введены, мы можем создать заказ:

Как можно видеть, интеграция довольна простая и не требует особых усилий со стороны разработчика приложения. При этом SDK решает две задачи одновременно — дает торговцу инструмент для приема платежей по платежным картам и избавляет его от необходимости проходить сертификацию на стандарты безопасности.

Источник

Интеграция Google Pay

Меня зовут Игорь, я Android-разработчик в команде Trinity Digital. Сегодня я хочу рассказать о классном инструменте — Google Pay API.

Итак, если в вашем приложении можно совершать покупки, и при этом вы используете не In-app Billing (за процессинг отвечает не Google Play), то скорее всего среди вариантов оплаты у вас есть и “Оплата картой”. А это значит, что вам каждый раз приходится отправлять пользователя вводить данные карты или на красиво сверстанные экраны с картой, или на веб-сайт вашего провайдера платежных сервисов (далее — payment processor). Уже посчитали сколько действий придется совершить пользователю, чтобы оплатить заветный заказ? Ага, а теперь представьте, что он сможет выполнить то же целевое действие всего в два тапа. Мы тоже представили и подумали, а почему бы не дать пользователям такую возможность? Основные условия успеха — продавец быть зарегистрирован в Google и payment processor должен сотрудничать с Google.

Список банков России, которые сотрудничают с Android Pay:

АК Барс Банк
Альфа Банк
БИНБАНК
Промсвязьбанк
ВТБ24
Банк Открытие
МТС Банк
Райффайзен Банк
Рокетбанк
Россельхозбанк
Банк Русский Стандарт
Сбербанк
Тинькофф Банк
Точка
Яндекс Деньги

Как все будет выглядеть для пользователя: он попадает на экран выбора типов оплаты в вашем приложении, нажимает на кнопку “Оплатить через Google ”, выбирает нужную карту или оставляет ту, что указана по-умолчанию, нажимает кнопку подтверждения. Готово!
Помните, что Google Pay API позволяет пользователям выбрать любую карту, привязанную или к аккаунту Google, или добавленную в Google Pay.

Теперь перейдем непосредственно к интеграции.

1. Верстка
2. Код
3. Тестирование
4. Отправка на ручную проверку
5. Релиз

1. Верстка

Первое, о чем стоит сказать — предупредите дизайнеров о гайдлайнах. Если кратко по пунктам:

• на экранах ДО ИЛИ на экране, где будет расположена кнопка “Оплатить через Google” должна быть указана стоимость покупки;
• дайте пользователям возможность изменять данные заказа, выбирать тип оплаты [, менять адрес];
• никогда не показывайте данные для оплаты полностью (любые номера, даты и так далее);
• еще раз — “Оплатить через Google” — именно такая надпись должна быть на вашей кнопке, если делаете приложение с поддержкой русского языка;
• Google рекомендует использовать стандартные кнопки. Если вы хотите использовать темную тему или вообще кнопку со своим дизайном, то вам стоит написать в тех. поддержку по адресу androidpay-api-support@google.com. Но даже на кастомной кнопке должно быть лого Google и надпись … да, я надеюсь, вы поняли 🙂 ;
• по ширине ограничений нет, минимальная высота кнопки — 40dp. Если делаете выше/шире, то помните, что текст должен быть отцентрирован.

Соблюдение данных пунктов позволит вам быстрее пройти все проверки и попасть в белый список.

2. Код

Чтобы оплата через Google работала, на телефоне пользователя должны быть установлены Google Play Services версии не ниже 11.4. Но не беспокойтесь, есть специальный метод, который подскажет, можно ли провести оплату или же стоит спрятать кнопку.

Для начала добавим нужные зависимости в build.gradle уровня приложения. Перед внедрением проверяйте актуальность версий!

Далее следует обновить AndroidManifest:

Теперь осталось совсем чуть-чуть:

Создаём PaymentsClient в вашей Activity или в Fragment. Чтобы не захламлять эти классы, можно вынести весь код в методы GooglePaymentUtils, например. Тогда:

Обратите внимание на константы:

WalletConstants.ENVIRONMENT_TEST — пока Google не разрешит выход в боевую среду, вы должны использовать именно её, чтобы самостоятельно протестировать флоу оплаты. Не пугайтесь, когда увидите предупреждение на диалоге Google Pay, что приложение не опознано.
WalletConstants.THEME_LIGHT — светлая тема диалога, также есть темная.

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

PAYMENT_METHOD_CARD, PAYMENT_METHOD_TOKENIZED_CARD — говорят, что мы хотим видеть карточки из Google аккаунта пользователя и карточки, привязанные к Android Pay.

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

Тут запомните, что price — это строчка. И самое важное, даже если вы вызываете AutoResolveHelper.resolveTask из фрагмента, то результат все-равно придет в активити (об этом чуть позже) [на момент написания статьи работает именно так, AutoResolveHelper не умеет возвращать результат во фрагмент].

Тут CURRENCY_CODE = “RUB”.
WalletConstants.TOTAL_PRICE_STATUS_FINAL — говорим, что стоимость покупки окончательная и больше изменяться не будет.

Также есть варианты:
WalletConstants.TOTAL_PRICE_STATUS_ESTIMATED — стоимость примерная, и может измениться, например, после уточнения адреса.
WalletConstants.TOTAL_PRICE_STATUS_NOT_CURRENTLY_KNOWN — еще не знаем, какая стоимость.

Не могу сказать, как на практике поведут себя последние две константы, так как не проверял ¯\_(ツ)_/¯.

Остановимся на PaymentMethodTokenizationParameters и его методе setPaymentMethodTokenizationType:

PAYMENT_METHOD_TOKENIZATION_TYPE_PAYMENT_GATEWAY
используется только если ваш payment processor в списке:

Adyen
Braintree
PaySafe
Stripe
Vantiv
WorldPay

Тогда вместо .addParameter(«publicKey», TOKENIZATION_PUBLIC_KEY)
вы должны написать .addParameter(«gateway», «yourGateway»)
.addParameter(«gatewayMerchantId», «yourMerchantIdGivenFromYourGateway»)

Иначе используется вышеуказанный тип PAYMENT_METHOD_TOKENIZATION_TYPE_DIRECT.
Для этого вам необходимо запросить у провайдера платежных сервисов публичный ключ и передавать именно его в .addParameter(«publicKey», TOKENIZATION_PUBLIC_KEY)

Теперь остается создать запрос.
.setPhoneNumberRequired — должен ли пользователь ввести номер.
.setEmailRequired — должен ли пользователь ввести email
.setShippingAddressRequired — должен ли пользователь выбрать страну. Тут можно ограничить число стран, для которых данная транзакция выполнится.
.addAllowedPaymentMethods — у нас это WalletConstants.PAYMENT_METHOD_CARD — карты из google аккаунта, WalletConstants.PAYMENT_METHOD_TOKENIZED_CARD — карты, добавленные в Google Pay.

В CardRequirements мы указываем, что должны работать карточки систем Visa, Mastercard и других (МИР, например)

Все, мы создали запрос, отправили его через клиента и ждем результат через AutoResolveHelper.

Как вы помните, результат придет в активити.

Вот и все, в paymentData у вас будет токен, который следует отдать вашему серверу. Дальнейшая логика зависит от вашего payment processor.

3. Тестирование

Ничего сложного, просто проверяете, что установлена константа WalletConstants.ENVIRONMENT_TEST, и проходите весь флоу. Списание денег с карточки производиться не будет, вам будет отдаваться тестовый токен, поэтому payment processor должен отклонить оплату.

4. Отправка на ручную проверку

Поздравляю! Вы готовы отправить свой дебаг билд на ручную проверку в Google.
Несколько советов:

• Если ваше приложение поддерживает только русский язык, то подготовьте скриншоты с указаниями, куда нажимать.
• Если есть какая-то специфика в процессе заказа, то подробно опишите.
• Создайте тестовый аккаунт специально для Google и отправьте прямо с билдом.

Отправляете билд на androidpay-api-support@google.com и ждете ответа.

5. Релиз

Вам сказали, что все хорошо и можно выпускать приложение. Первым делом вас попросят активировать приложение по адресу (с аккаунта продавца (merchant)).

Далее вас могут попросить прислать PCI Compliance. Эти документы подтверждают, что ваш payment processor соответствует стандартам безопасности по работе с картами. Запрашиваете у него и отправляете в поддержку.

Как только вы выполнили эти два пункта, вам скажут, что можно поменять WalletConstants.ENVIRONMENT_TEST на WalletConstants.ENVIRONMENT_PRODUCTION. Также может потребоваться поменять TOKENIZATION_PUBLIC_KEY, если вы использовали ключ с тестовой среды вашего payment processor.

Вот и все, теперь протестируйте реальную оплату и можете выпускать релиз в маркет!

Источник

Как добавить In-app Billing в приложение

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

В этой статье мы рассмотрим, как можно реализовать встроенные покупки на примере своего приложения Менеджер паролей от Wi-Fi сетей.

Возможность покупок в приложениях реализована благодаря In-app Billing. In-app Billing — это сервис Google Play, который позволяет продавать цифровой контент внутри приложений. Этот сервис можно использовать для продажи широкого спектра контента, включая загружаемый контент, такой как мультимедийные файлы и фотографии, виртуальный контент, такой как уровни игры или различные вспомогательные предметы, премиальные услуги и многое другое.

Встроенные покупки можно подключить для любого приложения, опубликованного в Google Play. Ничего особенного для этого не требуется, только аккаунт разработчика Google Play Console и аккаунт продавца Google Wallet. Android SDK также содержит пример приложения с реализованными встроенными покупками.

Как работают встроенные покупки?

Ваше приложение обращается к сервису In-app Billing с помощью API, который предоставляется приложением Google Play, установленным на устройстве. Затем Google Play передает платежные запросы и ответы на запросы между вашим приложением и сервером Google Play. Таким образом, ваше приложение никогда напрямую не связывается с сервером Google Play. Вместо этого ваше приложение отправляет запросы в приложение Google Play через межпроцессную связь (IPC) и получает от него ответы, нет необходимости поддерживать какие-либо соединения между вашим приложением и сервером Google Play.

In-app Billing поддерживает широкую совместимость, он работает на устройствах под управлением Android 2.2 (API 8) или выше, на которых установлена последняя версия приложения Google Play.

API In-app Billing предоставляет следующие возможности:

• Ваше приложение отправляет запросы с помощью модернизированного API, который позволяет пользователям легко запрашивать информацию о продукте из Google Play и заказывать продукты в приложении. API быстро восстанавливает продукты на основе прав пользователя.
• API синхронно передает информацию о заказе на устройство при завершении покупки.
• Все покупки регулируемы, т.е. Google Play отслеживает права пользователя на продукты. Пользователь не может владеть несколькими экземплярами одного продукта в приложении; только один экземпляр может принадлежать пользователю в любой момент времени.
• Приобретённые продукты могут быть использованы. В таком случае они возвращаются в бесхозное состояние и могут быть куплены снова.
• API обеспечивает поддержку подписки.

Интеграция In-app Billing в приложение

Есть разные способы, как встроить в своё приложение In-app Billing: можно это делать как вручную, так и используя сторонние библиотеки. Одной из таких библиотек является Checkout, которая уже содержит в себе готовую к применению реализацию сервиса. Ею и воспользуемся.

Checkout — это реализация In-app Billing API. Большим плюсом здесь является, что с помощью этой библиотеки можно сделать интеграцию встроенных покупок в приложение намного проще, чем если бы это делалось вручную с нуля.

Checkout решает общие проблемы, с которыми могут столкнуться разработчики при работе с покупками, например:

• Как отменить все запросы, когда активность уничтожена?
• Как запросить информацию о покупках в фоновом потоке?
• Как проверить покупку?
• Как загрузить все покупки с использованием данных continuationToken или SKU (уникальный идентификатор продукта)?
• Как добавить покупки с минимумом шаблонного кода?

Checkout может быть использован с любым фреймворком или без него. Он имеет четкое разграничение функциональности, доступной в разных контекстах: покупки могут быть сделаны только в активности, тогда как SKU может быть загружен в сервис или класс Application.

Перед началом работы библиотеку нужно добавить в проект. Для этого в файле build.gradle модуля приложения добавить зависимость в блок dependencies.

Для работы с покупками требуется специальное разрешение com.android.vending.BILLING, которое будет добавлено в AndroidManifest.xml автоматически с помощью Gradle. Вы также можете добавить его вручную, добавив в файл манифеста следующую строчку перед элементом :

Создадим экземпляр класса Billing в Application, откуда затем будем брать его при необходимости. Если у вас нет класса Application в проекте, вы можете легко создать его. Для этого нужно добавить в файле AndroidManifest.xml в элемент атрибут android:name=».Имя класса», например:

После этого нужно поставить курсор на имя класса, нажать Alt + Enter и выбрать опцию «Create class», после чего Android Studio создаст его.

В этом классе нам нужно добавить следующий код:

BASE64_PUBLIC_KEY это ключ, который используется для установления безопасного подключения между вашим приложением и сервером Google Play. Получить этот ключ вы можете в Google Play Console, перейдя в раздел «Инструменты разработки» — «Службы и API». Там в «Лицензирование и продажа контента» вы увидите сгенерированный для вашего приложения ключ, который нужно будет добавить в приложение, например, объявить как строковую константу в классе Application.

Класс Billing это основной класс для работы с библиотекой, он отвечает за:

• подключение и отключение услуг биллинга;
• выполнение платежных запросов;
• кеширование результатов запросов;
• создание объектов Checkout;
• логирование;

Для того, чтобы избежать множественных подключений к службе In-app Billing, следует использовать только один экземпляр класса Billing, именно по этой причине мы и создаём его в классе Application.

Теперь в классе активности при её создании инициализируем экземпляр класса ActivityCheckout, который наследует от базового класса Checkout.

Класс Checkout это средний уровень библиотеки, он использует класс Billing в определённом контексте (в Application, активности или сервисе), проверяет, поддерживаются ли покупки на устройстве и выполняет запросы. ActivityCheckout это подкласс, который способен покупать различные предметы, для создания его экземпляра нужно вызвать метод Checkout.forActivity() и передать в параметры активность и экземпляр Billing.

Метод start() запускает созданный экземпляр и отправляет запрос, который проверяет, поддерживается ли биллинг на этом устройстве.

Метод createPurchaseFlow() создаёт постоянный поток для покупок со слушателем, который будет получать обновления данных о покупках. Код слушателя выглядит следующим образом:

Класс PurchaseListener наследует от EmptyRequestLisneter

, который имеет методы onSuccess() и onError(). В данном случае, если пользователь купит отключение рекламы или сделает пожертвование, то слушатель получит данные о покупке и выполнит нужные операции.

Теперь нужно создать экземпляр класса Invertory.

Класс Invertory загружает данные о продуктах, SKU и покупках. Его жизненный цикл связан с жизненным циклом Checkout, в котором он был создан.

Метод makeInvertory() создаёт экземпляр Invertory и привязывает его к нужному объекту Checkout.

Метод load() отправляет запрос на получение данных о продуктах и асинхронно загружает результат в callback. В параметрах формируется запрос, какие именно продукты нужно получить (в данном случае, все имеющиеся, а именно донаты и отключение рекламы). Код коллбека, который принимает результат запроса, представлен ниже:

Метод onLoaded() вызывается, когда все данные загружены. В нём проверяются различные данные о продуктах. Например, можно проверить с помощью поля supported можно проверить, поддерживается ли продукт, а метод getSku() возвращает идентификатор продукта. Если нужно узнать стоимость продукта на основе локали устройства, то следует вызывать getSku(TYPE).price.

Метод isPurchased() проверяет, был ли продукт куплен пользователем. В случае с рекламой это будет означать, что её следует отключать.

Теперь нужно отправлять платёжные запросы сервису. Для этого в настройках приложения есть две кнопки «Удалить рекламу» и «Поддержать проект материально».

Обработка кнопки отключения рекламы выглядит следующим образом:

С помощью данного метода формируется запрос на покупку продукта, результат которого будет получен коллбеком.

Аналогичным образом формируется запрос на донат.

Таким образом, с помощью библиотеки мы реализовали встроенные покупки в приложении без использования шаблонного кода.

Как добавить In-app Billing в приложение : 6 комментариев

А физ. лицо может зарегистрировать Google Wallet? Или нужно ИП открывать?

Может, в этом плене Google очень демократичная компания. Выплаты начнутся по достижении порога в 100$

А как тестировать покупки? Я прописал в play console тестового пользователя и через него покупаю например рекламу. Деньги не списываются но покупка числиться у него в google play.
Но в классе InventoryCallback mPurchases = 0.
Как правильно тестировать?

Здравствуйте! К сожалению, насчёт тестирования не получится что-либо подсказать, попробуйте написать автору библиотеки на гитхабе.

Источник