что такое тестовый платеж
Как отключить услугу Мобильный платеж/удалить зарегистрированную карту?
Какие банковские карты могут быть зарегистрированы в услуге?
У клиента не регистрируется карта, в чем может быть проблема, если делается все правильно?
• банк абонента не проводит операции с суммами меньше 10 рублей (а для регистрации может потребоваться проведение тестового платежа на сумму до 10 руб.)
• банк абонента не проводит платежи по электронной коммерции без ввода в качестве подтверждения CVV2-кода (а мы, соответственно, не используем CVV2-код в транзакциях по мобильному платежу)
• банк не поддерживает взаимодействие с нами по данной услуге
• срок действия карты истёк;
• денежных средств на карте недостаточно для списания (резервирования) тестовой суммы (до 10 рублей).
В случае если с нашей стороны все корректно, выяснять причины проблемы клиент должен в банке.
Что такое тестовая сумма/ тестовый платеж и зачем они нужны?
Тестовая сумма (тестовый платеж) необходима для проверки возможности использования конкретной карты для совершения мобильных платежей и для исключения несанкционированного использования карты лицом, не являющимся владельцем банковской карты.
Инструменты пользователя
Инструменты сайта
Содержание
5.5. Тестирование и логи
Вопрос: Как проверить что МД5 работает как надо?
Ответ: Если платеж прошел (и МД5 включен в опциях), значит правильно.
5.5.1. Тестовые платежи
ОПИСАНИЕ.
«Тестовые платежи» это минимальная проверка перед началом работы, если проходят тестовые платежи, то уже можно запускать сервис. Данный инструмент доступен сразу после регистрации еще до приема платежей, именно его следует использовать перед активацией магазина на прием реальных платежей.
КАК ТЕСТИРОВАТЬ
Проведение первого тестового платежа:
Открыть страницу с тестированием можно выбрав пункт «настройки магазина» в главном меню, затем в меню второго уровня выбрать «Тестирование и логи», или перейдя по ссылке «https://secure.onpay.ru/tests/new» после того, как Вы вошли в Кабинет продавца.
Примечание: Тестирование доступно только если в данный момент у вас выбрана фирма и сайт в верхнем меню, так как тестирование осуществляется для определенного сайта.
Внешний вид страницы зеленого кабинета «Тестирование и логи»:
Для использования тестовых платежей поставьте флаг «Включить тестовую валюту», как показано на скриншоте.
Если правильно заполнили поля то увидите сообщение «Платеж сохранен», если где-то была допущена ошибка, то будет сообщение «Ошибка при сохранении или активации платежа».
Если платеж создан, то Вы сможете увидеть его нажав ссылку «Платежи» в главном меню, или перейдя по ссылке «https://secure.onpay.ru/payments».
Внешний вид страницы зеленого кабинета «Платежи»:
На этой же странице Вы в дальнейшем сможете просматривать все свои платежи.
Внешний вид страницы зеленого кабинета «Настройки магазина»:
После того как вы ввели все необходимые данные, нужно нажать кнопку «Сохранить» (возможно потребуется ввести код каптчи).
После сохранения настроек вернитесь обратно на страницу «Тестирование и логи» и проведите еще один тестовый платеж.
Внешний вид страницы зеленого кабинета «Тестирование и логи» с сообщением об ошибке в API :
Если платеж пройдет успешно, то вы увидите сообщение «Платеж сохранен», а также будет 2 запроса в логах, check и pay. Статус платежа можно будет по прежнему посмотреть на странице «Платежи».
5.5.2. Тестовая валюта
5.5.3. Проверить API
Шаг 1. Перед запуском проверки, создайте в вашем магазине следующие заказы в валюте RUR:
Для check запросов заказы №111, №112, №113, №114, №115 на сумму 500
Для pay запросов заказы №211, №212, №213, №214, №215 на сумму 100
Для оформления заказов можно использовать форму оплаты или модуль.
. Заказы должны появиться в «неоплаченных» на странице https://secure.onpay.ru/payment_orders
!!Внимание!! Отрицательный ответ на запрос типа pay не является отменой платежа, а лишь НЕ проставляет статус автоматической обработки.
Пример логов проведенных тестов: 
Тестовый платёж: проверка интеграции с платёжной системой
В GetCourse вы можете принимать платежи с помощью многих платёжных систем.
После того, как вы выбрали подходящую платёжную систему и настроили интеграцию с ней, рекомендуем проверить выполненные настройки. Эта проверка позволит убедиться, что вы готовы к старту продаж и можете получать платежи от своих пользователей.
Посмотрите нашу видео-инструкцию о том, как протестировать приём оплаты:
Как протестировать оплату после интеграции платежной системы
Для проведения проверки выполните следующие действия:
После этого, если интеграция с платёжной системой выполнена верно, заказ будет иметь статус «Завершён» или «Частично оплачен» — в зависимости от внесённой вами суммы оплаты.
Кроме того, в карточке заказа появится информация о совершённом платеже.
После проведения проверки рекомендуем удалить тестовый заказ, чтобы его данные не отображались в статистике продаж вашего аккаунта. Для этого переведите заказ в статус «ложный».
Наталья, добрый день!
Верно, для тестирования корректности настроек интеграции с платежной системой, необходимы выполнить реальную оплату, чтобы оплата поступила в платежную систему, и вы смогли проверить поступает ли от платёжной системы информация об оплате в ваш аккаунт Getcourse.
При этом сумма платежа может быть минимальной (20 рублей).
Далее вы можете изменить статус заказа на “Ложный”, чтобы он не учитывался в статистике аккаунта.
Как протестировать международный платежный сервис без боли и нервов
Меня зовут Саша Зубарчук. Я пришла в компанию Solid три года назад как Junior Manual QA. С того времени я стала автоматизатором, выпустила студентов первой QA School, с которой мы сотрудничали, и перешла на позицию Product Manager.
В этой статье расскажу об особенностях тестирования платежных систем и поделюсь опытом нашей команды: что мы тестируем, как, с какими вызовами сталкиваемся и как на них реагируем. Этот опыт будет полезен тем, кто выстраивает процесс тестирования на проекте — как QA-инженерам, так и Product/Project-менеджерам.
Я не буду углубляться в технику и конкретные инструменты, но расскажу об основной идее: как сделать процесс тестирования технически сложных сервисов максимально прозрачным и спокойным.
Из чего состоит и как работает платежный сервис
Solid — это шлюз, который позволяет компаниям во всем мире принимать онлайн-платежи клиентов разными способами: от банковских карт и электронных кошельков до PayPal и Alipay.
Во всей этой истории есть четыре основных игрока:
Проще говоря, мы помогаем мерчантам монетизироваться и зарабатывать деньги.
У вас мог возникнуть вопрос: почему мерчанты выбирают Solid, если можно напрямую работать с банками? Все просто: 1) банков много, и каждый из них имеет свои специфики — объединяя разные банки из разных стран в единую инфраструктуру, мы добиваемся максимальных конверсий и выручки; 2) у нас есть огромная экспертиза в платежных логиках и антифроде; 3) кроме банковских платежей, мы принимаем все альтернативные способы оплаты, популярные в том или ином регионе, и 4) мы дешевле.
Начнем с первого пункта — что же это за особенности проведения платежей в разных странах? Например, в США, как ни странно, вы не сможете совершить оплату так же просто, как в Украине — используя всего лишь карточные данные. Там банки обязаны проверять дополнительные данные плательщика, такие как платежный адрес и почтовый индекс.
Подобных нюансов — множество. Как и альтернатив карточным платежам. В Нидерландах и Германии, например, люди любят пользоваться локальными интернет-кошельками. Самые популярные способы оплаты в Китае — Alipay, WeChat Pay и UnionPay. А в Нигерии, чтобы оплатить товар в интернете, пользователи идут в банк с наличкой!
Мы принимаем все популярные платежи, без исключения — от банковских карточек до PayPal, электронных кошельков, Google Pay, Apple Pay или SMS. С помощью Solid, мерчант получает доступ к работе со всеми видами оплаты в одной интеграции. Кроме того, шлюз имеет собственную защиту от мошенничества, систему роутинга платежа, инструмент предотвращения необоснованных чарджбеков и многое другое.
Зачем тестировать платежные системы и риски не тестирования
К Solid подключено много мерчантов. Поэтому мы отвечаем не только за свой бизнес, но и за монетизацию всех подключенных к нам клиентов. Если что-то пойдет не так на нашей стороне, мы подводим слишком много компаний. И наоборот — тестируя и улучшая свой платежный сервис, мы улучшаем продукты других бизнесов.
К сожалению, помимо успешного платежа могут возникать ошибки — как системные, так и пользовательские. Важно понимать, что никогда и ни на какой локации не будет проходить 100% платежей успешно. Но со своей стороны мы обязаны сделать все, чтобы конверсия платежей была максимально возможной.
Тестировать платежный шлюз — не шаблонная задача, поскольку это довольно сложный механизм из десятков микросервисов и взаимосвязей. Мы все тестируем в три этапа. Сначала проверяем каждую задачу на изолированном окружении, потом объединяем их и проверяем в релиз-кандидате на стейдже, смотрим, как все работает в интеграции, потом релизим и еще раз тестируем все на продакшене.
Давайте подробнее остановимся на том, что конкретно нам приходится тестировать.
Особенности тестирования платежных систем
Платежная система состоит как из API, так и веб-интерфейсов. Кардинальных отличий в тестировании API и веба для платежных систем, в отличии от любых других продуктов, — нет. Главная особенность — в тестировании конкретно платежей для разных регионов, а также всех вспомогательных сервисов.
Кажется, что тестировать платеж несложно: нужно совершить оплату, проверить, что деньги списались с одного счета, и были зачислены на другой. Но есть нюансы. Тестировщики должны знать особенности платежей в разных странах, а иногда и нюансы местного законодательства и банковской регуляции.
Второй момент — это разные типы платежей: подписки, первый платеж, авторизация (заморозка денег на счету), платеж через электронный кошелек. Для каждого из них есть своя специфика тестирования.
Особое внимание стоит уделить работе с валютами: не все они имеют дробную часть. Например, у гривни есть копейки, а у чилийского песо — нет. Если вы передадите в Украине сумму платежа 100, то банк спишет 1 грн, то есть 100 копеек. А в Чили это будет означать 100 песо. Как видите, такие моменты нельзя упускать.
Что нужно тестировать в платежных системах
Все наши клиенты (веб, мобильные приложения, а также back-end сервисы) общаются с нами при помощи Solid API. Сам же шлюз располагается на отдельном кластере и ведет общение с различными системами (антифрод, токенизатор, банки и т.д.).
Разработчики Solid занимаются решением задач нескольких видов (и все эти задачи в итоге попадают в распоряжение команды QA):
Если обобщить, то все, что мы тестируем, можно разбить на следующие категории:
Backend сервисы Solid:
Шаги к успешному тестированию
Автоматизация
При работе с масштабными IT-решениями, такими как платежные провайдеры, нужно постоянно тестировать не только работу отдельных элементов функционала, но и их взаимодействие. Без автоматизации не получится. Если какой-то сервис не покрыт автотестами — сбоев не избежать. Прогоняйте автотесты при каждой возможности. Вылили задачу на окружение — запустите тесты. Слили несколько задач в релиз-кандидат — запустите тесты.
В нашем случае это происходит примерно так:
У нас есть минимальный набор тестов, который проверяет основные функциональности Solid для процессинга платежей — он проходит меньше, чем за минуту. На все остальные тесты Solid API и других микросервисов уходит порядка 3-4 минут. Тесты по UI, конечно, проходят слегка медленнее. Но и тут мы не прекращаем работу над улучшением и оптимизацией.
Почему изолированное тестирование — не лучший вариант при тестировании платежей? Расскажу на нашем кейсе с антифродом.
У каждого мерчанта Solid подключен антифрод-аккаунт с настройкой правил, как они должны срабатывать. Например, если у мерчанта пользователь за сутки провел больше трех платежей, то четвертый мы блокируем. Или если одной и той же карточкой делают платежи более пяти пользователей — тоже блокируем и добавляем в черный список. Мы покрывали это автотестами, но столкнулись с проблемой.
Изначально мы продублировали все правила на тестовый аккаунт, имитировали мошеннические действия, и тесты вроде как срабатывали. Но получилось так, что у самого мерчанта часто бывают ситуации, когда антифрод-правила комбинируются, например, сработало три из них.
Изолируя каждый платеж под каждое определенное правило, мы избавились от возможности комбинации правил и влияния других сервисов на проведение платежа.
Как мы делали каждый платеж: мы очищали тестовые данные, создавали все условия, чтобы платеж попал под определенное правило, и тогда оно срабатывало. Но не факт, что так будет и в рабочей среде, потому что никогда не будет идеальной ситуации, чтобы платеж попал под одно правило.
Мы решили подключить к тестовому мерчанту реальные антифрод-правила наших клиентов. Тогда они начали отрабатывать более четко. То есть, нужно было создавать не изолированные правила, а тестировать их в совокупности так, как они есть у конкретного клиента.
Сейчас клиенты Solid могут настроить антифрод-правила под себя. Потому что операции, которые похожи на мошенничество для одного мерчанта, могут быть нормой для другого.
Если человек совершает пять покупок за сутки в онлайн-магазине, то это норма: сначала понравился чехол для мобильного, потом блокнот и т.д. Но вот для fitness-приложений — это уже аномалия. Человек вряд ли будет покупать пять программ тренировок в день.
Автоматизация действительно помогает выстроить баланс: вручную проверяются только новые фичи и те сценарии, которые требуют человеческого внимания, все остальное — автоматизировано. Автоматизация поможет снизить как расходы на тестирование, так и риски, связанные с человеческим фактором.
Тестирование на этапе технического задания
Помимо непосредственной проверки работоспособности функционала, мы много времени уделяем тому, чтобы разработчики и менеджеры воспринимали реализуемый функционал одинаково. Кажется очевидным, но многие этим пренебрегают.
Все конфигурационные сервисы довольно сложные, они имеют огромный ряд возможностей и даже самые незначительные детали могут привести к тому, что сервис будет работать не так, как ожидалось.
У техники «раннего тестирования» есть сразу несколько преимуществ:
Хорошая тестовая документация
Действительно хорошая и структурированная внутренняя документация — половина успеха при тестировании. Несмотря на то, что практически весь функционал должен быть автоматизирован, мануальная работа никогда не сойдет на ноль.
Описание процессов тестирования разных функционалов, статьи с решением возможных проблем и различные мануалы ускоряют работу команды тестировщиков.
Мы в Solid создали собственную базу знаний. В ней описано, как работает каждый банк и альтернативный способ оплаты в разных локациях, какие типы оплат банк поддерживает, и как в принципе проходит платеж в том или ином регионе.
Такая база — емкая и сложная задача, которая стала для нас вызовом. Нужно было свести всю документацию воедино и доступно описать процессы. Зато теперь, когда к нам приходит новый сотрудник, не возникает никаких проблем. Сложно запомнить, как что-то должно работать с первого раза, а при наличии тестовой документации вариант ошибиться минимален. Понятная документация позволяет тестировщику точно определить, почему платеж не проходит: это ошибка или в этом банке такой тип платежа просто не должен работать.
Приведу еще один пример. Однажды мы меняли логотипы международных платежных систем на платежных формах. Различных дизайнов для наших клиентов у нас более 200. Для каждого дизайна может быть несколько конфигураций полей на форме. Например, для Бразилии добавляется дополнительное поле CPF — аналог нашего идентификационного кода.
Из-за нового размера логотипа некоторые поля на форме могли съехать, скрыться или стать некликабельными. Никто из команды тестирования Solid просто физически не может знать, как все 200 форм должны выглядеть.
Тестирование этой задачи было нервным, зато в результате мы создали базу знаний с эталонными видами форм для каждого нашего мерчанта, покрыли это автотестами и теперь никакие изменения, связанные с дизайнами, нам не страшны.
Напоследок расскажу маленький интересный факт из мира процессинга: доля деклайнов Restricted Card в Украине довольно низкая — 1-2%. То ли украинские банки так хороши во fraud prevention, то ли карточные данные украинских пользователей никто не хочет воровать…
Тем не менее, нет продукта с идеальными процессами разработки и тестирования, но в наших силах их улучшить. Ведь задача каждого бизнеса — выпустить качественный продукт. Кто еще, если не QA-инженеры, помогут в этом?
Буду рада, если поделитесь своими принципами хорошего процесса тестирования в комментариях.
Как сделать тестовый платеж для участия в пятом этапе акции Ростуризма и «Мира»
Средствам размещения, которые участвуют в пятом этапе акции кешбэк от Ростуризма и используют собственный эквайринг, нужно самостоятельно сделать тестовый платеж по карте «Мир» на сумму 355 рублей 50 копеек (или в размере 356 рублей, если нет возможности оплатить копейками). После 17 декабря 2021 года его можно будет отменить и вернуть деньги. Тестовую транзакцию обязательно провести всем, даже если ранее вы уже использовали терминал в предыдущем этапе Программы. Проведение тестовой транзакции является обязательным условием участия в Программе.
Если вы участвовали в предыдущих этапах Программы, можете использовать ранее полученные идентификаторы (Terminal ID и Merchant ID), если они не использовались после завершения акции и по ним не проходили иные покупки. Либо если покупки по данным идентификаторам были остановлены минимум за 7 календарных дней до проведения тестовой операции.
Если вы решили использовать новые идентификаторы, рекомендуем заблаговременно обратиться в банк для получения Terminal ID и Merchant ID, так как это занимает минимум 2-3 рабочих дня. Полученные в банке Terminal ID, Merchant ID и параметры для подключения необходимо прислать на support@travelline.ru.
Тестовый платеж нужно сделать с 00:01 6 декабря 2021 года до 23:59 11 декабря 2021 года по московскому времени.
Как провести тестовый платёж
1. Создайте в личном кабинете TravelLine отдельный тарифный план с названием «тестмир» и закройте его промокодом «тестмир».
Вы можете воспользоваться инструкцией: Как создать тариф с промокодом.
Используйте в названии тарифного плана и промокода именно такую комбинацию «тестмир»: русскими прописными буквами, без пробела и кавычек.
2. Проставьте в тарифе стоимость на одну дату 355 рублей 50 копеек. Лучше, если стоимость будет указана на один день в декабре, чтобы потом вы могли самостоятельно отменить эту бронь и провести возврат. Операция должна быть именно на эту сумму, по условиям платежной системы «Мир» для тестовых платежей.
3.Выберите в тарифе с названием «тестмир» на вкладке «Описание и условия» способ оплаты с пометкой «Кешбэк», например:
4. Перейдите на форму бронирования TravelLine на вашем сайте, введите промокод «тестмир» и создайте бронирование по тарифу «тестмир». Оплатите бронь банковской картой «Мир».
Важно! Оплата обязательно должна быть совершена по карте «Мир», выданной банком отличным от вашего банка (эквайера).
Что это значит? Если у вас электронный терминал Сбербанка, то для оплаты вам нужно использовать карту любого другого банка, кроме Сбербанка. Если у вас электронный терминал Тинькофф, то карту вы можете использовать любого банка, кроме Тинькофф, и т.д. Для проведения тестовой транзакции не допускается использование кобейджинговых карт «Мир».
Через 3 дня, но не позднее 15 декабря, после проведения тестовой транзакции необходимо осуществить проверку тестовой транзакции через специальный ресурс по адресу https://anketa.privetmir.ru/ Предварительно на сайте необходимо пройти процедуру регистрации в качестве пользователя.
Когда можно отменить тестовый платеж
Тестовый платеж можно отменить не ранее 17 декабря 2021 и не позднее 29 декабря 2021. До этого периода, пожалуйста, не отменяйте бронь, чтобы платежная система «Мир» успела подтвердить платеж.
После 17 декабря 2021 года тарифный план тоже можно будет удалить в личном кабинете TravelLine.
Как отменить тестовый платеж
Для этого зайдите в личный кабинет своей платежной системы или банка и оформите возврат.
Для отмены бронирования в системе TravelLine воспользуйтесь инструкцией: Как отменить бронирование с сайта