Как протестировать платежи в тинькофф

Обновлено: 25.04.2024

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

Содержание статьи:

— Подходит ли мне Тинькофф?

Интеграция с Тинькофф возможна для юридических лиц и ИП.

Какие способы оплаты доступны?

Какие проценты комиссии с платежей?

Ознакомиться с тарифами Тинькофф на прием платежей можно по ссылке.

Зарегистрируйтесь в Тинькофф. Заполните заявку и анкету магазина. Укажите адрес главной страницы сайта, предварительно создайте на ней витрину вашего магазина.

Основные элементы страницы-витрины: описание продуктов с формой заказа, контактная и юридическая информация.

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

После одобрения магазина менеджерами Тинькофф настройте интеграцию с тестовым терминалом и проведите тестовые платежи.

Для этого скопируйте номер тестового терминала и пароль в личном кабинете Тинькофф.

Переход к тестовому терминалу

Данные тестового терминала

В аккаунте Getcourse откройте раздел «Профиль» — «Настройки аккаунта» — «Интеграция» — «Тинькофф Банк» — «Настройки» и вставьте скопированные данные. Пароль укажите в поле «Секретный ключ».


Указанные в аккаунте Getcourse адреса скопируйте в настройки магазина в кабинете Тинькофф.


Переход к настройкам тестового терминала

Настройки тестового терминала

После настройки интеграции в кабинете Тинькофф перейдите в режим тестирования.

Переход в режим тестирования терминала

В аккаунте Getcourse создайте тестового пользователя, оформите на него заказы.

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

Для оплаты каждого заказа используйте данные тестовых карт, которые указаны в кейсах в кабинете Тинькофф.

После выполнения кейсов № 1-3 нажмите кнопку «Проверить» в кабинете Тинькофф.

Проверка результатов тестирования терминала

Внимание! Проходить тесты 7 и 8 на вкладке «Формирование чека» не нужно.

Тесты для проверки работы онлайн-кассы

Настройте рабочий терминал аналогично тестовому.

Переход к настройке рабочего терминала

Внимание! Замените на рабочие номер и пароль терминала в аккаунте Getcourse.

Номер и пароль рабочего терминала

Чтобы проверить корректность настроек, дождитесь изменения статуса рабочего терминала на статус «Включен», создайте еще один тестовый заказ и оплатите его с помощью реальной карты. При успешной оплате статус заказа изменится на «Завершен».

Рабочий терминал включен

Обратите внимание: GetCourse не поддерживает онлайн-кассу, подключенную на стороне Тинькофф, поэтому на стороне платежной системы онлайн-касса должна быть выключена.

Если вы используете онлайн-кассу Атол, Бизнес.ру Онлайн чеки или CloudKassir, подключите ее напрямую на стороне аккаунта GetCourse. В этом случае чеки будут формироваться для всех платежных систем, подключенных в аккаунте.

Инструкции для подключения онлайн-кассы к аккаунту GetCourse:

После подключения кассы в аккаунте GetCourse выберите ее в настройках интеграции с банком Тинькофф.

Выбор кассы в настройках интеграции на стороне аккаунта GetCourse

Google Pay и Apple Pay

Для приема платежей через Google Pay и Apple Pay указывать дополнительные настройки на стороне Тинькофф либо в аккаунте GetCourse нет необходимости.

Этот способ оплаты будет доступен сразу после включения платежной системы Тинькофф в аккаунте (появляется после нажатия на кнопку «Оплата картой»).






Добрый день)
Как быть пользователям, например ecomkassa?) Хотела через Ю кассу сделать платежи, так они не сотрудничают) Начала с Тинькофф оформлять интеграцию (у нас на нем магазин прекрасно функционирует), так и тут затык с отправкой информации по чекам. Есть ли у меня возможность хоть какую-то интеграцию настроить? Прям беда какая-то)


Здравствуйте, Виктория.
На данный момент использование сервиса Ecomkassa не предусмотрено.




Как настроить продажу курсов в кредит через Тинькофф? Чтобы кредитование происходило через Тинькофф и после доступ выдавался в геткурсе?



Здравствуйте! как на данный момент обстоят дела с онлайн-кассой и Тинькоф экваринг? у меня подключена онлайн касса ecomcass и тинькоф экваринг. правильно ли я понимаю, что на данный момент нет возможности настроить передачу чеков?



Алексей, планируется ли добавление возможности отправки чеков на кассы подключенные со стороны Тинькофф?


Здравствуйте!
Да, такой функционал есть в планах, однако, по срокам реализации данного функционала уточнить возможности нет. Вы можете следить за обновлениями на нашем Telegram канале t.me/getcourse_update


Здравствуйте, пожалуйста, дайте ответ - если у меня Тинькофф и онлайн-касса ОранжДата - смогу ли я установить интеграцию с Геткурсом? Благодарю!


Сам Тинькоф с ОранжДата взаимодействует, но внизу прочитал, что у пользователя были некоторые проблемы с Геткурсом.



Здравствуйте, подскажите на это этапе "Укажите адрес главной страницы сайта, на которой нужно будет создать витрину вашего магазина." нужно указывать адрес на котором у нас аккаунт геткурс или адрес на котором у нас лендинг?


Для страницы-витрины необходимо использовать адрес с системным доменом, который используется для настройки интеграции.

Доброго! Орандждата онлайн касса с яндекс кассой работают норм. Подключаю Тинькофф-эквайринг. Не проходит тест по формированию/отправке чеков. Остальные тесты работают.

Из онлайн-кассы орандждата ответили: "С нашей стороны видим что интеграция настроена, по кассе ошибок не наблюдается. Данный параметр вам нужно добавить со своей стороны. Запросов от Тинькофф не поступает. Вам нужно производить настройки по подключению со стороны Тинькофф."

Из Тинькофф банка ответили: "С нашей стороны производить настройки не надо.
GetCourse не передает нам данные чека, а передает напрямую в кассовый сервис. Поэтому со стороны GetCourse нужно проверять настройки."

Как мне добиться отправки чеков при оплатах в связке с Тинькофф и Орандждата?
Алексей Евчук,
аккаунт astrabot.


Время от времени у заемщика возникает необходимость в проверке своей задолженности, в основном – чтобы спланировать свои финансовые траты или посмотреть, сколько еще нужно отдать. Естественно, Тинькофф Банк представил своим клиентам несколько удобных способов для получения этой информации. Рассмотрим их.

Способы получения информации по кредиту в Тинькофф Банке

Личный кабинет

Когда речь идет о вопросе: «Как посмотреть остаток по кредиту наличными или кредитке в Тинькофф?», первый ответ, который должен приходить в голову – интернет, потому что банк «заточен» под эту технологию. С помощью интернета можно посмотреть остаток двумя путями: через сайт и через приложение. Здесь рассмотрим десктопную версию (сайт).

Проверка кредитной карты:





Если хотите узнать сумму остатка по кредиту наличными, сделайте следующее:

  1. Зайдите в личный кабинет (аналогично первому пункту предыдущей инструкции).
  2. В боковом меню выберите «Кредит наличными».
  3. Посмотрите на «Общую задолженность» – это и есть остаток, который нужно выплатить.



Мобильное приложение

И в Google Play, и в AppStore приложение называется «Тинькофф». Что делать:

  1. Скачиваем, устанавливаем, регистрируемся при необходимости.
  2. Открываем приложение. На главной странице будут все ваши продукты.









Через E-mail

Этот способ сработает, если при оформлении кредита вы указали в договоре почту, с которой будете слать письмо, в качестве средства связи. Во-первых, каждый месяц на эту почту будет приходить выписка по счету – можете поискать остаток там. Во-вторых, вы можете узнать остаток на текущий момент, послав на [email protected] письмо с запросом (в свободной форме).

По телефону по номеру договора

  • Кредитка: 8 800 5551010.
  • Кредит наличными: 8 800 5550911.

Звоните, называете номер договора, если оператор задаст уточняющие вопросы – отвечаете, получаете остаток.

Как узнать остаток по кредиту в отделении Тинькофф Банка?

Узнать остаток в офисе проблематично, потому что у Тинькофф Банка всего один офис, в Москве. Банк в основном работает через интернет, что позволяет экономить на офисах и предлагать более выгодные продукты. Если по каким-по причинам вам все же хочется узнать остаток в офисе, то вот адрес: Москва, 1-й Волоколамский проезд, д. 10, стр. 1. Зайдите туда с паспортом.

Трудности, с которыми нам пришлось столкнуться, и как мы их преодолевали.

Конкретные решения по некоторым распространенным кейсам при написании интеграционных тестов.

Подход к написанию E2E-тестов (тестов, покрывающих взаимодействие всех систем приложения, включая back-end и пользовательский интерфейс) с использованием паттерна PageObject, пришедшего к нам из мира веб-разработки.

Вместо предисловия

Было время, когда солнце светило ярче, орки были зеленее, а мобильный банк Тинькофф писали восемь человек. Тогда почти все фичи катились без какого-либо тестового покрытия. В лучшем случае основные компоненты бизнес-логики могли быть покрыты Unit-тестами.

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

Этап принятия

Ранее E2E-тесты писали только автоматизаторы, которых было несколько человек. Тестами покрывалась только малая часть основного функционала. Регресс-тестирование начало затягиваться, и выкатывать фичи в прод стало труднее с учетом роста команды.

Первый шаг, который мы сделали, — передали написание E2E-тестов разработчикам, причем на обязательной основе. Ни одна фича не может перейти в статус Ready если она не покрыта E2E-тестами. Поскольку критерии приемки задачи описывают QA-специалисты, то они и писали тест-кейсы для каждой фичи.

Тест-кейсы

Тест-кейсы — это шаги, по которым QA-специалист проходит во время тестирования фичи. Сюда входят всевозможные проверки пользовательского флоу, реакция приложения на разного рода corner-case-проверки наличия UI-элементов на экране и так далее.

Пример тест кейса

Тут мы столкнулись с несколькими проблемами:

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

Появилось большое количество тестов с повторяющимся флоу. Например, есть фича, в которой пользователь может заказывать справки. Пользователь попадал на экран «Списка справок», выбирал справку, после чего открывался экран «Настроек справки» (выбор языка, даты и так далее). После мы попадали на экран «Превью», где мы могли посмотреть PDF-файл нашей справки.

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

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

По итогу мы получали пирамиду тестирования в виде песочных часов. Мы делали много Unit- и E2E-тестов и практически не писали интеграционных тестов.

Почему это не круто?

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

Е2Е-тесты хорошо проверяют интеграцию между всеми компонентами приложения, но обходятся они достаточно дорого по следующим причинам:

Тесты запускаются на эмуляторах. Сам тест проходит долго, потому как он имитирует реальные действия пользователя (одна только авторизация длится около 30 секунд на каждом запуске теста).

Прогон Е2Е-тестов занимает много времени. Чтобы запускать такие тесты на пул-реквестах, нужно иметь достаточно мощностей. На данном этапе мы не можем этого делать. Это значит, что обратную связь о том, что что-то сломалось, мы получаем значительно позже. Но для нас это одна из приоритетных целей в области тестирования!

Из-за того, что прогоны тестов проводятся на CI, иногда достаточно трудно понять, по какой именно причине сломался тест.

Е2Е-тесты имеют свойство падать без каких-либо изменений в коде (нестабильность интернета, нестабильность тестового фреймворка, проблемы на реальном устройстве и другие причины), именно поэтому их еще называют flaky tests.

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

Почему так?

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

Для E2E-тестов понятно, что на тестовом окружении должно быть поднято все, а для интеграционного — только часть и не всегда понятно какая. Это приводило к тому, что всем было проще не разбираться и писать E2E тесты. Это негативно сказывалось на времени прогона тестов в целом.

Еще одной причиной была архитектура приложения. Она была не готова для комфортного написания интеграционных тестов. Поэтому, когда вставал вопрос — написать ли интеграционный тест на проверку корректности отправленного запроса в сеть с помощью E2E-теста или же написать тест, который это проверит на JVM, — выбор почти всегда был в пользу E2E.

Что мы сделали

Командный тренинг

Первое, что мы сделали, — командный курс. Выделили несколько команд-добровольцев, которые готовы были первыми попробовать на себе новые подходы к написанию тестов. Внутри компании провели несколько лекций и воркшопов, где разработчики вместе с QA могли разобрать какие-то тестовые кейсы, обсудить, какие кейсы и как лучше покрывать.

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

Пользовательские истории

У нас было много обсуждений с QA, пока мы не пришли к формату тест-кейса, который должен показывать какую-то пользовательскую историю.

У нас есть фича, в которой пользователь заказывает себе справку по счету. Здесь имеется три экрана:

Экран списка справок.

Экран настроек справки (язык, период и так далее).

Экран превью справки.

Как бы это выглядело раньше?

Мы бы проверили Экран списка справок: UI-элементы, отправляемые запросы. После чего аналогичные проверки были бы на другие два экрана.

Здесь было две проблемы:

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

Было много запусков тестов на реальном устройстве, которые во многом дублировали себя.

Как это сделано сейчас?

Тест-кейс != Е2Е-тест.

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

Сам тест разделяется на шаги (steps). Обычно шаг — это один экран внутри всего флоу (но бывают и другие ситуации). Мы пишем в description название этого шага, делаем скриншот и все проверки, которые касаются этого шага.

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

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

Пирамида

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

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

Мы с ребятами начали разбивать монолитные компоненты на фича-модули. Наша задача — вынести компоненты приложения, которыми пользовались все фича-команды (сетевые слои, работа с базами данных, аналитика и другие).

После чего внутри фича-команд создали задачи на рефакторинг своих фича-модулей и бизнес-сущностей, многие из которых рефакторятся в процессе написания тестов.

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

Выделили отдельные Аndroid-модули для тестовых компонентов.

Подготовили базовые моки (сущности хранения сессий, базы данных и так далее).

Написали документацию по основным принципам тестирования с примерами.

Итоги

Мы пришли к осмысленной, правильной пирамиде тестирования.

Начали более сбалансированно распределять тесты по слоям.

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

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

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

Клиенты

Соцсети «Тинькофф Банка» наводнили жалобы от клиентов об оформлении рассрочки без их согласия после просмотра спецпредложения в приложении. Пользователи рунета обвиняют компанию в недобросовестном отношении к потребителям и массово пишут в техподдержку с требованием отключить опцию.


Султан Мухтаров

Сегодня мониторю я свою кредитку для учёта движения средств, и вижу, что у меня активна рассрочка покупки в «Ленте» на сумму 564 рубля. Пишу в техподдержку, уточняю, откуда появилась рассрочка, а мне отвечают – она автоматически активировалась после просмотра спецпредложения.
Тут я выпал: то есть теперь решение о рассрочке (а по факту это кредит, так как понятия «рассрочка» нет в законодательстве РФ) принимается на основе просмотра всякой дичи, которую «Тинькофф» присылает в сторисах и в уведомлениях.

В комментариях к посту банк подтвердил, что для активация рассрочки достаточно посмотреть спецпредложение в приложении сервиса.

Здравствуйте. Сейчас и правда для активации рассрочки достаточно просмотреть спецпредложение. В этом нет никакой ошибки.

Клиенты

Скриншот ответа от представителей «Тинькофф Банка»

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


Николай

50 рублей на три месяца за покупку в «Пятёрочке».


Григорий Матасов

Действительно нашёл у себя активированные рассрочки после просмотра сторис. Поддержка обещала добавить меня в специальный список.
«Тинькофф», вы там совсем кукухой поехали?

Интернет-пользователи заполнили соцсети компании гневными комментариями, требуя объяснений по поводу оформления банком рассрочки без одобрения клиента.

Вадим Мухетдинов

Без спроса оформлять рассрочки после просмотра сторис — это , конечно, треш…

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

Спецпредложение от партнёров по рассрочке активируются автоматически, если их просмотреть в приложении, и если вы совершаете покупку, которая соответствует условиям спецпредложения.

Клиенты

Скриншоты переписки с оператором «Тинькофф Банка»

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


Дмитрий Вилов

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

Проверить, есть ли у вас активные рассрочки, можно в приложении, нажав на иконку с кредитной картой «Тинькофф Банк». Чуть ниже общей информации по продукту и тратам находится раздел с доступными предложениями по рассрочке от компаний-партнёров — это могут быть как заказы из магазина одежды, так и недорогие покупки в супермаркете, аптеке или кафе. Рядом с оформленной банком рассрочкой будет стоять соответствующая надпись «активная».

Ранее Medialeaks рассказал, как пользователи рунета закидали соцсети Леди Гаги за то, что та назвала россиян «тупыми» на концерте. В комментариях возмущённые слушатели оставляли цитаты из гимна РФ.

В другом материале Medialeaks можно прочитать яркие изречения Олега Тинькова из интервью у Юрия Дудя (признан в РФ иноагентом), которые помогут дерзко осадить оппонента в споре.

В GetCourse вы можете принимать платежи с помощью многих платёжных систем.

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

Посмотрите нашу видео-инструкцию о том, как протестировать приём оплаты:

Как протестировать оплату после интеграции платежной системы

Для проведения проверки выполните следующие действия:

  • Создайте предложение.
  • Создайте заказ для тестового пользователя. Это можно сделать из карточки пользователя или в разделе «заказы».
    Рекомендуем назначать сумму заказа не менее 20 рублей, так как часть средств будет списана в счёт оплаты комиссии платёжной системы. Сумма платежа должна быть больше суммы комиссии.
  • Из карточки заказа перейдите на страницу оплаты и совершите реальный платёж с помощью той платёжной системы, которую хотите протестировать.



После этого, если интеграция с платёжной системой выполнена верно, заказ будет иметь статус «Завершён» или «Частично оплачен» — в зависимости от внесённой вами суммы оплаты.

Кроме того, в карточке заказа появится информация о совершённом платеже.


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



NEW

Ольга Плотникова удалить

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







Добрый день. Клиент совершил оплату курса, вошел по ссылке в почте перейти к заказу, открыл платформу геткурс, но заказа в доступных тренингах нет



Здравствуйте, что делать, если деньги списались, но на платформе не написано, что заказ завершен. До сих пор стоит статус "новый". Что делать?



Здравствуйте, что делать, если деньги списались, но на платформе не написано, что заказ завершен. До сих пор стоит статус "новый". Что делать?



Что значит совершите реальный платеж? Заплатить деньги реальной картой? А потом перевести его в ложный?


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

При этом сумма платежа может быть минимальной (20 рублей).
Далее вы можете изменить статус заказа на “Ложный”, чтобы он не учитывался в статистике аккаунта.

Автор статьи

Куприянов Денис Юрьевич

Куприянов Денис Юрьевич

Юрист частного права

Страница автора

Читайте также: