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


Найдено 1528 сообщений
Cообщения с меткой

платежные системы - Самое интересное в блогах

Следующие 30  »
rss_rss_hh_new

[Перевод] Последние тенденции в онлайн платежах

Вторник, 26 Июля 2016 г. 13:35 (ссылка)

image



В этой статье представлены последние тенденции в онлайн платежах, с точки зрения покупателя и продавца.



С точки зрения продавца



Рост доли альтернативных способов оплаты


Помимо оплаты кредитной картой и оплатой с помощью виртуального кошелька, любой другой способ оплаты может упоминаться как альтернативный метод оплаты. Доля рынка альтернативных способов оплаты выросла за последние пару лет, и в некоторых странах они действительно догоняют по объему долю традиционных онлайн методов оплаты, кредитные карты, к примеру.

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

Дополнительные движущие факторы для принятия альтернативных способов оплаты относятся к стоимости самой транзакции, рискам, скорости расчетам и принятия, поддержке и спонсированию местными игроками рынка. Онлайн продавцы предпочитают низкие затраты, гарантированные платежи и использование международной системы SWIFT для увеличения кэш флоу. Альтернативные способы оплаты, которые основываются на существующих банковских платежных рельсах (банковские переводы, прямые дебеты) обеспечивают простоту и удобство как для продавцов. так и для покупателей.

Важным стимулом для использования альтернативных способов оплаты является то, что те покупатели, которые имеют доступ к кредитным картам, иногда не желают использовать свои карты при оплате в Интернете. Они напуганы тем, что данные карты могут быть украдены и использованы обманным путем. Поэтому покупатели ищут такие способы оплаты для себя, которые дают уверенность и чувство безопасности при оплате онлайн.



Популярность электронных кошельков растет


Помимо альтернативных способов оплаты, все больший и больший оборот по всему миру набирают электронные кошельки. Часто они разрабатываются с ориентиром на мобильные устройства. Как растет популярность использования смартфонов и планшетов, с такой же прогрессией растет популярность электронных кошельков. Многие электронные кошельки (MasterPass, V.me от Visa, PayPal), были разработаны для более простого, быстрого и легкого выполнения платежей, сделанных через мобильные устройства.



Оптимизация конверсии


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

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



Межбанковские комиссии снижаются


В США и в Европе взаимные комиссии для четвертой стороны при оплате, например, для MasterCard и Visa, были вытеснены регуляторами. Взаимные комиссии относятся к тем сборам, которые должны быть оплачены владельцем карты эмитенту для каждой обрабатываемой сделки. Эти сборы представляют собой значительную долю сборов за использование торговых точек, принимающих банковские карты, или торговую комиссию. Из-за возросшей конкуренции ожидается, что продавцы выиграют в результате более низких комиссионных ставок.

Усиление конкуренции между провайдерами платежных услуг и банками — эквайрерами

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



Универсальные магазины


Существует тенденция, управляемая схемой, которая позволяет провайдерам платежных услуг получать денежные средства от сделок с продавцами. Заключается она в том, что все больше и больше провайдеров платежных услуг используют агрегатную модель оплаты услуг. Эта модель позволяет им подписаться на онлайн-продавцов, предложить одну точку доступа для приема платежей онлайн и их урегулирования при необходимости, и сохраняет полный контроль над бизнес-отношениями.

Для многих продавцов это даже проще, поскольку они имеют дело только с агрегаторами. Нет необходимости контактировать с провайдерами платежных услуг и эквайерами.



С точки зрения покупателя



Восприятие покупателями процесса совершения покупок в цифровой реальности


При обычной покупке в магазине платежи производятся в одном месте и в одно время. При совершении покупок в Интернете покупатель и продавец оторваны от времени и места. Это приводит к изменению восприятия рисков, участвующих в сделке. Для успешного использования е коммерс как продавцу, так и покупателю, очень важно доверие. Совершая покупку в Интернете, покупатель идентифицирует себя с обычной жизнью, как если бы он сначала шел в магазин, потом оплачивал выбранный товар, а потом бы ждал доставку.

Когда покупатель с самого начала совершения покупки отождествляет себя самым обычным покупателем, понимает все этапы совершения покупки и разрешает оплату, то это ведет к беспроблемному осуществлению платежа. Кроме того, это позволяет продавцу предложить клиенту какие-нибудь дополнительные персонализированные услуги, которые имеют значение для данного конкретного клиента, увеличивая таким образом коэффициент конверсии. Примеры таких цифровых решений можно увидеть у компаний BankID, Personalausweis, .beID, Idensys, iDIN.



Покупки и платежи при помощи мобильных устройств


Во всем мире доля смартфонов среди обычных мобильных телефонов стремительно растет. 9 миллиардов устройств по всему миру в настоящее время подключены к сети Интернет, в том числе компьютеры и смартфоны. И как ожидается, это число резко возрастет в течение следующего десятилетия от 50 млрд устройств до 1 трлн. Мобильные устройства все чаще используются в различных целей:




  • В магазине: поиск информации о продукте и сравнение цен в интернет-магазинах конкурентов




  • На ходу: мобильная коммерция позволяет пользователям сразу же увидеть своими глазами товары, не садясь за экран компьютера. При использовании функции GPS так же можно найти необходимый товар или магазин согласно своему местонахождению. Все существующие способы оплаты должны быть адаптированы для мобильных приложений магазина.




  • Мобильные устройства требуют различного взаимодействия с пользователями из-за меньшего экрана и иного способа ввода данных по сравнению со стационарным компьютером




  • Пользователи хотят использовать привычные им онлайн методы оплаты, адаптированные для мобильного устройства




  • Развитие технологий в будущем позволит более глубокую интеграцию между мобильными телефонами и POS-терминалами, объединит рекламу, платежи и начисление бонусных баллов. Это увеличит потребность в новых способах оплаты, которые способны легко встраиваться в цепочку покупок.




  • Мобильные устройства обеспечат PoS терминалы более дешёвыми технологиями для принятия онлайн и офлайн платежей.





Электронные кошельки и приложения для телефона


Электронные кошельки предлагают услуги по оплате, хранение данных по оплате и личных данных пользователя. Цель электронных кошельков:




  • увеличение скорости оплаты и удобство для покупателей;




  • обеспечение продавцов конверсией и клиентами



В настоящее время существует огромное количество сервисов с электронными кошельками, предлагающих свои услуги для продавцов и покупателей, что привело к «войне электронных кошельков». В настоящее время рынок демонстрирует разнообразный охват, прием и поддержку каналов. Сузествуют интернет- и PoS-кошельки, а так же омниканальные кошельки. Электронные кошельки могут быть использованы в различных целях и с помощью множества устройств (стационарные ПК, планшеты, мобильные телефоны). Ожидается, что в будущем появятся многие дополнительные и усовершенствованные услуги. Примерами могут служить: MasterPass, V.me от Visa, PayPal



Процесс сближения каналов продаж


Поскольку опыт использования Интернета у населения продолжает расти, потребители по умолчанию при совершении покупки учитывают оба канала, как офлайн, так и онлайн. Помимо этого, у продавцов существует растущая возможность использовать эти же два канала, создавая омниканальный опыт продаж для покупателя. Нормой считается осуществить покупку онлайн, а затем забрать товар в офлайн магазине или пункте самовывоза. Так же покупатели очень ценят и довольно часто пользуются возможностью вернуть товар назад при заказе онлайн. Или же, например, покупатель мерил в магазине понравившуюся модель джинсов, а его размер закончился – тогда он может заказать нужный размер в интернет-магазине и получить товар уже у себя дома. Для потребителя эта тенденция означает, что нет больше различий между обычной покупкой, покупкой через интернет или покупкой с помощью мобильного телефона. Есть просто покупка. Платежи же индивидуальны для каждого отдельного заказа, в офлайне и онлайне они отличаются друг от друга.

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



Контроль личных данных покупателем


Необходимость снова и снова регистрироваться в различных интернет-магазинах заставляет покупателей оставлять множество личной информации в Интернете. Важная информация остается разбросанной по Интернету, что делает ее уязвимой для мошенников. Это так же вызывает многие риски нарушения конфиденциальности, особенно когда в Интернете или в автономном режиме личные данные используются для аналитики.



В качестве реакции на вышеперечисленные недостатки, возникла интересная тенденция превращения общедоступных данных в закрытые. Платформы Life Management и Personal Data Ecosystems предоставляют пользователям возможность сохранять полный контроль над своими личными данными и позволяют определить, какие данные с какой компанией совместимы. Особенно это важно для платежей, которые включают в себя конфиденциальные данные, и для них существует растущая потребность в безопасности. В свете этой тенденции мы видим как развиваются такие способы оплаты, как, например, Bitcoin.



С уважением команда фулфилмент-оператора «Ямбокс»

(мы занимаемся логистикой для e-commerce)






image
Original source: habrahabr.ru (comments, light).

https://habrahabr.ru/post/306418/

Комментарии (0)КомментироватьВ цитатник или сообщество
rss_rss_hh_new

Stripe: сервис вашей мечты для автоматизации денежных переводов

Понедельник, 25 Июля 2016 г. 15:05 (ссылка)

Имевшие дело с сервисом электронных платежей Stripe знают, что он отлично заточен под разработчиков. Его документация написана людьми для людей; есть хороший тестовый режим — полная копия реального, и для перехода на live-режим нужно только заменить ключи, не трогая API и не получая никаких сюрпризов; админка тестового режима — тоже полная копия боевого. В общем, Stripe — это хорошо, и я хочу посвятить эту статью базовым вопросам интеграции сервиса в e-Commerce-проект, объяснив процессы на конкретных и абстрактных примерах. Надеюсь, что мой опыт поможет всем, кто хочет попробовать Stripe на своём проекте.



Однако перед тем, как использовать Stripe, задайте вопрос: «А где находится бизнес, который мы будем обслуживать?». Например, если бизнес российский, Stripe для нас бесполезен: принимать платежи можно из любой страны, но бизнес владельца аккаунта на Stripe должен быть юридически зарегистрирован в одной из доступных стран. Иначе создать и авторизовать аккаунт невозможно. Список стран можно посмотреть здесь. Если вы хотите выводить деньги на другие счета, например, поставщикам (как это делать, я расскажу ниже), то юридически поставщики тоже должны находиться в странах, с которыми работает Stripe. Бизнес клиента, с которым работала я, зарегистрирован в Америке, что позволяло проводить платежи через Stripe.



Также нужно быть готовым, что Stripe не поддерживает xml-протокол 3-D-secure, который требует от клиента вводить код подтверждения, полученный в SMS-сообщении. Stripe просто пытается провести платеж без этой опции, и если банк принимает платежи без 3-D Secure — хорошо, если нет — всё закончится отказом, и с этой карты платить не получится.



Проведение платежа



Чтобы перевести деньги с карточки клиента на наш Stripe-аккаунт, нам нужно сделать следующее. С помощью скрипта Stripe.js получим на фронтенде Stripe token. Дальше мы будем использовать token с серверной стороны, чтобы провести сам платёж.



Подключаем Stripe.js и указываем публичный ключ:






Делаем обычную HTML-форму, на input указываем атрибуты data-stripe для работы скрипта. Нам будет нужен номер карты клиента, год и месяц валидности карты и CVC. Имя и фамилию владельца Stripe не требует.















Теперь получим token:



$(function() {
var $form = $('#payment-form');
$form.submit(function(event) {
// Отключим кнопку, чтобы предотвратить повторные клики
$form.find('.submit').prop('disabled', true);

// Запрашиваем token у Stripe
Stripe.card.createToken($form, stripeResponseHandler);

// Запретим форме submit
return false;
});
});

function stripeResponseHandler(status, response) {
// Grab the form:
var $form = $('#payment-form');

if (response.error) { // Problem!

// Показываем ошибки в форме:
$form.find('.payment-errors').text(response.error.message);
$form.find('.submit').prop('disabled', false); // Re-enable submission

} else { // Token был создан

// Получаем token id:
var token = response.id;

// Вставим token в форму, чтобы при submit он пришел на сервер:
$form.append($('').val(token));

// Сабмитим форму:
$form.get(0).submit();
}
};


На всякий случай: этот шаг описан в официальной документации.



Теперь мы можем списать деньги с клиента через сервер. Примеры кода на PHP.



// Устанавливаем секретный ключ 
\Stripe\Stripe::setApiKey("your_secret_key");

// Забираем token из формы
$token = $_POST['stripeToken'];

// Создаём оплату
try {
$charge = \Stripe\Charge::create(array(
"amount" => 1000, // сумма в центах
"currency" => "usd",
"source" => $token,
"description" => "Example charge"
));
} catch(\Stripe\Error\Card $e) {
// Платёж не прошёл
}


Это всё, что нужно сделать, чтобы перевести деньги с карты клиента на ваш Stripe счет.



Автоматические переводы денег вашим поставщикам



Теперь рассмотрим перевод на рабочем примере. Представим, что вы пишете платформу, которая продаёт редкие книги из маленьких издательств по всему миру. Вам нужно переводить деньги вашим поставщикам-издательствам, чтобы они выслали книгу клиенту, и брать себе комиссию 10$ c каждой продажи. Вы не хотите париться с ежемесячными отчётами и выплатами, вы хотите просто переводить деньги каждый раз, когда платит клиент. Stripe это позволяет.



Как и прежде, обязательное условие для настройки автоматических переводов — это нахождение поставщика в одной из стран, поддерживаемых Stripe.



У Stripe есть замечательная штука Managed Acсounts. С помощью этой опции мы как бы создаем Stripe-аккаунт для нашего поставщика, но берём на себя все заботы по управлению аккаунтом, так что самому издательству не нужно будет регистрироваться в Stripe.



Сначала получим информацию о банковском счёте вашего издательства с помощью уже знакомого нам скрипта Stripe.js. Как и в случае списания денег с карты клиента, для операций над банковским счётом нам тоже нужен Stripe token.



Stripe.bankAccount.createToken({
country: $('.country').val(), // 2-хсимвольный код страны (US)
currency: $('.currency').val(), // 3-хсимвольный код валюты (USD)
routing_number: $('.routing-number').val(), // идентификационый номер банка
account_number: $('.account-number').val(), // номер банковского счёта
account_holder_name: $('.name').val(), // имя владельца бизнеса (в нашем примере — издательства)
account_holder_type: $('.account_holder_type').val() // тип аккаунта — идивидуальный предприниматель или компания (individual, company)
}, stripeResponseHandler);


Это тоже описано в документации.



Ремарка. Имейте в виду, что для каждой страны банковские данные (routing_number, account_number ) заполняются по-разному. Например, для европейских стран нужно получать IBAN-номер. Он кладётся в поле account_number, а routing_number не отпраляется вообще. Также для некоторых стран внутренние номера счетов склеиваются в одну строку и записываются в поля. Например, чтобы получить корректный идентификационный номер банка routing_number для Канады, надо склеить transit number и institution number (transit number + institution number). Если transit number: 02345, а institution number: 987, то routing_number будет ‘02345987’. Account number варьируется в зависимости от банка. А для Германии нужен будет только IBAN номер, он заполняется в поле routing_number. Например, IBAN: DE89370400440532013000 (22 символа). Как заполнять эти поля для остальных стран, можно посмотреть тут.



Итак, теперь у нас есть token банковского счёта, куда мы можем выводить деньги поставщикам. Давайте создадим Managed Account. Пусть наше издательство находится в Америке, является компанией, а не ИП, и мы платим ему в американских долларах.



\Stripe\Stripe::setApiKey("your_secret_key");
$account = Account::create([
"country" => 'US',
"managed" => true,
]);
if (isset($account->id)) {
try {
$account->external_accounts->create(
["external_account" => $token] // наш token банковского счета
);
} catch (InvalidRequest $error) {
// произошла ошибка создания
}
}


Казалось бы, теперь у нас есть Managed Account, и можно переводить деньги, но нет: аккаунт нужно верифицировать. Для этого нужно предоставить Stripe определённую юридическую информацию о компании. Какая именно информация нужна и в каких странах, описано здесь.



Итак, для издательства в Америке нам нужно предоставить:




































































legal_entity.address.city Город, в котором расположена компания
legal_entity.address.line1 Адрес компании
legal_entity.address.postal_code Почтовый индекс
legal_entity.address.state Штат
legal_entity.business_name Название компании
legal_entity.business_tax_id Налоговый идентификационный номер
legal_entity.dob.day День рождения владельца компании
legal_entity.dob.month Месяц рождения владельца компании
legal_entity.dob.year Год рождения владельца компании
legal_entity.first_name Имя владельца компании
legal_entity.last_name Фамилия владельца компании
legal_entity.ssn_last_4 Четыре последние цифры номера социального страхования владельца компании
legal_entity.type individual/company
tos_acceptance.date Дата принятия условий использования Stripe
tos_acceptance.ip IP-адрес, с которого происходило принятие условий использования Stripe


Условия использования Stripe здесь. Человек, от чьего имени будет создаваться Managed Account, должен их принять.



Также Stripe может потребовать дополнительную информацию. Для Америки это:
















legal_entity.personal_id_number Личный идентификационный номер
legal_entity.verification.document Скан документа, подтверждающего личность


Собираем необходимую информацию и редактируем аккаунт.



\Stripe\Stripe::setApiKey("your_secret_key");
$account = Account::retrieve($accountId);
$account->legal_entity->address->city = 'New-York';
$account->legal_entity->address->state = 'New-York';
$account->legal_entity->address->postal_code = '00501';
$account->legal_entity->address->line1 = 'Some address';
$account->legal_entity->business_name = 'US TEST';
$account->legal_entity->business_tax_id = '00000001';
$account->legal_entity->dob->day = 1;
$account->legal_entity->dob->month = 1;
$account->legal_entity->dob->year = 1980;
$account->legal_entity->first_name = 'Bob';
$account->legal_entity->last_name = 'Smith';
$account->legal_entity->type = 'company';
$account->legal_entity->ssn_last_4 = '0000';
$account->tos_acceptance->date = 1466074123; // timestamp
$account->tos_acceptance->ip = 123.123.123.123;
try {
$account->save();
} catch (InvalidRequest $error) {
// ошибка во время сохранения
}


Теперь команда Stripe всё проверит, и в админке мы увидим статус Verified.

https://dashboard.stripe.com/test/applications/users/overview



![image]()



Но этого нам не будет достаточно. Также команда Stripe может указать ошибки в данных или потребовать дополнительной информации, например personal_id_number.



image



Когда команда проверит данные, аккаунт будет обновлён. На это событие можно настроить webhook.



image



Необходимые поля будут описаны в объекте аккаунта:



$account->verification->fields_needed


Также Stripe может выставить дедлайн для предоставления данных. Если дата есть, она будет в свойстве $account->verification->due_by.



Для тестирования верификации Stripe предоставляет хорошую тестовую среду. С помощью переводов с определённых тестовых карт мы можем симулировать разные сценарии поведения верификации аккуантов. Примеры таких сценариев:




  • данные не заполнены, и мы вообще не можем совершать переводы;

  • сработал лимит на размер платежа. Это происходит, если Stripe считает, что перевод слишком большой, и предоставленной информации ему недостаточно. В этом случае он отключает Managed Account;

  • отключение аккаунта с требованием ввести данные к определенной дате;

  • загрузка скана документа, подтверждающего личность владельца аккаунта.

  • принятие и отклонение этого скана.



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



Обработать все ситуации придётся в любом случае. И по моему опыту, лучше сразу предоставить Stripe максимум информации, чтобы избежать сюрпризов с отключением аккаунта.



Когда все окей, и Stripe верифицировал ваш Managed Account, нужно включить переводы (transfers) с помощью API или отключить автоматические — это одно и то же.

https://dashboard.stripe.com/account/transfers



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



Обработать все ситуации придётся в любом случае. И по моему опыту, лучше сразу предоставить Stripe максимум информации, чтобы избежать сюрпризов с отключением аккаунта.



Когда все окей, и Stripe верифицировал ваш Managed Account, нужно включить переводы (transfers) с помощью API или отключить автоматические — это одно и то же.

https://dashboard.stripe.com/account/transfers



image



Итак, у нас есть верифициронный аккаунт, переводы включены, и теперь мы можем делать переводы денег напрямую поставщику.



Предположим, у нас есть книга. Поставщик хочет за неё 50$, мы хотим 10$ долларов комиссии себе, плюс нам надо заложить в цену комиссию Stripe на перевод. Сейчас Stripe берёт за каждый перевод 2,9% + 30c. Мы решили, что оплатим комиссию из своей части. Тогда пользователю надо заплатить за книгу 60$. Из своей части мы отдадим 2,04$ комиссии Stripe.



Получаем token с помощью Stripe.js и проводим платёж со стороны сервера.



$charge = Charge::create([
"amount" => 6000, // в центах
"currency" => 'USD',
"source" => $token,
"application_fee" => 1000,
"destination" => $managedAccountId
]);


Свойство application_fee позволяет указать, какую сумму от перевода оставить на нашем счету. Комиссия Stripe будет списываться в любом случае только с нашего счёта, даже если мы сделаем полный перевод поставщику.



На банковский счёт поставщика деньги сразу не придут, они выводятся раз в семь дней. Т.е. мы переводим деньги на Stripe-аккаунт нашего поставщика, и по истечении семи дней они переводятся аккаунту на привязанный банковский счёт.



Дополнительные фичи



Кроме того, Stripe позволяет сохранять клиентов, добавлять произвольные метаданные при создании платежа, чтобы было проще ориентироваться в проведённых платежах, задавать description при платеже для его более информативного описания, и многое другое. Обо всём этом можно посмотреть в документации к API платежей.



Желаю вам удачи в интеграции Stripe! Я буду рада вашим комментариям, вопросам и уточнениям, которые помогут дополнить статью.



Полезные ссылки:



Страны, которые поддерживают Stripe

Custom HTML form для получения token

Managed Acсounts

Получение token для банковского аккаунта

Необходимая банковская информация по странам

Необходимая юридическая информация для Managed Accounts по странам

Условия использования Stripe

Тестирование верификации аккуанта

Webhooks

Stripe Pricing

Stripe API Reference


Original source: habrahabr.ru.

https://habrahabr.ru/post/306338/?utm_source=habrahabr&utm_medium=rss&utm_campaign=best

Метки:   Комментарии (0)КомментироватьВ цитатник или сообщество
rss_rss_hh_new

[Перевод] Интервью с мамой, банковским программистом на COBOL'е

Среда, 20 Июля 2016 г. 16:09 (ссылка)



Фото из Гугла, это не мама автора



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



Объясню немного



Мир банковского программного обеспечения — это другая вселенная. Она сильно отличается от той, к которой привыкло большинство из нас. Я публикую этот пост на HN и на Reddit. Публикую интервью не в виде вопросов-ответов, а в виде рассказа. Я добавил некоторые вопросы и ответы в нижнюю часть поста.



1991



Год, когда она начала внутреннее обучение в банке Nordea, который тогда назывался Nordbanken (Северный банк). В 2001 году его переименовали в Nordea. Во время обучения она должна была проходить различные тесты, в первую очередь тест IQ, чтобы показать, что она обладает интеллектом, достаточным для работы в этой области. Тест на психологическую устойчивость — что у неё достаточно нервов для этой специфической работы и тест на многозадачность, который она завалила с оценкой 22/100. Остальные тесты она прошла успешно и заняла одну из 16 доступных позиций.



Должность звучала «как программист мэйнфреймов IBM на языке COBOL», и до сих пор, уже 25 лет, моя мама работает на этой должности в том же банке.



Эта позиция в банке самая важная, по крайней мере, с технической точки зрения. Если, скажем, мама и члены её команды одновременно бросят работу, банк разорится в лучшем случае в течение нескольких недель. Её коллектив работает посменно с круглосуточной доступностью. Помню, когда я был младше, она брала такси и ехала на работу посредине ночи, в воскресенье, чтобы исправить взаимную блокировку.





Мой брат (ему 1 год, он слева), моя мама и я (справа)



COBOL...



… это не такой крутой язык программирования как функциональный Haskell или Golang для параллельных вычислений. COBOL — это императивный, процедурный язык, а с 2002 года — объектно-ориентированный. В самом языке ничего плохого нет, проблема в том, что его почти никто не знает, как минимум в контексте программирования мэйнфреймов. Моя мать — вторая из самых молодых членов команды, а она родилась в 1964 году. У самого молодого из персонала разница с ней в два года. Это глобальная проблема, поскольку почти все крупнейшие банки в мире работают с мэйнфреймами IBM и COBOL у них — основной язык программирования. У банков помельче ситуация лучше, они обычно работают, например, на Java, без мэйнфреймов.



Мама раньше спрашивала меня, не хочу ли я изучить этот язык, но я тогда уже работал с более продвинутыми технологиями вроде Postgres, Redis, Node, Crystal, PHP и всегда отвечал «Да ни за что!». Мне до сих пор интересно то, что она делает, но такие типы систем вызывают, кажется, самое плохое ощущение корпоративщины, которое только можно представить и которого мне хотелось бы избежать.



Правда, я могу только представить жирную зарплату 20-летнего программиста старого мэйнфрейма, потому что возраст в этом случае бесценен.



Базы данных



Их основная база данных называется IMS. Это иерархическая база данных, созданная IBM для программы Apollo. Между собой они называют её DL/1, Язык Базы данных 1 (Database Language One). Они пытаются мигрировать на DB2, реляционную базу данных, которая понимает нормальный SQL. Но, учитывая огромный объем данных, которые хранит банк Nordea, такая задача займёт несколько лет. Нужно не просто переместить данные из IMS в DB2, в дополнение надо обновить модули для загрузки и сохранения данных из DB2 вместо IMS, а модулей тысячи, многие из них были разработаны программистами, которые либо умерли, либо вышли на пенсию.



Каждая транзакция хранится в DB2. Они избегают записей в IMS насколько это возможно, и только считывают из неё данные, пока их новая купленная система не интегрируется полностью, и они не смогут хранить данные там.



IMS — чрезвычайно старая и очень медленная (для некоторых задач).

Поиск данных может занять несколько часов. Ха, а мы тут спорим о том, что у MySQL скорость выполнения запросов на две миллисекунды выше, чем у Postgres. Немного иронично.



Они также используют плоскую файловую структуру для целого ряда задач, которые сами по себе делятся на несколько подвидов, поддерживаемых IMS. Один из примеров — GSAM, из-за которого маме не раз приходилось мчаться на работу на такси. И всё из-за модулей, работающих с одним и тем же GSAM-файлом одновременно, создавая взаимные блокировки.



Давайте поговорим о размере их баз данных. DB2 хранит данные только о транзакциях, и транзакции отличаются по размеру, в зависимости от типа счетов, между которыми протекает транзакция. Частные счета, как мой личный банковский счет, на порядок проще, чем корпоративные счета. Каждая транзакция весит где-то от 500б до 2Кб, в среднем примерно 1Кб.



Сейчас их база данных DB2 хранит 11 миллиардов транзакций, а закон требует хранить каждую транзакцию в течение 10 лет, а по факту — 11 лет. На данный момент транзакциям только 7 лет, а их количество, предположительно, растёт на 5-8% каждый год, и так, пока они не дождутся 11 лет, когда можно будет уничтожить записи старше 11 лет.



Получается, сегодня DB2 хранит около 10Тб данных, и это только транзакции. Через четыре года это превратится приблизительно в 13-14Тб.



Большая часть оставшейся информации хранится в IMS. Эти данные сильно отличаются по объёму, так что трудно оценить размер, но я предполагаю, что их намного больше, чем в DB2.



Ещё они хранят некоторые данные на лентах, а их программы указывают машине загрузить или сохранить данные с конкретной ленты. Это довольно круто!



IDE



У всех есть что-то вроде IDE или текстового редактора, правда? У них, вот, есть. Их IDE называется ISPF и напоминает операционную систему. ISPF можно расширять, и часть, которую можно назвать IDE — это расширение ISPF под названием Endevor.



ISPF напрямую связана с мэйнфреймом, и у них нет такого понятия, как локальная среда разработки.





Интерфейс ISPF, найденный в интернете



Пакетная обработка



Примерно 80% их систем — пакетная обработка. Это задачи, которые запускаются в определенное время или интервал времени, выполняя какую-нибудь обработку данных или отправляя данные в другие банки, агентства или ещё куда-то. Например, когда я покупаю банку кока-колы, деньги снимаются с моего счета, но фактически деньги никуда не поступают, пока одно из их пакетных заданий не проведёт эту операцию. Эти задания, как правило, выполняются в ночные часы, поэтому обычно требуется день, чтобы операции между банками завершились. Транзакции внутри банка обычно мгновенные, поскольку выполняются сразу.



Пакетные задания работают с гигабайтами, иногда терабайтами данных, и в некоторых случаях могут занять несколько часов. Хотелось бы посмотреть, как мэйнфреймы IBM внезапно переходят на полную мощность в их датацентрах в ту секунду, когда на часах 00:00. Это было бы офигенно!



Проблемы, с которыми сталкиваются банки



У банков, которые работают на мэйнфреймах, множество проблем, которые они должны решать, но времени на это, к сожалению, не хватает.



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



Есть программы, которым десятки лет: никто не понимает, как они работают, а человека, который их писал, уже давно нет.



Многие банки хотят приобрести новые крутые системы, чтобы заменить старые, а все их программисты в один голос заявляют: «это не сработает, нашего монстра нельзя ничем заменить».



Отчасти, причина огромного размера их систем в том, что они изначально допустили ошибку и начали подстраивать свою систему под другие системы. Хороший пример: мы создаём RESTful-сервисы, в которых программы, которым нужно получить от нас данные, подстраивают свои системы под нашу. В некоторых банках всё не так, и они посылают данные другим системам, например, налоговым службам, а налоговые службы могут в любой момент обновить свои системы, которые, в свою очередь, сломают те, что банки используют для отправки данных.



Банковские системы также чрезвычайно продвинутые. Личный банковский счет сильно отличается от корпоративного банковского счета. В дополнение существует как минимум 50 различных видов банковских счетов для каждого из типов. А в случае с Nordea, есть ещё и шведские правительственные счета, которые отличаются от личных и корпоративных. Думаю, что существуют финские правительственные счета и, возможно, часть датских, которые тоже чем-то отличаются.



В заключение



Будет очень интересно послушать, что банк Nordea и другие банки собираются делать в ближайшие годы, и какие новые технологии они собираются реализовывать.



Q&A



Почему ты решила программировать на мэйнфрейме IBM на COBOL?

— Я всегда хотела «работать с компьютерами», но не искала эту конкретную работу. Я увидела объявление в газете, подала резюме и получила работу. Правда, на тот момент у меня уже было немного опыта в сфере компьютерных систем.



Что тебя больше всего шокировало?

— Мой коллега однажды забыл добавить точку в конце инструкции для программного модуля в самой важной части нашей системы, которую мы называем «кассой». Она отвечает за обработку всех денег. В результате на 16 часов остановилась работа всего банка, исключительно из-за модуля, который продолжал выполняться, хотя должен был остановиться после той инструкции. Это буквально повесило нашу систему, устроив, можно сказать, DoS-атаку самой себя.



Как ты думаешь, какое будущее ждёт банки, работающие в той же инфраструктуре, как Nordea?

— Большинство банков признало, что нужно заменить старые мэйнфреймы на более современные. Nordea купил новую систему, которой обещал заменить текущую в течение 4-х лет, но банк обслуживает несколько стран, и в реальности 4 года уйдёт только на одну страну, так что в общей сложности — 16 лет.



Банки и финансовые системы, которые не поняли этого, окажутся в очень сложной ситуации. Хотя мне до сих пор кажется, что мы будем использовать инфраструктуру IBM.



С какими проблемами тебе пришлось столкнуться как женщине-программисту, которая начала работать в 90-х?

— Совершенно никаких проблем не было. В моём коллективе есть несколько женщин, но мужчин больше. Меня это не особо беспокоит.



Ты работаешь над одним модулем и, возможно, над одной кодовой базой больше 20 лет. Это вообще надоедает?

— Да, определенно, как и в других сферах деятельности. Но за время работы здесь я создала множество абсолютно новых систем по разным финансовым направлениям, и это всегда было интересно. К сожалению, с этого момента мы уже никогда не создадим ничего нового, только будем поддерживать текущее и ждать новую систему, которую купили для замены.



Насколько страшно писать код для банка?

— Очень страшно, особенно, когда мы делаем изменения на главном сервере по воскресеньям. Когда мы что-то там меняем, крупные блоки системы нужно переводить в оффлайн. Один из этих блоков — вся IMS. В этот промежуток времени может случиться что угодно, но у нас очень надежная тестовая система, так что, как правило, всё проходит без проблем.



Ты когда-нибудь допускала серьёзные ошибки в работе?

— Определенно, одну довольно серьёзную ошибку я сделала еще в 1997 году, когда мой младший сын (это я, автор) только пошёл в детский сад и кончился мой декретный отпуск. У нас есть накопительная пенсионная система. Этот тип банковских счетов в то время был не закрытым, а по закону нельзя было снимать деньги с этого счета пока не исполнится 55 лет. Поскольку счета не были закрытыми, при наличии номера банковского счета деньги можно было снимать. Поэтому решение было простым — не давать клиентам номера их банковских счетов.



Я ухитрилась облажаться и изменила модуль, который стал добавлять номер счета в письмо, отсылаемое клиенту по почте. Клиенты начали снимать деньги (с которых еще не списали налоги!) со своих пенсионных счетов раньше, чем им полагалось по закону.



Это повлекло за собой огромное внутреннее расследование. Вмешалось шведское правительство, нас атаковали финансовая инспекция и СМИ. Это всё — я.



Какая у тебя рабочая атмосфера?

— Мы недавно переехали в более «модное» место. Раньше у нас были личные столы, а теперь «выбирай любое доступное место» — открытое пространство. Мне это совсем не нравится.



(Перевод Наталии Басс)


Original source: habrahabr.ru.

https://habrahabr.ru/post/306046/?utm_source=habrahabr&utm_medium=rss&utm_campaign=best

Метки:   Комментарии (0)КомментироватьВ цитатник или сообщество
rss_rss_hh_new

Хаордическая организация Visa (Часть 4)

Вторник, 19 Июля 2016 г. 10:07 (ссылка)

image



В то время я так и не смог сделать членами-собственниками NBI предприятия розничной торговли и сферы услуг, а также держателей карт. Любой шаг в этом направлении вызывал бурю протеста со стороны банков. Вероятно, если бы я проявил твердость, мне удалось бы склонить их на свою сторону, но теперь уже поздно говорить об этом.


Ди Хок



Уважаемые читатели, мы продолжаем цикл статей о истории зарождения самой крупной финансовой организации в мире Visa. Как и в предыдущей части – цитаты из книги Ди Хока “One from Many: VISA and the Rise of Chaordic Organization” выделены курсивом. Важные цитаты выделены жирным шрифтом. Эти моменты мы и обсудим в 4-ой заключительной части.



Пока NBI разбиралась с двойным членством и занималась вопросами, связанными с системами коммуникаций, маркетингом и защитой пластиковых карт, то есть важнейшими проблемами, не решив которые, нельзя было запустить систему BankAmericard на всей территории США, Bank of America Service Corporation продолжала лицензировать банки по всему миру. Каждая лицензия имела свою специфику, требовала особого подхода к маркетингу, компьютерным и операционным системам. К тому же все карты назывались по-разному. Если в США кредитная карта с сине-бело-золотым логотипом называлась BankAmericard, то в Японии это была уже Sumitomo Card, в Великобритании — Barclaycard, в Канаде — Chargex, в Мексике — Вancomer и т. д. Из-за языковых, валютных, культурных и юридических различий в других странах было гораздо больше неурядиц, чем в США.







Следуя примеру NBI, зарубежные лицензиаты создали свой собственный комитет и даже попытались сколотить международную организацию. Однако их попытка провалилась. В конце 1972 года международный комитет лицензиатов обратился к руководству NBI с предложением создать всемирную организацию. Мы были не против, но возникала сложная проблема. Если NBI возьмется за разработку этого проекта, значит, мы будем навязывать свое мировосприятие и культуру другим странам, и нас просто возненавидят. Да и как сочетать обязательства перед членами NBI с обязательствами перед банками, находящимися за пределами США? Как отвлечься от собственных трудностей? В то же время наш успех был напрямую связан с успехом программы за рубежом. Разве можно осуществить мечту о самой совершенной глобальной системе обмена стоимостью без эффективной всемирной организации?



Эта задача была сложнее, чем создание NBI. Всемирная организация должна была преодолеть языковые, культурные, валютные, технологические, юридические и политические различия. Необходимо было задействовать тысячи банков по всему миру, а также национальные консорциумы во Франции, Канаде, странах Скандинавии и США. Следовало ожидать, что десятки тысяч различных финансовых институтов более чем 200 стран и регионов тоже захотят войти в такую организацию. На это уйдет несколько лет — без всякой гарантии успеха. И все же, если бы такая организация появилась, это стало бы огромным плюсом и для рынка США, и для рынка других стран. При этом накопленный в результате опыт и укрепившийся авторитет NBI, несомненно, оказали бы нам бесценную услугу. Для NBI настала пора стать «гражданином мира».



Я обратился к совету управляющих NBI с той же просьбой, с которой обращался некогда к Максвеллу Карлсону. Я объяснил, что руководство NBI сможет двигаться в нужном направлении, только если будет свободно от обязательств перед этой организацией.



Вместе с тем нам было необходимо развивать NBI, чтобы сохранить ее авторитет и получать прибыль. Многие из управляющих, в том числе и наш председатель Сэм Стюарт, в свое время работали в организационном комитете и видели, что National Bank of Commerce предоставил мне полную свободу действий. Они помнили, как рьяно я защищал тогда собственную независимость и право комитетов действовать открыто, в общих интересах.



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



Два года я был одновременно президентом и главным исполнительным директором NBI, а также независимым агентом, действующим от лица международных лицензиатов. Это было удивительное время: я встретил много друзей, пережил предательство. Сюрпризов было хоть отбавляй.



Два года мы боролись и сняли огромное количество противоречий. Руководство каждого банка-лицензиата приняло решение, касающееся условий участия в новой организации. Остались разногласия всего по трем пунктам. Комитет решил провести последнее совещание. Если бы банки не пересмотрели свою позицию, от проекта пришлось бы отказаться. В ходе предварительных переговоров стало очевидно, что противоречия только обостряются. Мы, организаторы, отчаянно искали выход из положения. Казалось, ни один из предложенных нами компромиссов не может быть принят.




Ситуация перестала быть прозрачной, кто-то из банков-лицензиатов саботировал создание новой организации. Ди Хок выступил с речью, в которой он снял с себя обязательство руководство. Но было решено до ежегодного собрания банков-лицензиатов ничего не предпринимать. Собрание должно было проходить в Испании через несколько недель.



Я привык с легкостью справляться с трудностями, поэтому перестал искать компромиссы и подумал о том, чего мы добились за эти два года. Как умудрилась такая большая группа самых разных людей преодолеть столько преград? Найти ответ на этот вопрос было нелегко, но он оказался очень простым. Всякий раз во время кризиса все участники проекта были нацелены на успех и готовы на уступки. Их волновали не победа и не поражение — они были охвачены чувством единства, озарены общей целью.



Ко мне присоединилось еще несколько человек, и через час у нас родилась идея, которую можно было выразить так: воля к победе и готовность к компромиссу. Если бы мы написали эту фразу, например, только по-английски, это могло бы обидеть носителей других языков. Значит, она должна была звучать на мертвом языке. Мы обратились к лингвистам и получили перевод на латинский: stadium ad prosperandum – voluntas in conveniendum. Я до сих пор не знаю, насколько точен этот перевод, но это и не имеет значения, потому что важна суть.



Мы попросили хорошего местного ювелира отлить для нас клише, чтобы потом изготовить запонки. На одной запонке должно было быть изображено земное полушарие с контурами континентов, обрамленных надписью stadium ad prosperandum, а на второй — другое полушарие, тоже с контурами континентов, на этот раз обрамленных надписью voluntas in conveniendum. Такие запонки мы хотели подарить каждому члену организационного комитета. Но это был наш секрет.



В Сан-Франциско выдался тогда замечательный теплый день. На совещании люди сталкивались лбами, осыпая друг друга взаимными упреками. Четыре крупных канадских банка, выпускающих кредитные карты Chargex, повели себя очень агрессивно. Они заявили, что если другие банки не примут их требований, они выйдут из проекта. В полной растерянности я встал перед собравшимися и произнес:



— Что ж, похоже, Канада не желает принять точку зрения остальных. Что скажут другие? Будем ли мы продолжать без наших канадских друзей?



Все закивали в ответ.



— Хорошо. Итак, представители Chargex выпадают из процесса. Считаете ли вы, что они могут остаться на совещании в роли наблюдателей без права участия в дальнейших дискуссиях?



И снова все согласно кивают. Канадцы удивлены, но не уходят.



Однако напряжение не спадало. По остальным вопросам также обнаружились серьезные разногласия. Дело близилось к вечеру, тучи сгущались. Я предложил прервать совещание и, если уж мы отказываемся от проекта, закрепить свое решение документально завтра, а сейчас совершить великолепную прогулку по заливу. В Fisherman’s Wharf мы арендовали прогулочную яхту. Мы пригласили собравшихся отправиться на ней в сторону Сосалито, где нас ждал ужин во французском ресторанчике Le Vivoire — совсем недалеко от того места, где четыре года назад Сэм, Джек, Фред и я, сидя на открытой террасе гостиничного ресторана, задались волшебным вопросом: «Если допустить, что невероятное возможно и что нет никаких преград, как мы представляем себе в идеале глобальную систему обмена стоимостью?»



Матушка-природа была к нам благосклонна. Мы отчалили от Fisherman’s Wharf. За мостом Золотые Ворота садилось солнце, окрашивая облака в розовые и пурпурные тона. А мост и впрямь, подтверждая свое название, стал ослепительно золотым, что было особенно заметно на фоне пастельных красок города. По синей воде до самого горизонта тянулась золотая дорожка. Вечер был теплым, все сняли пиджаки, яхта медленно шла мимо зданий острова Алькатрас, похожих на крепости (там прежде располагалась федеральная тюрьма). Мы плыли дальше, мимо зеленого острова Энджел-Айденд, пока наконец не причалили между плавучих домиков в Сосалито.

Мы прошлись пешком до ресторанчика, где распили несколько бутылок прекрасного вина и отлично поужинали. Люди оттаяли. Я попросил минуту внимания и сказал пару слов о трудностях, через которые мы прошли, о проделанной работе. Перед каждым из собравшихся положили по футляру с запонками. Я объяснил:



— Наша мечта не осуществилась, но давайте не будем считать это провалом. С самого начала было ясно, что невозможно создать всемирную организацию. Однако два года мы трудились не покладая рук. Мы не знали, чем закончится сегодняшнее собрание, но в любом случае решили сделать вам подарок. Откройте футляры.



Все открыли изящные коробочки. А я продолжал: — Мы решили подарить вам сувенир на память о сегодняшнем дне. На одной запонке — полушарие с латинской надписью stadium ad prosperandum, что означает «воля к победе». На другой — второе полушарие, окаймленное второй частью изречения: Voluntas in conveniendum, или «готовность к компромиссу». Сегодня, после напряженного двухлетнего труда, мы собрались, чтобы похоронить наш проект. Мы не смогли прийти к соглашению. У нас, у организаторов, есть к вам одна просьба. Пожалуйста, наденьте завтра эти запонки. Вы разъедетесь по домам и заберете подарок как напоминание о том, что мы не смогли объединить мир, потому что у нас не хватило воли к победе и готовности к компромиссу. Если вдруг случится чудо и завтра все наши разногласия растают, как туман, эти запонки будут напоминать нам до самого смертного часа, что мы смогли объединить мир, потому что у нас хватило воли к победе и готовности к компромиссу.



В полной тишине все рассматривали запонки. А потом один канадец, мой приятель, очень веселый человек, встал и, улыбаясь во весь рот, воскликнул:



— Ах ты, чертяка!



Под дружный хохот мы продолжали ужинать.



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



— Кто-нибудь хочет выступить по поводу выхода из проекта? Канадцы отказались от заявлений, сделанных накануне, и выразили желание войти в новую организацию. Люди слушали и тихо дотрагивались до своих запонок.



Через час мы договорились по всем вопросам.



Спустя несколько месяцев была создана международная организация Ibanco, именуемая сегодня Visa International. Ее девизом стала фраза «Воля к победе, готовность к компромиссу». Насколько я знаю, и по сей день каждому новому директору банка вручаются золотые запонки и грамота, повествующая об этой истории. Для меня это — высшая награда.



В 1973 году стало очевидно, что использование разных названий карт препятствует развитию системы. Тогда все карты объединял только сине-бело-золотой логотип. В каждой стране кредитка называлась по-своему, а в некоторых странах было даже несколько названий. В США — BankAmericard, в Канаде — Chargex, иногда карту называли по имени банка-эмитента, как, например, Sumitomo в Японии или Barclays в Великобритании. И каждый раз, когда карте давалось название одного банка, другие банки отказывались подключаться к проекту. Торговые предприятия все время путались, и это серьезно мешало работе. Таким образом, сильно ограничивались возможности международного маркетинга: карты теряли привлекательность.



У кассовых аппаратов были вывешены названия карт, которые принимались к оплате: «Здесь принимают Barclaycard», «Принимаем карты Sumitomo». Торговым предприятиям не нравилось, что в их помещениях размещается реклама банков. Держатели карт думали, что принимаются к оплате только карты банка, указанного в объявлении, и это не устраивало другие банки. Система разрасталась, а проблема названия все осложняла. В США название BankAmericard тоже ограничивало другие банки — получалось, что они продвигают Bank of America.



Сберегательным и кредитным компаниям, тоже получившим законное право заниматься бизнесом кредитных карт, не очень нравилось, что карту называют банковской. В других странах были недовольны словом American. Само понятие «карта» не годилось для таких новых продуктов, как дорожные чеки и денежные почтовые переводы. С каждым годом решать эти проблемы становилось все труднее. Когда в 1974 году была создана международная корпорация Ibаnсо, появился механизм, позволявший выйти из нелегкого положения.



После создания Ibаnсо произошло еще одно важное событие. Международный комитет, стоявший у истоков новой корпорации, уже не хотел сдавать свои полномочия. Но разве у двух организаций могло быть общее руководство? Поначалу казалось, что нет. Существовало два самостоятельных юридических лица: National BankAmericard, куда входили банки США, и Ibаnсо, куда входили несколько национальных консорциумов вроде NBI, Chargex, Carte Bleue и еще сотня отдельных банков по всему миру.



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



Мы придумали весьма оригинальный выход. Ibanco и NBA подпишут договор о совместном управлении — один и тот же штат сотрудников будет обслуживать обе организации. Советы директоров обеих организаций смогут самостоятельно снимать менеджеров с должности, а вот для назначения новых потребуется согласие и совета директоров NBI, и совета директоров Ibanco. Таким образом, менеджеров будут назначать и поощрять в двустороннем порядке, а снимать или наказывать — в одностороннем. В случае конфликта интересов менеджеры должны будут заявить об этом, определив для себя, какую из сторон они представляют. Другую сторону будет представлять ее совет директоров.



Вскоре после образования Ibanco мы попросили совет директоров разрешить нам разработать единое международное название карты. В условиях новой организации это было труднейшей задачей. Нужно было заменить все карты, находящиеся на руках у клиентов. Нужно было переклеить все наклейки на кассовых аппаратах в торговых точках. Все электронные вывески должны были демонтировать и заменить новыми, а ведь только в Японии их было около 200 тыс. Нужно было выпустить бланки и канцелярские принадлежности с новыми логотипами. То же касалось и рекламы. Изменения должны были затронуть десятки стран с различными языками, культурами и законодательством. Совместное управление неспособно было решить такое количество сложнейших задач.



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



Ситуация усложнялась. Хотя у Ibanco была эксклюзивная лицензия Bank of America, сине-бело-золотой логотип и название карты полностью принадлежали банку. К счастью, ко времени создания Ibanco была достигнута договоренность о подписании соглашения, которое предусматривало компенсацию банку в случае передачи прав владения международной составляющей системы. По условиям договора, если новое название карты окажется приемлемым для 80% участников системы, право на дизайн карт должно будет перейти к Ibanco без всякой дополнительной компенсации. Это означало, что все банки должны были отказаться от названия BankAmericard и оно становилось исключительной собственностью Вапk of Аmeriса.



Мы снова обратились к целям и принципам проекта. С целями все было просто: нужно было придумать название всемирной организации и ее продукта, сохранив сине-бело-золотой логотип. Название и логотип будут находиться в совместной собственности. Чтобы придумать название карты, нужно было утвердить основные требования к нему. И мы начали думать.



Новое название должно было быть коротким, выразительным, легко узнаваемым и легко произносимым. Оно должно было звучать так, чтобы ни на каком языке не вызывать нездоровых ассоциаций. Оно должно было обеспечивать защиту мировой торговой марки, под которой будут осуществляться обмен стоимостью и другие операции. В нем не должно было содержаться намеков на географическое положение, название организации или вид услуги, например, Ameri, Euro, bank, charge, credit и card. Название карты должно было отражать мобильность, выгодность кредитки и возможность пользоваться ею во время путешествий. В итоге мы набросали 15 требований. Но при таком раскладе можно было выбирать название бесконечно. И мы решили положиться на собственную интуицию и талант.



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



— Думайте в одиночку и все вместе, — сказали мы. — Главное, чтобы вам было интересно. Мы создадим специальную группу, куда вы сможете обращаться за помощью и вносить предложения. И никаких специалистов со стороны! Мы сами с усами. Тот, кто придумает новое название карты, получит банкноту в $50. Если название карты придумают несколько человек, каждый получит по такой банкноте. Плата чисто символическая. Но если назначить большой приз, мы потонем в вариантах. А купюру в $50 победитель может повесить у себя дома в рамочке!



Сколько же талантов мы разбудили! Люди очень быстро организовали работу. Технари даже написали компьютерные программы. К делу подключились друзья и члены семей. Все штудировали словари, изыскивая слова с подходящим корнем. Чем бы ни занимались сотрудники, они все время думали о названии карты. Приступы бурной радости сменялись разочарованием, горе-победители отбивались от добродушных насмешек. Маркетологи считали, что именно они, а не какие-то там экспедиторы, должны быть первыми. Экспедиторы, в свою очередь, старались доказать, что они тоже талантливы, — и им это не раз удавалось.



Предложения систематизировались по определенным признакам. Множество идей, не отвечающих нашим принципам и целям, сразу же отсеивалось. Через несколько месяцев осталось всего несколько названий. Одно из них, Visa, было слишком простым для брэнда: его то снимали с дистанции, то снова вспоминали о нем. Может ли слово «виза», которое всегда означало «разрешение на въезд в другую страну», стать всемирным брэндом финансовой услуги? А почему бы и нет? И все же такое название казалось чересчур распространенным. Кроме того, мы думали, что наверняка кто-то уже назвал так финансовую компанию.



Мы стали изучать мировые брэнды, пытаясь выяснить, не использовалось ли слово «виза» в сфере финансовых услуг. Вскоре мы узнали, что существовал автомобиль марки Visa, гольф-клубы Visa, ткань Visa. Мы знакомились с результатами исследования, затаив дыхание. Еще были авторучки Visa, бытовая техника Visa и многие другие продукты с таким названием. Но никаких следов слова Visa в сфере финансовых услуг, издательской деятельности и т. п. мы не обнаружили, поэтому быстренько зарегистрировали название нашей новой торговой марки во всех возможных инстанциях.



Мы еще не знали, согласятся ли члены Ibanco изменить название карты, но начало было положено: мы зарегистрировали его. «Но кто же получил купюру в $50?»— спросите вы. Об этом рассказывают много историй. Сколько мы ни ломали голову, так и не вспомнили, кто же первым предложил название Visa. Оно словно родилось само по себе, возникло из воздуха в процессе работы. На итоговом совещании кто-то пошутил: «Наверное, оно само к нам пришло. Награда должна достаться всем, то есть, учитывая номинальную стоимость, никому». Посмеявшись, мы решили, что так тому и быть.



Итак, встреча на Гавайях. Именно здесь должно было быть принято окончательное решение. Я тщательно готовился к встрече, чтобы собрать всех за столом переговоров. Вечером накануне совещания мы с Феролой прогуливались вдоль океана, потом присели на скамеечку. К нам присоединилась еще одна пара. Мы грелись на солнышке, обмениваясь впечатлениями о красотах природы, любовались сначала закатом, а потом небом, усеянным звездами.

На следующий день на совещании я узнал своего вчерашнего знакомца — это был директор Barclay’s Bank. Джон Клинтон. Он не поленился приехать на Гавайи с единственной целью — убедить остальных, что мы совершаем ошибку, пытаясь перейти на единое название карт. Были длительные, горячие дискуссии, мнения резко разошлись. Как всегда, мы были верны традиции и закончили совещание к полудню, чтобы люди могли отдохнуть и побеседовать. Джон сказал, что хочет переговорить со мной. Через час мы встретились на пляже.



И вот мы лежим на горячем песке под знойным тропическим солнцем, и Джон проникновенно объясняет мне, что Barclay’s возражает против изменения названия карт. Я внимательно слушаю его, пытаясь почувствовать кожей то, что чувствует он. Если встать на его место, он прав. Оказавшись в его положении, мы вели бы себя точно так же. Не было смысла спорить. Но в то же время я задался вопросом: а пытался ли он взглянуть на ситуацию нашими глазами? Сочетаются ли интересы Barclay’s с интересами остальных?



Я спросил у Джона, есть ли у него время, чтобы выслушать меня? Джон ответил, что да, конечно же есть. Я разровнял ладонью влажный песок и начал набрасывать рисунки самых разных карт и наклеек. Я хотел показать ему, какие проблемы возникают во всем мире из-за того, что карты не похожи друг на друга. Я рисовал и вдруг краем глаза увидел, что меня зовет один из членов NBI. Я махнул ему рукой, чтобы он подождал, потому что не хотел прерывать разговора с Джоном. Джон очень быстро понял, что я пытаюсь ему сказать. Я ползал по песку, спину уже начало припекать. Я мысленно усмехнулся, вспомнив старую родительскую поговорку: своя кожа ближе к телу. Не знаю, не знаю — лично у меня сегодня точно будет облезать кожа. Так мы беседовали около часа, а потом Джон сказал:



— Похоже, мы не до конца поняли суть дела. Мне нужно подумать до утра и посоветоваться с другими сотрудниками. Думаю, мы поддержим проект.



Я поблагодарил Джона и отправился мазать спину кремом от солнечных ожогов.



Меня поймали возле гостиницы и рассказали, что кто-то из сторонников проекта «обложил» Бернара Сью, главу Carte Bleue. Бернар вспылил и заявил, что улетает во Францию первым же рейсом. А ведь мы почти договорились!



— Где Бернар? Он еще не улетел? — спросил я.



Мне указали в сторону океана. Вдали от берега я увидел маленькую фигурку, болтающуюся на волнах.



Сердце у меня упало. Через полтора часа начнется вечернее заседание, на котором я председательствую, а тут такое! Я знал, что в молодые годы Бернар был пловцом олимпийского класса. А я, деревенский парень, плавал как утка только в речке да пруду. Но мне нужно было переговорить с Бернаром. Ну и работенка! Я пошлепал к воде и поплыл. На мое счастье, Бернар уже повернул обратно.



Мы встретились в сотне ярдов от берега — беседа, так сказать, состоялась в океане. Завидую Бернару — он и не думал уставать, а у меня уже через полчаса язык был на плече. Не знаю, что тут сыграло свою роль: то ли Бернару стало меня жалко, то ли океан ввел его в благодушное настроение, но он внимательно меня выслушал. И согласился, что присутствие Carte Bleue очень важно для нас, несмотря на чье-то непреднамеренное хамство.

Удачи и неудачи как бананы: они растут в одной связке. За ужином я оказался рядом с представителем Sumitomo Bank, тихим, скромным человеком. Мы разговорились об искусстве бонсай — в то время я как раз пытался освоить его. Мой собеседник был большим знатоком в этой области. Он рассказал, что в его семье одно карликовое деревце выращивает уже пятое поколение. Это занятие дает его близким ощущение, что жизнь — эстафета, и заставляет почувствовать, что нужно уважать предков и трудиться ради следующих поколений. Этот человек признался мне, что скучает по своему деревцу и беспокоится о нем, потому что его нужно еще немного подрастить и передать молодым. Я поделился убеждением, что человеческая жизнь — не наша личная собственность и общение с другими людьми не должно быть похожим на некие договорные отношения. Жизнь — это скорее священная связь между мертвыми, ныне живущими и еще не рожденными людьми.



Разговор сам собой перешел к Ibаnсо. Мы говорили о том, что Ibаnсо строится на отношениях особого рода и требует определенных жертв с нашей стороны. Мы сравнили Ibаnсо с деревцем бонсай, которое надо растить и передавать следующему поколению. Потрясенные этим совместным открытием, мы представили себе наше «карликовое деревце» NBI и замолчали. Мы и словом не обмолвились о разногласиях, касающихся изменения названия карт. Я знал, что восточные люди легко и красиво входят в особое состояние причастности общему делу. Тогда, разговаривая с японцем, я тоже испытал нечто подобное.



В конце ужина я попросил у своего собеседника разрешения поведать остальным историю его семейного деревца. На вечернем совещании я рассказал, что компания Sumitomo имеет 400-летнюю историю. Когда-то самураи бродили по стране и добывали медь. И только потом они открыли банковское дело и многие другие виды бизнеса Sumitomo. Завершая свой рассказ, я прибавил:



— Прежде чем продолжить завтра наше совещание, мы должны хорошенько подумать: стоит ли подвергать опасности жизнь нашего крошечного деревца? Не пора ли и нам возродить самурайский дух, отвечая за жизнь, которую мы взращиваем?



Мой коллега из Sumitomo сидел в зале и довольно улыбался.



Вот уж действительно: у каждого свой путь к пониманию, свои мотивы, и бесполезно навязывать чуждую точку зрения!



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

Было принято единогласное решение о замене названия Ibanco на Visa International Services Association, сокращенно Visa. Карта BankAmericard была переименована в Visa. Одновременно и тоже единогласно все карты, находящиеся на руках у пользователей во всем мире, было решено переименовать в Visa. Таким образом, название карт сливалось с названием корпорации. Это решение создало многим участникам кучу проблем, и на местах им пришлось объясняться со своим начальством. Не исключено, что кто-то даже рисковал карьерой. Но все равно они сделали этот шаг без оглядки. За два-три месяца мы составили план переходного периода, рассчитанный на четыре года. Предстояла сложная работа. Был задан лишь общий вектор, но каждая организация могла осуществлять переход так, как считала нужным. Никто никому не приказывал, не угрожал санкциями. Никто никому не читал нотаций. Однако были установлены сроки, за какое время каждая организация должна была добиться определенных результатов. Держатели карт и торговые предприятия восприняли кампанию с энтузиазмом и начали сами организовывать свою работу. Через полтора года в обороте уже почти не осталось старых карт, и все наклейки на кассовых аппаратах были заменены. Еще через три года Visa обошла всех своих конкурентов по бизнесу кредитных карт.




Создание Visa – бесспорно впечатляющая работа, объединившая тысячи банков по всему миру в единую систему. Более того, как мы узнали, в каждом регионе решения принимаются локально своими банками.



https://habrahabr.ru/post/305904/

Метки:   Комментарии (0)КомментироватьВ цитатник или сообщество
rss_rss_hh_new

Главные тренды развития рынка платежных систем

Среда, 06 Июля 2016 г. 15:40 (ссылка)

image

Максим Иванченко, Генеральный директор Canopus IT и основатель проекта Advapay.eu о главных трендах развития рынка платежных систем.



Если попытаться сформулировать современные тренды платежного рынка совсем коротко, то можно сказать, что платежи становятся: а) быстрее, б) безопаснее, в) дешевле, г) проще. Например, оплата картой в интернет-магазине стоит достаточно дорого – в среднем, от 1.5% до 3%, если речь идет о покупке какого-то товара. Межбанковский перевод внутри SEPA стоит всего лишь от 15 до 30 евро центов. Стоимость перевода bitcoin реально еще меньше и даже может быть в ряде случаев нулевой.



Вопрос безопасности платежей остается в центре внимания профессионального сообщества… Банки и платежные операторы тратят колоссальные средства на обеспечение безопасности платежной инфраструктуры. Некоторое время назад в ЕС были приняты новые правила и нормы, регулирующие вопросы обеспечение безопасности интернет-платежей. Эти нормы стали обязательными для исполнения всеми участниками рынка начиная с 1-го августа 2015 года.



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



Платить становится проще.



Что это значит? Во-первых, глубокое проникновение в нашу жизнь умных устройств, таких как смартфоны и планшетные ПК коренным образом меняет подход к оплате как в онлайн, так и в офлайн-магазинах. Ваш смартфон легко может быть превращен и в платежный терминал, и в электронный кошелек одновременно, заменив традиционную банковскую карту. При этом такой платеж становится еще и более безопасным, так как Вам не надо вводить номер карты, передавать ее кассиру, и т.д. Во-вторых, происходит сращивание платежных технологий с интеллектуальными системами автоматизации торговли и электронного мерчендайзинга. Например, придя в магазин, вы просто сканируете QR-коды образцов товаров, которые хотите купить при помощи мобильного приложения, при этом автоматически формируется электронный счет на оплату. Вы подтверждаете его одноразовым паролем или PIN-кодом, происходит оплата и Вы получаете у менеджера пакет, в который упакованы все Ваши покупки. Подобные системы уже становятся реальностью.



Электронные витрины, системы дополненной реальности, мобильные торговые терминалы стыкуются с платежными системами. И на этом стыке рождается новый уровень платежного сервиса.



Угрозы и перспективы, прогноз масштаба рынка в мировом измерении.



Если говорить об угрозах, связанных с дальнейшим развитием рынка платежных услуг, то их, на мой взгляд не так много. Естественно, такие угрозы всегда есть, когда речь идет о каких-то достаточно радикальных изменениях в тех или иных сферах человеческой деятельности. Например, как я недавно прочитал в статье в The New York Times, посвященной Fintehc-стартапам, ожидается, что в банковском секторе в ближайшие 10 лет в результате развития технологий, будет потеряно до 30% рабочих мест. Наверное, данный факт можно расценивать как угрозу для тех сотрудников банков, которые не хотят повышать свою квалификацию или менять сферу деятельности. Но в целом для мировой экономики, это скорее благо, чем угроза.



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



Не последнюю роль в этой связи играет и законодательная составляющая, а также – судебная практика. Известно много случаев, когда хакеры получали реальные весьма серьезные сроки в США и Европе. К сожалению, в Российской практике такие случаи пока весьма редки.



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

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

Original source: habrahabr.ru.

https://habrahabr.ru/post/304844/?utm_source=habrahabr&utm_medium=rss&utm_campaign=best

Метки:   Комментарии (0)КомментироватьВ цитатник или сообщество
rss_rss_hh_new

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

Понедельник, 04 Июля 2016 г. 11:38 (ссылка)

А нужен ли PCI DSS?



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



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


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





image



С веб-сайтом все довольно просто: при интеграции достаточно воспользоваться техническим решением, которое перенаправляет плательщика на форму ввода данных карты, расположенной на сайте 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):



activity_main.xml







































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



image



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



image



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



    @Override
protected void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
setContentView(R.layout.activity_main);

findViewById(R.id.btn_amount).setOnClickListener(this);
editAmount = (EditText) findViewById(R.id.edit_amount);
spinnerCcy = (Spinner) findViewById(R.id.spinner_ccy);
editEmail = (EditText) findViewById(R.id.edit_email);
editDescription = (EditText) findViewById(R.id.edit_description);
cardInput = (CardInputView) findViewById(R.id.card_input);
cardInput.setHelpedNeeded(BuildConfig.DEBUG);
findViewById(R.id.btn_pay).setOnClickListener(this);

webView = (CloudipspWebView) findViewById(R.id.web_view);
cloudipsp = new Cloudipsp(MERCHANT_ID, webView);

spinnerCcy.setAdapter(new ArrayAdapter(this, android.R.layout.simple_spinner_item, Currency.values()));
}



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



                @Override
public void onCardInputErrorClear(CardInputView view, EditText editText) {

}

@Override
public void onCardInputErrorCatched(CardInputView view, EditText editText, String error) {
editText.getText();
}



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



            if (card != null) {
final Currency currency = (Currency) spinnerCcy.getSelectedItem();
final Order order = new Order(amount, currency, "vb_" + System.currentTimeMillis(), description, email);

cloudipsp.pay(card, order, new Cloudipsp.PayCallback() {
@Override
public void onPaidProcessed(Receipt receipt) {
Toast.makeText(MainActivity.this, "Paid " + receipt.status.name() + "\nPaymentId:" + receipt.paymentId+"\n Signature:"+receipt.signature, Toast.LENGTH_LONG).show();
}

@Override
public void onPaidFailure(Cloudipsp.Exception e) {
if (e instanceof Cloudipsp.Exception.Failure) {
Cloudipsp.Exception.Failure f = (Cloudipsp.Exception.Failure) e;

Toast.makeText(MainActivity.this, "Failure\nErrorCode: " +
f.errorCode + "\nMessage: " + f.getMessage() + "\nRequestId: " + f.requestId, Toast.LENGTH_LONG).show();
} else if (e instanceof Cloudipsp.Exception.NetworkSecurity) {
Toast.makeText(MainActivity.this, "Network security error: " + e.getMessage(), Toast.LENGTH_LONG).show();
} else if (e instanceof Cloudipsp.Exception.ServerInternalError) {
Toast.makeText(MainActivity.this, "Internal server error: " + e.getMessage(), Toast.LENGTH_LONG).show();
} else if (e instanceof Cloudipsp.Exception.NetworkAccess) {
Toast.makeText(MainActivity.this, "Network error", Toast.LENGTH_LONG).show();
} else {
Toast.makeText(MainActivity.this, "Payment Failed", Toast.LENGTH_LONG).show();
}
e.printStackTrace();
}
});
}


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

https://habrahabr.ru/post/304650/

Метки:   Комментарии (0)КомментироватьВ цитатник или сообщество

Следующие 30  »

<платежные системы - Самое интересное в блогах

Страницы: [1] 2 3 ..
.. 10

LiveInternet.Ru Ссылки: на главную|почта|знакомства|одноклассники|фото|открытки|тесты|чат
О проекте: помощь|контакты|разместить рекламу|версия для pda