Перейти к основному содержимому
УзнатьРуководстваТестируйте платежи агентов без реальных денег
РУКОВОДСТВО

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

12 минут
КРАТКИЙ ОТВЕТ

Swap your API key for a sk_test_ key - that alone puts you on Base Sepolia. Fund the agent's wallet from the public Base Sepolia USDC faucet, make a real test payment with payments.create (test funds, no real money), and tunnel your local webhook through ngrok. The response shapes match live, so a flow that passes in test passes in production. Exercise the failure paths, not just the happy one.

ПРЕДВАРИТЕЛЬНЫЕ УСЛОВИЯ

Перед тем как начать.

  • Работающая интеграция в реальном времени (или, по крайней мере, в реальном формате) - см. добавить-платежи-к-агенту.
  • Ключ API sk_test_ и соответствующий тестовый секрет подписи из панели управления.
  • ngrok (или любой HTTPS-туннель) для доставки вебхуков во время разработки.
  • Отдельная среда разработки - отдельные переменные окружения, отдельная база данных (или, по крайней мере, отдельные таблицы), отдельный URL вебхука.
  • Комфорт с руководством по шаблонам вебхуков - это руководство предполагает, что у вас есть обработчик для тестирования.
ШАГ 1 ИЗ 5

Переключиться на тестовый ключ.

Ключ sk_test_ транзакционируется на Base Sepolia; ключ sk_live_ транзакционируется на основной сети Base. Префикс выбирает сеть - нет отдельной переменной окружения сети, и тестовый ключ не может перемещать средства основной сети. Поэтому все, что вам нужно изменить для среды разработки, это ключ (и секрет вебхука для тестирования).

# .env.development
# A sk_test_ key picks Base Sepolia automatically - there is no network env var.
BLOCKCHAIN0X_API_KEY=sk_test_01J9...
BLOCKCHAIN0X_WEBHOOK_SECRET=...   # the test webhook's secret, from the dashboard
ШАГ 2 ИЗ 5

Пополните кошелек агента из крана.

Тестовый USDC не имеет денежной стоимости, но в остальном ведет себя как живой USDC: те же формы ответов, тот же учет баланса. Нет вызова SDK, который его создает - вы пополняете адрес кошелька агента из публичного крана USDC Base Sepolia. Найдите адрес в панели управления или на публичной странице агента (или прочитайте агента с помощью SDK), затем вставьте его в кран.

TypeScript
import { createClient } from "@blockchain0x/node";

const client = createClient({ apiKey: process.env.BLOCKCHAIN0X_API_KEY! }); // sk_test_

// Look up the agent; its wallet address is shown in the dashboard and on the
// agent's public page. Fund THAT address from the Base Sepolia USDC faucet -
// there is no SDK call that mints test funds.
const agent = await client.agents.get("agt_123");
console.log(agent.id);
Python
from blockchain0x import Client

client = Client()  # reads BLOCKCHAIN0X_API_KEY (sk_test_)

# The agent's wallet address is in the dashboard / on its public page.
# Paste it into the public Base Sepolia USDC faucet to fund it.
agent = client.agents.get("agt_123")
print(agent["id"])
ШАГ 3 ИЗ 5

Сделать реальный тестовый платеж.

С пополненным кошельком вызовите payments.create на вашем ключе sk_test_. Это реальный перевод на Base Sepolia с использованием тестовых средств, и он вызывает вебхук payment.received точно так же, как это сделала бы основная сеть - так вы используете фактический код, а не симуляцию. Следите за тем, как событие попадает в ваш туннелированный обработчик.

TypeScript
// On a sk_test_ key this is a REAL transfer on Base Sepolia (test funds, no
// real money). It fires the payment.received webhook just like mainnet does.
const tx = await client.payments.create({
  agentId: "agt_123",
  to: "0xRecipientOnSepolia",
  amountWei: "10000", // 0.01 USDC
});

console.log(tx); // watch payment.received arrive at your webhook
Python
tx = client.payments.create(body={
    "agentId": "agt_123",
    "to": "0xRecipientOnSepolia",
    "amountWei": "10000",  # 0.01 USDC
})

print(tx)  # watch payment.received arrive at your webhook

Три сценария, которые нужно протестировать как минимум: платеж, который поступает (счастливый путь, payment.received), платеж, который никогда не поступает (укажите вебхук на недоступный URL и подтвердите, что ваша проверка согласования поймала застрявшую задачу - путь, который большинство команд игнорирует), и повторная попытка вебхука (вызовите 500 в первый раз и 200 во второй, затем убедитесь, что ваша идемпотентность пропустила дублирующую работу).

ШАГ 4 ИЗ 5

Туннелируйте вебхуки к вашему локальному обработчику.

Тестовые платежи отправляют реальные вебхуки на тот URL, который вы настроили для тестового вебхука. Для локальной разработки предоставьте ему HTTPS-туннель к вашему ноутбуку. ngrok - самый простой вариант; любой инструмент обратного туннелирования подойдет.

# Tunnel your local webhook endpoint to a public HTTPS URL.
$ ngrok http 3000

# Forwarding   https://abc123.ngrok.app -> http://localhost:3000

# Paste the URL in the dashboard under Webhooks for your test
# environment - test and live keep separate webhook config.

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

ШАГ 5 ИЗ 5

Скоро провалитесь на неправильно настроенных ключах.

Самый распространенный инцидент в производстве вокруг тестовых/живых ключей - это молчаливый: развертывание происходит с тестовым ключом, платежи не проходят, оповещения срабатывают только на следующий рабочий день. Заблокируйте это при запуске: отказывайтесь запускаться, если переменные окружения и префикс ключа не совпадают.

TypeScript
// Fail fast if test/live get mixed up.
const apiKey = process.env.BLOCKCHAIN0X_API_KEY!;
const env = process.env.NODE_ENV;

if (env === "production" && apiKey.startsWith("sk_test_")) {
  throw new Error("Test key in production environment - aborting boot.");
}
if (env !== "production" && apiKey.startsWith("sk_live_")) {
  throw new Error("Live key in non-production environment - aborting boot.");
}
Python
import os, sys

api_key = os.environ["BLOCKCHAIN0X_API_KEY"]
env = os.environ.get("ENV", "development")

if env == "production" and api_key.startswith("sk_test_"):
    sys.exit("Test key in production environment - aborting boot.")
if env != "production" and api_key.startswith("sk_live_"):
    sys.exit("Live key in non-production environment - aborting boot.")
ОБЩИЕ ОШИБКИ

Пять ошибок тестирования, которые аукнутся позже.

Забывая, что Base Sepolia - это собственная цепочка

Ключ sk_test_ транзакционируется на Base Sepolia, а не на основной сети Base. Блок-эксплореры, адреса кошельков и токены газа все разные. Распространенная путаница - скопировать реальный адрес Base в тест, наблюдать, как он не проходит, и думать, что API сломан. Пополните адрес кошелька агента из крана USDC Base Sepolia и оплачивайте адреса, которые существуют на этой цепочке.

Не тестируются пути сбоя

Большинство команд тестируют счастливый путь - платеж, который вызывает payment.received - затем отправляют и позже обнаруживают, что их путь неоплаты сломан. Проведите тест: укажите вебхук на несуществующий URL и подтвердите, что ваша сверка ловит зависшую задачу, заставьте обработчик вернуть 500 и проверьте, что повторная попытка идемпотентна, и убедитесь, что 503 от payments.create (адаптер цепи не подключен) обрабатывается. Тестовые среды дешевы; отладка в производстве дорога.

URL вебхука все еще указывает на ngrok в производстве

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

Доверие к времени тестовой сети как прокси для реального времени.

Base Sepolia не ведет себя идентично основной сети Base - время блоков и загруженность отличаются. Не используйте тестовую сеть для нагрузочного тестирования пропускной способности основной сети и не предполагайте, что ваша задержка в тестовой сети будет такой же, как в производственной среде. Когда вам нужны реальные числа, выполните небольшой тест на основной сети с ключом sk_live_.

Оставление тестовых фикстур в общих базах данных

Если ваши среды разработки и продакшена используют одну и ту же базу данных (не делайте этого), тестовые события попадают в ту же таблицу, что и живые события, и нарушают вашу идемпотентность (префикс ID события отличается, но строка реальна). Минимум, изолируйте таблицу webhook_events для каждой среды. Лучше: полностью разделите базы данных. Это одно из тех правил, которые кажутся избыточными, пока не произойдет сбой.

СЛЕДУЮЩИЕ ШАГИ

Как только тестовый цикл входит в ваш цикл разработки.

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

Полная справка на docs.blockchain0x.com. Подробности тестовой сети: Глоссарий цепи Base. Поверхность продукта: Payment API.

Последний обзор: 2026-05-15. Опубликовано под CC BY 4.0.

Протестируйте это перед отправкой.

Полный песочница: тестовые ключи, Base Sepolia, симулируемый жизненный цикл. Бесплатно.