Passer au contenu principal
ApprendreGuidesTestez les paiements d'agents sans argent réel
GUIDE

Tester les paiements des agents sans argent réel.

12 minutes
RÉPONSE COURTE

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.

PRÉREQUIS

Avant de commencer.

  • Une intégration fonctionnelle en direct (ou au moins en forme de direct) - voir ajouter-des-paiements-à-l-agent.
  • Une clé API sk_test_ et un secret de signature de test correspondant depuis le tableau de bord.
  • ngrok (ou tout tunnel HTTPS) pour la livraison de webhook en temps de développement.
  • Un environnement de développement séparé - variables d'environnement distinctes, base de données distincte (ou au moins tables distinctes), URL de webhook distincte.
  • Confort avec le guide des modèles de webhook - ce guide suppose que vous avez un gestionnaire à tester.
ÉTAPE 1 DE 5

Changer pour une clé de test.

Une clé sk_test_ effectue des transactions sur Base Sepolia ; une clé sk_live_ effectue des transactions sur le mainnet de Base. Le préfixe choisit le réseau - il n'y a pas de variable d'environnement réseau séparée, et une clé de test ne peut pas déplacer des fonds du mainnet. Donc, tout ce que vous changez pour un environnement de développement est la clé (et le secret du webhook de test).

# .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
ÉTAPE 2 DE 5

Financer le portefeuille de l'agent depuis le robinet.

Le USDC de test n'a aucune valeur monétaire mais se comporte autrement comme un USDC réel : mêmes formes de réponse, même suivi de solde. Il n'y a pas d'appel SDK qui le crée - vous financez l'adresse du portefeuille de l'agent à partir du robinet public de USDC de Base Sepolia. Trouvez l'adresse dans le tableau de bord ou sur la page publique de l'agent (ou lisez l'agent avec le SDK), puis collez-la dans le robinet.

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"])
ÉTAPE 3 DE 5

Effectuez un vrai paiement de test.

Avec le portefeuille financé, appelez payments.create sur votre clé sk_test_. C'est un transfert réel sur Base Sepolia utilisant des fonds de test, et cela déclenche le webhook payment.received exactement comme le ferait le mainnet - vous exercez donc le chemin de code réel, pas une simulation. Regardez l'événement arriver à votre gestionnaire tunnelé.

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

Trois scénarios à exercer au minimum : un paiement qui arrive (le chemin heureux, payment.received), un paiement qui n'arrive jamais (dirigez le webhook vers une URL morte et confirmez que votre balayage de réconciliation attrape le travail bloqué - le chemin que la plupart des équipes ignorent), et une nouvelle tentative de webhook (forcez un 500 la première fois et 200 la seconde, puis vérifiez que votre idempotence a sauté le travail en double).

ÉTAPE 4 DE 5

Tunnelisez les webhooks vers votre gestionnaire local.

Les paiements de test envoient de vrais webhooks à l'URL que vous avez configurée pour le webhook de test. Pour le développement local, donnez-lui un tunnel HTTPS vers votre ordinateur portable. ngrok est l'option la plus simple ; tout outil de tunnel inverse fonctionne.

# 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.

Les tests et l'utilisation en direct utilisent des clés séparées et une configuration de webhook distincte, vous pouvez donc laisser la production pointée vers votre véritable point de terminaison pendant que votre tunnel local gère les événements de test.

ÉTAPE 5 DE 5

Échouez rapidement sur des clés mal configurées.

L'incident de production le plus courant concernant les clés de test/en direct est silencieux : un déploiement se fait avec une clé de test, aucun paiement ne passe, les alertes ne se déclenchent qu'après le jour ouvrable suivant. Bloquez cela au démarrage : refusez de démarrer si l'environnement et le préfixe de la clé ne correspondent pas.

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.")
PIÈGES COURANTS

Cinq erreurs de test qui font mal plus tard.

Oublier que Base Sepolia est sa propre chaîne

Une clé sk_test_ effectue des transactions sur Base Sepolia, pas sur le mainnet de Base. Les explorateurs de blocs, les adresses de portefeuille et les jetons de gaz sont tous séparés. Une confusion courante est de copier une adresse Base réelle dans un test, de la voir échouer et de penser que l'API est cassée. Financer l'adresse du portefeuille de l'agent à partir du robinet USDC de Base Sepolia et payer des adresses qui existent sur cette chaîne.

Pas de test des chemins d'échec

La plupart des équipes testent le chemin heureux - un paiement qui déclenche payment.received - puis expédient et découvrent plus tard que leur chemin non payé est cassé. Exercez-le : pointez le webhook vers une URL morte et confirmez que votre balayage de réconciliation attrape le travail bloqué, forcez un 500 de votre gestionnaire et vérifiez que la nouvelle tentative est idempotente, et vérifiez que le 503 de payments.create (adaptateur de chaîne non câblé) est géré. Les environnements de test sont bon marché ; le débogage en production est coûteux.

URL du webhook pointant toujours vers ngrok en production

Changer les préfixes de clé est facile à retenir ; mettre à jour l'URL du webhook est facile à oublier. Si vous passez en production avec l'URL toujours pointée vers le tunnel ngrok de votre ordinateur portable, le premier paiement de production déclenche un webhook dans le vide. Considérez le changement d'URL du webhook comme faisant partie de la liste de contrôle de déploiement, et non comme un paramètre unique.

Faire confiance au timing du testnet comme proxy pour le timing en direct

Base Sepolia ne se comporte pas de manière identique à Base mainnet - le timing des blocs et la congestion diffèrent. N'utilisez pas le testnet pour tester le débit du mainnet, et ne supposez pas que votre latence testnet est ce que vous verrez en production. Lorsque vous avez besoin de chiffres réels, exécutez un test de validation de petit montant sur le mainnet avec une clé sk_live_.

Laisser des fixtures de test dans des bases de données partagées

Si vos environnements de développement et de production partagent une base de données (ne le faites pas), les événements de test se retrouvent dans la même table que les événements en direct et cassent votre dé-duplication d'idempotence (le préfixe d'ID d'événement est différent mais la ligne est réelle). Au minimum, isolez la table webhook_events par environnement. Mieux : séparez complètement les bases de données. C'est l'une de ces règles qui semble excessive jusqu'à ce qu'elle fasse mal une fois.

PROCHAINES ÉTAPES

Une fois que la boucle de test est dans votre cycle de développement.

Avec une boucle de test saine en place, le travail restant consiste principalement à renforcer : gestion fiable des webhooks sous charge, une liste de contrôle de sécurité finale et des migrations depuis tout fournisseur de paiement précédent que vous pourriez utiliser en parallèle.

Référence complète sur docs.blockchain0x.com. Détails du testnet : Glossaire de la chaîne Base. Surface du produit : API de paiement.

Dernière révision : 2026-05-15. Publié sous CC BY 4.0.

Testez-le avant de le déployer.

Sandbox complète : clés de test, Base Sepolia, cycle de vie simulable. Gratuit.