никто не мешает написать приложение для Android, которое будет из трек2 получать реальный номер карты (а не токен) и срок действия, а потом эти данные использовать для MOTO платежей
Советую в архитектуру добавить систему антифрода — без нее вы в будущем получите еще много неприятностей.
И да, ни какой финансовый запрос в АПИ не должен выполняться в обход системы антифрода. Это аксиома для платежного шлюза. У разработчика не должно быть шансов создать endpoint в АПИ не унаследовав базовые проверки в антифроде. В первом приближении система антифрода может быть обычной таблицей барьерных лимитов.
В первую очередь PSP — это продукт, сервис. Мало банков вам предложат полноценный продукт, качественную поддержку. Все-таки банк это банк, а не IT компания. PSP также может дать банальный выигрыш в финансовых условиях: для банка обороты вашего онлайн-бизнеса могут оказаться незначительными, и он предложит вам тариф на общих условиях, если обратитесь напрямую. PSP для него — крупный клиент, и условия для него как правило индивидуальные.
Есть и другие преимущества:
у многих эквайеров АПИ разрабатывает вендор, который зачастую не уделяет внимания его юзабилити и порогу входа для мерчанта. Нам встречался эквайер, у которого чтобы совершить простую покупку, нужно выполнить цепочку из 5 вызовов в том числе к MPI. Кстати вы знаете что такое MPI? И все это через VPN тунель, который, если построен по публичному каналу, а не по выделенному, постоянно отваливается и нужно держать резервный с автопереключением. PSP в этом плане делает интеграцию проще, сгаживая все углы. Мы например предлагаем разные виды интеграций: набор готовых модулей к CMS, PHP/iOS/Android/React Native SDK. Можно кастомизировать дизайн платежной страницы и подгружать ее на своем сайте в виде виджета, а не редиректом, чего банки не дают. При этом страница будет адаптивная для всех видов устройств с хорошей юзабильностью. В личном кабинете есть детальная аналитика по принятым и выплаченным платежам, стандартизированные отчеты, если надо — акты сверок.
PSP может выступать в качестве каскадного процессинга: если платеж не прошел у первого эквайера или эквайер не доступен по техническим причинам, переключает на другого «на лету». А эквайеры довольно часто устраивают 2-3 часовые регламентные работы по обновлению ПО, поскольку Visa и MasterCard требуют от них это делать регулярно. На нашей памяти был случай, когда наш клиент работал через 3-х эквайеров параллельно, и 2 из них упали одновременно. Однажды карты MasterCard другого эквайера были не доступны все выходные. Каскадный процессинг увеличивает конверсию в среднем на 5-10%. Если желаете, мы даже подписываем SLA договор, гарантируя уровень доступности сервиса 99.95%.
гибкий антифрод. У банка как правило стоят обычные лимиты, которые «стреляют» очень часто в самое не подходящий момент. А еще служба безопасности банка любит закручивать гайки на всякий случай. Например в одном из банков лимиты срабатываю почему-то чаще всего по выходным, когда никто из операционного подразделения не доступен. В другом банке ограничение по умолчанию — страна IP-адреса клиента должна совпадать со страной карты. Мы стараемся договориться с банками на минимальные ограничения для нас, а правила антифрода уже настраиваем у себя. Например как вы думаете, какой самый частый фрод у продавцов цветов? Когда мужчина мужчине заказывает цветы и к ним дорогое спиртное. Передавайте нам атрибуты заказа и мы такой платеж автоматом отправим на ручную проверку отделу фрод-мониторинга.
В общем много всяких нюансов, которыми вам прийдется заниматься самостоятельно, если решите работать с эквайером напрямую. Лучше это доверить специалистам PSP, тем более вам это не будет стоить ни копейки.
1. по АПИ или в мерчнт-портале делаете реверс. Средства возвращаются плательщику а с мерчанта удерживаются с последующих выплат
2. да, можно
3. есть правила арбитража от Visa/MasterCard. Они называются Liability Shift. Претензионная работа по этим правилам ведется банками эквайером и эмитентом через подразделение арбитража Visa и MasterCard.
Можно дополнительно еще придумать что-то типа escrow сервиса, который не дает списать средства с плательщика пока служба доставки не отчитается о вручении товара. Но тут PSP возьмет на себя максимум интеграцию с API логистического сервиса, а арбитраж — это уже не его парафия, арбитром должна выступать какая-то третья сторона, например площадка(маркетплейс) через которую осуществляется продажа от торговца к покупателю
спам письмо расчитано на то, что вы на него ответите, типа «а вы не ошиблись — это мне?», а в ответ вам придет ссылка уже с нужным контентом, а ваш имей будет добавлен в спам лист как вот здесь: artimind.livejournal.com/285694.html
Что в предшествующем топике, что в этом авторы имеют поверхностное представление о том, о чем говорят. Ошибки которые бросаются в глаза при беглом чтении топика:
1)во всех спорах между банком-эмитентом [...] и банком-эквайером по поводу интернет-транзакций разрешаются в пользу банка-эмитента
а как же правила претензионной работы и переноса ответственности?
2)Из-за этого банки-эмитенты, когда видели, что им от банка-эквайера приходит запрос на авторизацию с применением Visa 3D Secure или MasterCard SecureCode, просто отказывали в авторизации
не правда, за отказ полагаются огромные штрафы, платежные системы мониторят такие случаи
3)Неважно – ввели ли мошенники правильное имя держателя карты, или даже правильный CVC/CVV – правила платежных систем при card not present транзакциях всегда стоят на стороне держателя карты. Убытки по спорным транзакциям ложатся на банк-эквайер, который перекладывает их на интернет-магазин.
если эмитент авторизовал без CVV2/CVC — это его риски, почитайте правила платежных систем
4)на практике вам следует знать следующее: если вы используете кредитку Сбербанка, который сертифицирован и по Visa 3D Secure, и по MasterCard SecureCode, то независимо от того, использует ли банк-эквайер, обслуживающий тот или иной интернет-магазин, эту технологию, ваши транзакции полностью защищены.
не правда, не защищены, просто переносится ответственность на эквафера
Что в предшествующем топике, что в этом авторы имеют поверхностное представление о том, о чем говорят. Ошибки которые бросаются в глаза при беглом чтении топика:
1)во всех спорах между банком-эмитентом [...] и банком-эквайером по поводу интернет-транзакций разрешаются в пользу банка-эмитента
И да, ни какой финансовый запрос в АПИ не должен выполняться в обход системы антифрода. Это аксиома для платежного шлюза. У разработчика не должно быть шансов создать endpoint в АПИ не унаследовав базовые проверки в антифроде. В первом приближении система антифрода может быть обычной таблицей барьерных лимитов.
Есть и другие преимущества:
В общем много всяких нюансов, которыми вам прийдется заниматься самостоятельно, если решите работать с эквайером напрямую. Лучше это доверить специалистам PSP, тем более вам это не будет стоить ни копейки.
2. да, можно
3. есть правила арбитража от Visa/MasterCard. Они называются Liability Shift. Претензионная работа по этим правилам ведется банками эквайером и эмитентом через подразделение арбитража Visa и MasterCard.
Можно дополнительно еще придумать что-то типа escrow сервиса, который не дает списать средства с плательщика пока служба доставки не отчитается о вручении товара. Но тут PSP возьмет на себя максимум интеграцию с API логистического сервиса, а арбитраж — это уже не его парафия, арбитром должна выступать какая-то третья сторона, например площадка(маркетплейс) через которую осуществляется продажа от торговца к покупателю
лучший способ уменьшить энтропию — это использовать iphone со статической не обновляемой версией iOS
artimind.livejournal.com/285694.html
sp-money.yandex.ru/card/card-payment/bind-sign.xml
Ошибка привязки банковской карты
1)во всех спорах между банком-эмитентом [...] и банком-эквайером по поводу интернет-транзакций разрешаются в пользу банка-эмитента
а как же правила претензионной работы и переноса ответственности?
2)Из-за этого банки-эмитенты, когда видели, что им от банка-эквайера приходит запрос на авторизацию с применением Visa 3D Secure или MasterCard SecureCode, просто отказывали в авторизации
не правда, за отказ полагаются огромные штрафы, платежные системы мониторят такие случаи
3)Неважно – ввели ли мошенники правильное имя держателя карты, или даже правильный CVC/CVV – правила платежных систем при card not present транзакциях всегда стоят на стороне держателя карты. Убытки по спорным транзакциям ложатся на банк-эквайер, который перекладывает их на интернет-магазин.
если эмитент авторизовал без CVV2/CVC — это его риски, почитайте правила платежных систем
4)на практике вам следует знать следующее: если вы используете кредитку Сбербанка, который сертифицирован и по Visa 3D Secure, и по MasterCard SecureCode, то независимо от того, использует ли банк-эквайер, обслуживающий тот или иной интернет-магазин, эту технологию, ваши транзакции полностью защищены.
не правда, не защищены, просто переносится ответственность на эквафера
…
и много много других ошибок
1)во всех спорах между банком-эмитентом [...] и банком-эквайером по поводу интернет-транзакций разрешаются в пользу банка-эмитента