Тестирование интеграции криптоплатежей должно доказать, что нужный заказ исполняется ровно один раз и только после проверки оплаты, а не просто что страница оплаты открывается. Разделяйте проверку доставки сообщений, проверку состояний заказа в приложении и санкционированную приемочную проверку с реальными средствами. Они отвечают на разные вопросы.
Этот список предназначен для разработчиков и продавцов, которые готовят платежный процесс к запуску, в том числе оплату в USDC или USDT, если выбранные актив и сеть действительно доступны. Это рекомендуемый порядок тестирования, а не отчет о том, что Yolfi прошел эти проверки для вашего приложения или предоставляет полноценную оплату в тестовой сети.
Определите, какой именно тест вы проводите
Имитированное уведомление о платеже — не перевод в блокчейне. Перевод в тестовой сети — не платеж в основной сети. Успешное перенаправление браузера не подтверждает ни то ни другое.
| Уровень проверки | Что можно установить | Чего установить нельзя |
|---|---|---|
| Тесты приложения с контролируемыми тестовыми данными | Переходы состояний заказа, правила отклонения и обработку дублей | Что провайдер может связаться с развернутым обработчиком |
| Тестовый вебхук провайдера | Доступность конечной точки и обработку тестовых данных провайдера | Что средства переведены или реальный счет оплачен |
| Перевод в тестовой сети при явно заявленной поддержке | Поведение в конкретной тестовой сети | Доступность актива в рабочем режиме или расчеты в основной сети |
| Санкционированная приемочная проверка в рабочей среде | Наблюдаемый результат одного реального платежа | Что работают все сети, токены и сценарии сбоев |
Руководство Ethereum по сетям объясняет, что балансы счетов и история транзакций не переносятся между независимыми сетями. Одинаковый вид адреса не делает средства тестовой сети доступными в основной. Изучите актуальную документацию провайдера, а не предполагайте, что обычная проверка кошелька применима к его платежному сервису.
Сначала письменно зафиксируйте границы проверки
До отправки чего-либо запишите среду приложения, учетную запись провайдера, URL обработчика, место хранения секрета подписи, идентификаторы заказов и ожидаемые побочные действия. Для имитационных сценариев используйте временные записи клиентов и отключите реальную доставку, предоставление платного доступа и письма клиентам.
Храните тестовую и рабочую конфигурации раздельно. Никогда не копируйте секрет подписи в статью, снимок экрана, задачу или переписку. Материалы проверки должны указывать версию использованного секрета, но не раскрывать его значение. Не запрашивайте у покупателя фразы восстановления кошелька или закрытые ключи для расследования неудачного теста.
Для проверки с реальными средствами получите явное внутреннее разрешение на сумму, комиссии, адрес назначения и назначьте ответственного. Используйте кошелек под контролем компании и сумму, которую можете позволить себе потерять. Не отправляйте деньги на адрес или в сеть только потому, что они указаны на старом снимке экрана, автоматически созданной странице монеты или в неофициальной инструкции по тестированию.
Докажите, что сумму заказа определяет сервер
В Yolfi API Checkout сервер продавца создает Checkout Session с окончательной суммой и валютой. Затем покупатель выбирает поддерживаемые сеть и токен, и на основе этой сессии создается Invoice. Многоразовый Paylink решает другую задачу, нежели динамический заказ с ценой, рассчитанной сервером.
Для динамической корзины проверьте расчет цены на своем сервере и привязку сессии до проверки движения средств:
- Измените передаваемую браузером итоговую сумму и убедитесь, что она не может подменить достоверную цену заказа.
- Попробуйте использовать идентификатор заказа другого клиента и убедитесь, что приложение запрещает несанкционированный доступ.
- Обновите или заново откройте процесс оплаты и проверьте, что повторные попытки остаются связаны с нужным заказом.
- Измените корзину после создания сессии и убедитесь, что в приложении есть явное правило замены или отклонения прежней попытки оплаты.
Это критерии приемки приложения, а не утверждение, что конечная точка провайдера отклоняет любые возможные запросы. Храните серверный идентификатор заказа вместе с полученным идентификатором сессии. Не выдумывайте поля API и не считайте, что контролируемый браузером идентификатор доказывает право доступа.
Отправьте тестовый вебхук, не создавая реальную продажу
Актуальная документация Yolfi по вебхукам описывает тестовое событие из панели управления, которое использует тот же путь доставки, адаптер и заголовок подписи, что и реальные события. Его данные содержат livemode: false и идентификатор события с префиксом evt_test_. Тест не создает счета, платежные события, подписки или записи клиентов.
Используйте это событие для проверки доставки и обработки данных, а не расчетов. Обработчик, возвращающий 200 OK, все равно может ошибочно предоставлять доступ или незаметно терять сообщение. Проверяйте итоговое состояние приложения наряду с результатом доставки.
Проверяйте подписи по документированной процедуре с секретом подписи конкретной конечной точки, а не с API-ключом организации. Убедитесь, что рабочий процесс исполнения заказов не может принять тестовое событие за оплаченный заказ. Если вы проверяете исполнение на тестовых данных в изолированной среде, используйте временные записи и проверяйте их отдельно от рабочих.
Yolfi требует общедоступный адрес HTTP или HTTPS и не следует перенаправлениям. Для локальной разработки документация рекомендует общедоступный HTTPS-туннель. Проверяйте точный конечный URL обработчика: успешный запрос по другому пути или локальному адресу не доказывает доставку от провайдера.
Используйте матрицу сбоев, а не только снимок успешного сценария
Для случаев, недоступных в средстве отправки тестовых событий провайдера, запускайте контролируемые тестовые данные в своей изолированной среде. Явно помечайте такие проверки как тесты приложения; не выдавайте искусственно созданные события провайдера за доказательство реальной оплаты.
| Сценарий | Что необходимо наблюдать в приложении |
|---|---|
| Корректное тестовое событие | Записано как тестовое; нет реальной доставки или квитанции об оплате |
| Отсутствующая или неверная подпись | Отклонение до изменения заказа |
| Платеж начат, но не подтвержден | Заказ остается неоплаченным |
| Подтвержденный платеж для неизвестного заказа | Отложен для расследования; клиент не подбирается по догадке |
| Одно подписанное событие доставлено дважды | Один надежно сохраненный бизнес-результат без повторной доставки |
| Два обработчика обрабатывают одно событие | Одно решение об исполнении, несмотря на параллельную обработку |
| Обработчик был недоступен, затем восстановлен | Наблюдаемое восстановление без повторного исполнения |
| Браузер закрыт до возврата | Обработка платежа не зависит от страницы возврата |
В Yolfi invoice.created означает начало процесса, а payment.confirmed — документированный сигнал для исполнения заказа. Не помечайте заказ как оплаченный только из-за получения первого сообщения. Руководство по идемпотентным вебхукам описывает надежное устранение дублей; этот список помогает собрать доказательства того, что ваша реализация действительно ведет себя именно так.
Проверяйте восстановление целенаправленно. Процесс, возвращающий успешный ответ до сохранения события, при аварии может потерять работу. Процесс, передающий товар до фиксации завершения, может повторить доставку при повторной попытке. Выберите надежную схему обработки, затем проверьте точки прерывания, а не считайте один успешный запрос доказательством надежности.
Проверьте инструкции покупателю и работу с невыясненными платежами
Откройте реальный процесс оплаты на телефоне и компьютере. Проверьте, что до перевода понятны отображаемая сумма, выбранный актив, сеть, адрес назначения и сведения о сроке действия. Проверьте кнопки копирования и сканирование QR-кода, не предполагая, что QR-код автоматически правильно настраивает любой кошелек отправителя.
Не отправляйте неподдерживаемый токен, не выбирайте намеренно неправильную сеть и не совершайте необратимый перевод только ради проверки сообщения об ошибке. Вместо этого отработайте такие обращения в поддержку на контролируемых записях. Руководство по предотвращению ошибок выбора сети объясняет, какие проверки нужно предусмотреть для покупателя.
Отработайте неоплаченный или просроченный заказ: покупатель должен увидеть понятный статус и безопасный следующий шаг, а не необоснованное обещание вернуть средства. Используйте порядок работы с просроченными счетами, чтобы определить, что выяснить до просьбы оплатить повторно. Второй платеж не должен становиться автоматическим ответом на неясный результат первой попытки.
При наличии разрешения задокументируйте одну проверку реального платежа
Продолжайте только после подтверждения, что выбранные рабочий актив и сеть доступны в реальном процессе оплаты. Учтите необходимые сетевые комиссии и держите адрес назначения под контролем компании. Тестовый вебхук провайдера не оправдывает отправку реальных средств по непроверенному маршруту.
Запишите идентификаторы заказа и платежа, фактические актив и сеть, сумму, наблюдаемое подтверждение, свидетельства из кошелька получателя и итоговое состояние исполнения заказа. Не обещайте универсальное число подтверждений или срок зачисления. Проверяйте фактически наблюдаемый результат, а не только снимок кошелька.
Затем сверьте этот платеж с записями заказа и квитанциями. Список проверок для сверки платежей помогает отличить поступившие средства от их распределения по заказам и комиссий. Если вы планируете вернуть платеж приемочной проверки, отдельно согласуйте и проверьте возврат; не считайте его автоматической отменой операции.
Успешная проверка подтверждает один наблюдаемый маршрут в определенный момент времени. Повторяйте соответствующие приемочные тесты при изменении платежной логики, развертывания обработчика, секретов или поддерживаемых маршрутов. Никогда не считайте один платеж в USDC доказательством работоспособности всех сетей USDT.
Сохраните материалы проверки выпуска
Сохраните краткий отчет с версией проверенного приложения, средой, сценариями, ожидаемыми и фактическими результатами и нерешенными проблемами. Давайте ссылки на закрытые журналы и записи заказов вместо публикации идентификаторов клиентов или полной истории кошельков.
Запретите запуск, если тестовое событие может исполнить реальный заказ, дубль может привести к повторной доставке, неверные подписи могут изменить состояние или подтвержденные платежи нельзя безопасно сопоставить. Назначьте ответственного за каждый нерешенный пункт. Зеленая отметка доставки не заменяет эти бизнес-результаты.
Часто задаваемые вопросы
Переводит ли тестовый вебхук Yolfi криптовалюту?
Нет. Документированный тест проверяет доставку и обработку данных без создания счетов или записей платежей. Он не доказывает, что реальный платеж в блокчейне прошел успешно.
Платеж в тестовой сети — то же самое, что тестовая среда платежного сервиса?
Нет. Тестовая сеть — отдельная сеть блокчейна. Тестовая среда провайдера относится к конкретному сервису. Уточните, поддерживает ли провайдер нужный режим; эта статья не подтверждает наличие у Yolfi оплаты в тестовой сети.
Можно ли запускаться после успешного перенаправления со страницы оплаты?
Одного этого недостаточно. Проверьте серверную обработку платежей, сопоставление заказов, защиту от дублей и восстановление после сбоев. Покупатель может закрыть браузер до открытия любой страницы возврата.
Нужно ли проверять каждый сбой отправкой реальных денег?
Нет. Проверяйте обработку сбоев в изолированных тестах приложения и документированных имитациях провайдера. Любая приемочная проверка с реальными средствами требует разрешения и проверенного поддерживаемого маршрута, а не намеренных переводов в неправильные сети.
Итог: до запуска проверьте бизнес-результат
Начните с четких границ проверки, подтвердите серверную обработку заказов и отличайте имитированное событие от проверенного поступления средств. Используйте платежные ссылки Yolfi для подходящих предложений с фиксированной ценой или документированный процесс API для динамических заказов, а затем сохраняйте доказательства того, что исполнением управляет обработка платежа, а не перенаправление браузера.
