Comments 18
… одной рукой лечит, другой калечит.
Вы уже месяц сломали пополнение в валюте через unistream, а саппорт просит показать, какая там ошибка (как будто пользователям дают смотреть в мониторы операционисток).
В декабре интегрировали SDK в приложение. Выяснилось, что вообще вся логика по отправки чеков, все платежные данные, tokenы необходимо передавать в приложение и от туда оно отправляется на ваш сервер напрямую. Никакой промежуточной обработки данных на нашем сервере. В итоге любое изменение бизнес логики или законодательства потребвоало бы выпускать новую версию. Это все еще так?
У нас есть некоторые расширения логики в новой версии, например можно инициировать платеж в приложении, выполнить дополнительную обработку на вашем сервере и уже после открыть экран sdk с переданным paymentId, для ввода карточных данных пользователем и подтверждения платежа. В общем случае, логика обработки платежей происходит на наших серверах и изменения в законодательстве сразу же будут учтены. Если у вас есть вопросы по конкретным кейсам, напишите нам на почту oplata@tinkoff.ru, поможем разобраться.
Пример: появилось новое обязательное поле в чеке. Или сменился тип юрлица. И это сломает все, потому что вместо «тонкого» клиента, вы сделали «толстого» со всей логикой внутри. Это просто не подходит. Мало того, надо еще делать собственное шифрование, чтобы получить все данные о юрлице, токенах с сервера в приложение. Надеюсь вы учтете это в следующей версии.
Почему тинькофф не сделает встраиваемые поля в дизайн сайта продавца?
Через iframe можно все сделать безопасно и удобно для продавца.
Через iframe можно все сделать безопасно и удобно для продавца.
Появится ли когда-нибудь решение для веба вроде такого?
docs.mandarin.io/pay-russian/user_interface.html#mandarin-custom-pay
stripe.com/payments/elements
developers.braintreepayments.com/guides/hosted-fields/overview/javascript/v3
docs.mandarin.io/pay-russian/user_interface.html#mandarin-custom-pay
stripe.com/payments/elements
developers.braintreepayments.com/guides/hosted-fields/overview/javascript/v3
Передала ваш вопрос коллегам, я напишу, когда получу ответ
Сейчас для интеграции у нас существует платежный виджет.
С технической стороны мы предоставляем готовый код, который необходимо прописать на сайте для кнопки «оплатить», который вызывает платежную форму.
При этом в планах есть создание более легкого решения, где клиенту необходимо будет только разместить ссылку для кнопки «оплатить», а плательщик внесет все необходимые параметры платежа уже в нашем виджете или они будут предварительно заполнены в конструкторе виджета.
С технической стороны мы предоставляем готовый код, который необходимо прописать на сайте для кнопки «оплатить», который вызывает платежную форму.
При этом в планах есть создание более легкого решения, где клиенту необходимо будет только разместить ссылку для кнопки «оплатить», а плательщик внесет все необходимые параметры платежа уже в нашем виджете или они будут предварительно заполнены в конструкторе виджета.
ваши коллеги не поняли, то о чем я пишу — это возможность встроить поля для ввода данных карты в дизайн своего сайта с возможностью стилизации, это улучшит платежную конверсию, тк не будет лишних редиректов на платежную страницу или всплывающих окон виджета.
При этом с точки зрения стандарта безопасности PCI DSS все остается на высоком уровне — каждое поле для данных карты грузится как отдельный прозрачный iframe с защищенного сервера банка, а поля можно стилизовать в рамках параметров API.
Клиент при этом доволен улучшенной платежной конверсией и нет головной боли с PCI DSS в отличии от скрипта Checkout от cloudpayments (дочерняя компания tinkoff), где клиенту нужно постоянно сканировать свой сервер на уязвимости и заниматься процедурами для соответствия PCI DSS. Порог вхождения для клиента за счет упрощения сложностей с PCI DSS намного сокращается.
Почему на западе такое есть — а в России только одну компанию нашел.
Спросите пожалуйста у колег еще раз — когда сделаете такое?
При этом с точки зрения стандарта безопасности PCI DSS все остается на высоком уровне — каждое поле для данных карты грузится как отдельный прозрачный iframe с защищенного сервера банка, а поля можно стилизовать в рамках параметров API.
Клиент при этом доволен улучшенной платежной конверсией и нет головной боли с PCI DSS в отличии от скрипта Checkout от cloudpayments (дочерняя компания tinkoff), где клиенту нужно постоянно сканировать свой сервер на уязвимости и заниматься процедурами для соответствия PCI DSS. Порог вхождения для клиента за счет упрощения сложностей с PCI DSS намного сокращается.
Почему на западе такое есть — а в России только одну компанию нашел.
Спросите пожалуйста у колег еще раз — когда сделаете такое?
А эту проблему когда полечите?
github.com/TinkoffCreditSystems/AcquiringSdkAndroid/issues/14
Мы пока используем веб версию на мобилках и ждем…
github.com/TinkoffCreditSystems/AcquiringSdkAndroid/issues/14
Мы пока используем веб версию на мобилках и ждем…
Покупатель попадает в банковское приложение и там подтверждает списание денег. Сумма будет указана в платежной форме.
можно подробнее о там как это работает для покупателя?
какие банки? (со сбера можно платить?)
оплата проходит со счёта, а не с карты? (никакого КБ, со счёта кредитной карты будет с комиссией/не в грейс?)
При выборе способа оплаты через Систему быстрых платежей, покупателю либо будет предложено выбрать банковское приложение, поддерживающее СБП, либо сразу откроется такое приложение, если ранее он выбрал его для этого типа оплаты. Далее в банковском приложении покупатель авторизуется, ему открывается форма для подтверждения платежа, где он может выбрать счет для списания и оплатить покупку.
Сбер пока не поддерживает такой тип оплаты. Полный список банков-участников можно посмотреть здесь
Операции происходят со счета, комиссии с кредитной карты не предусмотрено, так как это покупка, кэшбека не будет
Сбер пока не поддерживает такой тип оплаты. Полный список банков-участников можно посмотреть здесь
Операции происходят со счета, комиссии с кредитной карты не предусмотрено, так как это покупка, кэшбека не будет
Последние несколько месяцев занимаемся разработкой мобильного приложения. Исходно стартовали с эквайрингом от Яндекс.Кассы. Там, в принципе, все шло ровно. Но тут нежданно-негаданно грянул Сбер со своим ребрендингом в Ю-Кассу. Из-за этого резко понадобилось переоформлять личный кабинет, а вместе с ним и договор. Сервис полетел в ад. Менеджеры менялись один за другим. Мы решили глянуь по сторонам. Увидели CloudPayments, но у них какой-то дикий тариф + крайне заносчивая поддержка в стиле «мы предоставляем безумно крутой сервис, поэтому не будем с вами обсуждать ничего». Наконец добрались до Тинькофф. Подумали, что ну тут-то будет супер. Это ж Тинькофф. Лучший онлайн-банк в Галактике. Плюсом шло то, что это банк, а нам по природе сервиса предстояли агентские отношения. Поэтому перспектива держать расчетные счета там же, где эквайринг, добавляла +100500 к простоте проверок по 115-ФЗ. Зарегистрировались, создали ЛК, начали ковырять.
1. Базовые функции, реализованные в SDK (например, получение списка карт) не работают из коробки. Падает с парсингом ответа с сервера. В приложении, которое поставляется как пример, реализован костыль, который эту проблему фиксит. Его надо копировать к себе в апп.
2. Для работы SDK ему нужно передать пароль от терминала. Выше про это писали. Встает закономерный вопрос, что будет просиходить если приложение дизасемблируют и пароль вытащат? Он используется для подписи всех запросов в эквайринг. Почему это безопасно? Ответа нет.
3. Для работы с экварингом создается Магазин. Вместе с ним идут два терминала: Тестовый и Боевой. Для тестового в ЛК есть сценарий проверки интеграции, который состоит из кейсов, вроде «проведите платеж, потом отмените». Мы прошли все кейсы. Боевой терминал не активировался (в ЛК написано, что должен). Постучались в поддержку. Там сказали, что у нас сайт не работает. Мы ответили, что мы делаем мобильное приложение. Его нужно опубликовать в стор, для этого необходимо проверить работу эквайринга. В частности, мы должны протестировать повторные платежи (рекурентные). Можно ли это сделать с тестовым терминалом? Нет, он не дает провести любые операции, отличные от тех, что есть в сценарии активации. Есть ли тестовые карты (а-ля всем известные 4242 4242...)? Нет, такой функционал не предусмотрен. Есть ли тестовый магазин? Нет. Но вы можете проводить для тестирования реальные операци по реальным картам, но для этого нужен боевой терминал, а его мы вам не активируем. За три дня переписки с поддержкой мы так и не поняли, как нам выложить приложение с эквайрингом Тинькофф в AppStore, если мы ничего не можем проверить.
4. Какой-либо SDK для веба не предусмотрен в принципе. Есть некий виджет, из документации к которому «киньте вот эту форму на страницу и загрузите вот этот скрипт».
5. Документация для хуков, которые прилетают от сервера на те или иные события, отсутствует.
Короче, я потратил неделю, искренне желая воспользоваться вашими услугами, потому что мне глубоко симпатичен банк, но пока так и не сумел понять, как мне это сделать. Поддержка не смогла внятно ответить.
Банку: посмотрите на свой продукт и найдите, пожалуйста, лекарство от дестких болезней: напишите документацию подробно объясняющую флоу, сделайте тестовый магазин, дайте возможность заводить новые терминалы. На рынке сейчас нет внятного игрока. Вы можете стать лучшими. Но пока что это тихий ужас.
Разработчикам: если вам нужно быстро и без головной боли сделать эквайринг, пока что соваться в Тинькофф бессмысленно. Тестирование там не работает в принципе, оно не продумано. Документация на уровне перечисления методов в API, а SDK наровит рассыпаться на каждом шагу.
1. Базовые функции, реализованные в SDK (например, получение списка карт) не работают из коробки. Падает с парсингом ответа с сервера. В приложении, которое поставляется как пример, реализован костыль, который эту проблему фиксит. Его надо копировать к себе в апп.
2. Для работы SDK ему нужно передать пароль от терминала. Выше про это писали. Встает закономерный вопрос, что будет просиходить если приложение дизасемблируют и пароль вытащат? Он используется для подписи всех запросов в эквайринг. Почему это безопасно? Ответа нет.
3. Для работы с экварингом создается Магазин. Вместе с ним идут два терминала: Тестовый и Боевой. Для тестового в ЛК есть сценарий проверки интеграции, который состоит из кейсов, вроде «проведите платеж, потом отмените». Мы прошли все кейсы. Боевой терминал не активировался (в ЛК написано, что должен). Постучались в поддержку. Там сказали, что у нас сайт не работает. Мы ответили, что мы делаем мобильное приложение. Его нужно опубликовать в стор, для этого необходимо проверить работу эквайринга. В частности, мы должны протестировать повторные платежи (рекурентные). Можно ли это сделать с тестовым терминалом? Нет, он не дает провести любые операции, отличные от тех, что есть в сценарии активации. Есть ли тестовые карты (а-ля всем известные 4242 4242...)? Нет, такой функционал не предусмотрен. Есть ли тестовый магазин? Нет. Но вы можете проводить для тестирования реальные операци по реальным картам, но для этого нужен боевой терминал, а его мы вам не активируем. За три дня переписки с поддержкой мы так и не поняли, как нам выложить приложение с эквайрингом Тинькофф в AppStore, если мы ничего не можем проверить.
4. Какой-либо SDK для веба не предусмотрен в принципе. Есть некий виджет, из документации к которому «киньте вот эту форму на страницу и загрузите вот этот скрипт».
5. Документация для хуков, которые прилетают от сервера на те или иные события, отсутствует.
Короче, я потратил неделю, искренне желая воспользоваться вашими услугами, потому что мне глубоко симпатичен банк, но пока так и не сумел понять, как мне это сделать. Поддержка не смогла внятно ответить.
Банку: посмотрите на свой продукт и найдите, пожалуйста, лекарство от дестких болезней: напишите документацию подробно объясняющую флоу, сделайте тестовый магазин, дайте возможность заводить новые терминалы. На рынке сейчас нет внятного игрока. Вы можете стать лучшими. Но пока что это тихий ужас.
Разработчикам: если вам нужно быстро и без головной боли сделать эквайринг, пока что соваться в Тинькофф бессмысленно. Тестирование там не работает в принципе, оно не продумано. Документация на уровне перечисления методов в API, а SDK наровит рассыпаться на каждом шагу.
Это всё классно, но расскажите, почему SDK и нормальная документация есть для интернет-эквайринга, а торговый эквайринг такой скрытый?
Sign up to leave a comment.
Опыт Тинькофф Оплаты: улучшили мобильный SDK и сделали оплату в интернете еще удобнее