Tester les paiements des agents sans argent réel.
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.
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.
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 dashboardFinancer 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.
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);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"])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é.
// 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 webhooktx = client.payments.create(body={
"agentId": "agt_123",
"to": "0xRecipientOnSepolia",
"amountWei": "10000", # 0.01 USDC
})
print(tx) # watch payment.received arrive at your webhookTrois 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).
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.
É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.
// 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.");
}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.")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.
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.
Les modèles de webhook dont les développeurs parlent le plus
Sécurisez votre portefeuille d'agent avant de passer en direct
Migrer de Stripe vers Blockchain0x pour un accès API piloté par l'agent
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.