​

Liens de paiement : webhook deposit.incomplete

​

Ce qui a changé

• deposit.incomplete : envoyé pour chaque paiement qui laisse un lien à montant fixe en dessous de son montant. amountPaid est le total reçu jusqu’ici, et metadata contient remainingAmount et une liste partialPayments avec une entrée par paiement on-chain.
• deposit.success plus rapide après un paiement partiel : lorsque le client complète un lien sous-payé, deposit.success est envoyé dès que le paiement final est enregistré. Il pouvait auparavant arriver avec plusieurs minutes, voire plusieurs heures de retard.
• Plus de dépôts en double : le paiement final d’un lien complété n’est plus enregistré une seconde fois comme un dépôt distinct avec son propre deposit.success.
• Montants attendus adaptés au token : le montant d’un lien converti dans le token payé est arrondi à l’inférieur selon les décimales de ce token, afin que le client puisse toujours envoyer le montant exact.

​

Ce que vous devez faire

​

Paiements par agents : x402 et MPP

​

Ce qui a changé

• Payer : les agents paient des requêtes x402 et MPP (charge EVM) en USDC sur les chaînes EVM. Blockradar signe l’autorisation EIP-3009 : la clé privée reste dans Blockradar et le portefeuille payeur n’a pas besoin de gas. Le guide inclut des adaptateurs pour les clients officiels @x402/fetch et mppx.
• Recevoir : les paiements x402 et MPP vers une adresse Blockradar arrivent comme des dépôts ordinaires, avec le webhook deposit.success habituel et le portefeuille payeur comme senderAddress. Cela inclut les paiements x402 sur Solana en USDC, ainsi que les charges MPP sur Tempo mainnet en OUSD, USDC.e et USDT.
• Bientôt disponible : le paiement de charges MPP sur Tempo et les sessions MPP.

​

Ce que vous devez faire

​

Gateway : prise en charge de Solana

​

Ce qui a changé

• Nouvelle chaîne : Solana (mainnet) et Solana Devnet, comme source et comme destination. Les dépôts sont crédités après ~2-3 blocs (environ 8 secondes).
• Soldes combinés : un retrait depuis une master wallet peut puiser à la fois dans vos soldes Gateway EVM et Solana, et émettre sur une chaîne EVM ou sur Solana.
• Destinataires Solana : indiquez dans address une adresse de wallet, et non un compte de jetons USDC. Les comptes de jetons et les autres adresses détenues par un programme sont refusés avec une erreur 400. Si le destinataire n’a pas encore de compte de jetons USDC, Gateway le crée.

​

Ce que vous devez faire

​

Prise en charge de OpenUSD (OUSD)

​

Ce qui a changé

• Nouvel actif : OUSD sur le mainnet, avec 6 décimales sur tous les réseaux :

  Réseau	Adresse du contrat / mint
  Tempo	0x20c0000000000000000000006a37DA5C996874BE
  Base	0xB2000000000000000000002fEb517dFeC7415344
  Ethereum	0x9f6F3991D525015a6F8CaF062C83b62fD3AC4436
  Solana	ousd2mJsPEckLHcSCDxyKD7NDGARZcfLbDZkKiatYHB

• Mainnet uniquement : OUSD n’est disponible sur aucun testnet.
• Solana utilise Token-2022 : le mint Solana est un jeton Token-2022, comme PYUSD sur Solana, et non un jeton SPL classique.

​

Ce que vous devez faire

​

Stellar : Prise en charge de PYUSD

​

Ce qui a change

• Nouvel actif : PYUSD sur Stellar mainnet (code d’actif PYUSD, emetteur GDQE7IXJ4HUHV6RQHIUPRJSEZE4DRS5WY577O2FY6YQ5LVWZ7JZTU2V5, emis par Paxos). Il n’est pas disponible sur Stellar testnet.
• Optionnel : rien ne change pour vos portefeuilles tant que vous n’activez pas PYUSD. L’activer ajoute une trustline PYUSD au portefeuille principal et a chaque adresse activee de ce portefeuille, avec 0,5 XLM de reserve chacun, et augmente de 0,5 XLM le cout d’activation des nouvelles adresses de ce portefeuille.

​

Ce que vous devez faire

​

Stellar : Prise en charge de USDT

​

Ce qui a change

• Nouvel actif : USDT sur Stellar mainnet (code d’actif on-chain USDT0, emetteur GATISXX6BZ6NC7IKQBY37CJD4SOZL3CYZJWXEDG6JVIY4WBS6KXJHN6Q). L’API le renvoie avec le symbole USDT, comme sur toutes les autres blockchains. Il n’est pas disponible sur Stellar testnet.
• Trustlines optionnelles : les trustlines Stellar suivent les actifs actives sur chaque portefeuille. Les portefeuilles qui n’activent pas USDT ne sont pas concernes et aucun XLM ne bouge.
• Cout d’activation : sur un portefeuille ou USDT est active, chaque nouvelle adresse recoit une trustline de plus, l’activation reserve donc 0,5 XLM de plus par adresse (2,5 XLM avec USDC, EURC et USDT actives, au lieu de 2 XLM).
• Adresses existantes : lorsque vous activez USDT sur un portefeuille, son portefeuille principal et chaque adresse activee recoivent automatiquement une trustline USDT en environ 10 minutes. Chacun recoit 0,5 XLM de votre portefeuille principal pour couvrir la reserve supplementaire.
• Depots via bridge : l’USDT transfere vers Stellar via un bridge est emis (mint) directement au destinataire, donc le webhook deposit.success d’un depot via bridge a un senderAddress a null.

​

Ce que vous devez faire

• Pour accepter l’USDT sur Stellar, activez l’actif sur votre portefeuille. Au prealable, assurez-vous que votre portefeuille principal detient au moins 0,5 XLM par adresse activee du portefeuille, plus 0,5 XLM pour le portefeuille principal.
• Assurez-vous que votre gestionnaire de webhooks accepte un senderAddress a null.

​

Retrait en Fiat : Fixez le montant du versement avec amountSide

​

Ce qui a changé

• amountSide sur les endpoints v2 de devis et d’exécution (portefeuille maître et adresse enfant) ainsi que sur l’endpoint v2 de taux de change : source (par défaut) traite amount comme le montant en stablecoin à envoyer ; target le traite comme le montant fiat que le destinataire doit recevoir.
• Avec amountSide: "target", le débit en stablecoin est dérivé du taux coté et arrondi au supérieur selon la précision décimale de l’actif, afin que le versement ne soit jamais inférieur au montant fiat demandé.
• Le paramètre est optionnel et vaut source par défaut, les intégrations existantes restent donc inchangées. Les endpoints v1 de retrait en fiat ne prennent pas en charge amountSide.

​

Ce que vous devez faire

​

Endpoint de validation d’adresses

​

Ce qui a changé

• GET /addresses/validate : passez un slug de blockchain et une address, et la réponse vous indique si l’adresse est valide pour cette chaîne. Pour les blockchains EVM, une adresse valide est renvoyée dans sa forme avec checksum EIP-55. L’endpoint utilise les mêmes règles de validation que les endpoints de retrait et prend en charge toutes les blockchains Blockradar — chaînes EVM, Tron, Solana et Stellar.
• La validation s’effectue hors ligne contre le format d’adresse de la chaîne — aucune consultation on-chain ni aucun filtrage AML n’est effectué, les réponses sont donc rapides. Les limites de débit standard de l’API s’appliquent, validez donc à la soumission du formulaire plutôt qu’à chaque frappe.
• Une adresse invalide renvoie 200 avec isValid: false. Un 404 signifie que le slug de blockchain est inconnu ou indisponible, et un 400 signifie que la requête elle-même est malformée — vous pouvez ainsi distinguer « mauvaise adresse » de « mauvaise requête ».
• Durcissement du lookup AML : envoyer un paramètre de requête blockchain dupliqué à /aml/lookup renvoie désormais un 400 au lieu d’un 500.

​

Ce que vous devez faire

​

Frais de reseau dans les payloads de webhooks

​

Ce qui a changé

• networkFee : le total des frais de réseau payés par vos portefeuilles gérés par Blockradar pour le flux de la transaction, dans le token natif de la chaîne et en USD. Null sur les événements où vous n’avez supporté aucun frais, comme deposit.success où le gas a été payé par le déposant.
• networkFees : un détail par frais. Chaque entrée porte l’opération, le portefeuille payeur, le montant en natif et en USD, et son propre hash de transaction pour vérification on chain. Les entrées sponsorisées par Blockradar sont marquées PLATFORM ou PROVIDER et sont exclues du total networkFee.

​

Ce que vous devez faire

​

Stellar : Contrats Soroban et destinataires muxed

​

Ce qui a change

• Destinataires muxed (M...) : Les retraits acceptent les adresses muxed pour tous les actifs. Les fonds sont regles dans le compte G... sous-jacent, et aucun memo n’est attache — l’identifiant de routage est integre dans l’adresse elle-meme.
• Destinataires contrats Soroban (C...) : Les retraits de tokens (ex. USDC, EURC) peuvent etre envoyes vers des adresses de contrat Soroban. Le transfert s’execute sur le Stellar Asset Contract du token via Soroban RPC. Les destinataires de type contrat sont valides pour les actifs token uniquement — envoyer du XLM natif vers une adresse C... renvoie une erreur 400.
• Transactions Soroban sur les endpoints de signature : Les endpoints /signing/transaction et /signing/broadcast acceptent les transactions Soroban (transferts via Stellar Asset Contract ou invocations de contrat personnalisees). Simulez et assemblez la transaction avant de la soumettre pour signature.

​

Ce que vous devez faire

​

Mises a jour des adresses de contrat cNGN

​

Ce qui a change

• Nouveau deploiement cNGN : Adresses de contrat mises a jour pour cNGN sur Ethereum, BNB Chain, Base, Asset Chain et Arc
• Adresses precedentes reetiquetees : Les adresses existantes sont maintenant marquees comme “Old v2” dans le tableau de bord
• Support d’un nouveau reseau : cNGN est maintenant disponible sur le reseau Arc

​

Ce que vous devez faire

• Allez dans votre tableau de bord et ajoutez les nouveaux actifs cNGN (recherchez ceux sans l’etiquette “Old”)
• Mettez a jour vos integrations pour utiliser les nouvelles adresses de contrat
• Les adresses precedentes continueront de fonctionner pendant la periode de transition

​

Nouvelles adresses de contrat

​

Tokens cNGN de test

​

Changements Majeurs de l’API Comptes Virtuels

​

Pourquoi Ce Changement

​

Ce Qui a Change

​

Nouveaux Endpoints

​

Details de Pagination

​

Nouvelles Fonctionnalites

• Labels de comptes virtuels : Ajoutez des labels personnalises pour organiser les comptes (ex., “Client A”, “Paie”)
• Regeneration de comptes : Generez de nouveaux numeros de compte avec suivi de raison pour l’audit
• Historique des transactions : Consultez les transactions liees a des comptes virtuels specifiques

​

Guide de Migration

const response = await fetch(`/wallets/${walletId}/virtual-accounts`);
const account = await response.json();

console.log(account.accountNumber);
console.log(account.bankName);

const response = await fetch(`/wallets/${walletId}/virtual-accounts`);
const { data, meta } = await response.json();

// Gerer le cas du tableau vide
if (data.length === 0) {
  console.log('Aucun compte virtuel trouve');
  return;
}

// Obtenir le premier compte (equivalent au comportement precedent)
const account = data[0];
console.log(account.accountNumber);
console.log(account.bankName);

// Ou iterer a travers tous les comptes
for (const account of data) {
  console.log(account.accountNumber);
}

// Informations de pagination disponibles dans meta
console.log(`Page ${meta.currentPage} sur ${meta.totalPages}`);

const response = await fetch(`/wallets/${walletId}/virtual-accounts/${virtualAccountId}`);

if (!response.ok) {
  console.log('Compte virtuel non trouve');
  return;
}

const { data } = await response.json();
console.log(data.accountNumber);

​

Exemple de Reponse API

{
  "message": "Virtual accounts retrieved successfully",
  "statusCode": 200,
  "data": [
    {
      "id": "550e8400-e29b-41d4-a716-446655440000",
      "accountNumber": "8012345678",
      "accountName": "Blockradar/John Doe",
      "bankName": "Wema Bank",
      "bankCode": "035",
      "isActive": true,
      "type": "AUTO_FUNDING",
      "label": "Customer Deposits",
      "createdAt": "2026-01-22T10:30:00.000Z",
      "updatedAt": "2026-01-22T10:30:00.000Z"
    }
  ],
  "meta": {
    "itemCount": 1,
    "totalItems": 1,
    "itemsPerPage": 10,
    "totalPages": 1,
    "currentPage": 1
  }
}

{
  "message": "Virtual account retrieved successfully",
  "statusCode": 200,
  "data": {
    "id": "550e8400-e29b-41d4-a716-446655440000",
    "accountNumber": "8012345678",
    "accountName": "Blockradar/John Doe",
    "bankName": "Wema Bank",
    "bankCode": "035",
    "isActive": true,
    "type": "AUTO_FUNDING",
    "label": "Customer Deposits",
    "createdAt": "2026-01-22T10:30:00.000Z",
    "updatedAt": "2026-01-22T10:30:00.000Z"
  }
}

​

Besoin d’Aide ?

• Documentation : Guide des Comptes Virtuels
• Reference API : Endpoints des Comptes Virtuels
• Support par email : [email protected]

​

API Comptes Virtuels

• Nouvelle fonctionnalite : L’API Comptes Virtuels permet aux entreprises de creer et gerer des comptes bancaires virtuels lies aux portefeuilles principaux ou aux adresses enfants
• Conversion fiat-vers-stablecoin : Les clients peuvent recevoir des paiements NGN via des virements bancaires traditionnels, automatiquement convertis en stablecoins cNGN
• Support de financement automatique : Les comptes de type AUTO_FUNDING emettent automatiquement du cNGN lorsque les paiements fiat sont recus et le transferent vers les portefeuilles lies
• Integration portefeuille principal : Creez des comptes virtuels directement lies aux portefeuilles principaux
• Integration adresse enfant : Creez des comptes virtuels lies a des adresses enfants specifiques pour un controle granulaire
• Gestion de compte : Activez ou desactivez les comptes virtuels pour controler le comportement du financement automatique

​

Ce que vous devez faire

• Activer la fonctionnalite : Contactez [email protected] pour activer les comptes virtuels pour votre entreprise
• Assurer le support cNGN : Assurez-vous que votre portefeuille principal prend en charge l’actif stablecoin cNGN
• Mainnet uniquement : Notez que les comptes virtuels sont uniquement disponibles dans l’environnement MAINNET
• Consulter les endpoints API : Consultez la documentation de l’API Comptes Virtuels pour les details d’implementation

​

Endpoints API

​

Endpoints du Portefeuille Principal

• POST /wallets//virtual-accounts - Creer un compte virtuel pour un portefeuille principal
• GET /wallets//virtual-accounts - Recuperer les details du compte virtuel
• PATCH /wallets//virtual-accounts/ - Mettre a jour le statut du compte virtuel

​

Endpoints de l’Adresse Enfant

• POST /wallets//addresses//virtual-accounts - Creer un compte virtuel pour une adresse enfant
• GET /wallets//addresses//virtual-accounts - Recuperer les details du compte virtuel
• PATCH /wallets//addresses//virtual-accounts/ - Mettre a jour le statut du compte virtuel

​

Fonctionnalites Cles

• Devise prise en charge : NGN (Naira nigerien) pour les paiements fiat, cNGN pour la conversion stablecoin
• Flux de financement automatique : Emission et transfert automatiques de cNGN lorsque les paiements sont recus (type AUTO_FUNDING)
• Activation de compte : Controlez le comportement du financement automatique en activant ou desactivant les comptes
• Gestion des clients : Creez des comptes avec les informations client (prenom, nom, email, telephone)

​

Mises a jour des Adresses cNGN Testnet

• Adresses cNGN testnet mises a jour : L’equipe cNGN a mis a jour leurs adresses testnet sur plusieurs reseaux
• Nouveau support d’actifs : Ajout du support pour le stablecoin cNGN mis a jour dans le tableau de bord
• Gestion des actifs : Les adresses testnet precedentes sont maintenant etiquetees comme “old” et seront supprimees dans 30 jours
• Support Tron USDT : Ajout de l’adresse Tron USDT mise a jour avec l’adresse precedente etiquetee comme “old”

​

Ce que vous devez faire

• Allez dans votre tableau de bord et ajoutez les nouveaux actifs cNGN (recherchez ceux sans l’etiquette “old”)
• Mettez a jour vos integrations pour utiliser les nouvelles adresses testnet
• Les anciennes adresses testnet seront automatiquement supprimees apres 30 jours
• Note : Ces changements ne s’appliquent qu’aux environnements testnet - les adresses mainnet restent inchangees

​

Adresses Testnet Mises a Jour

​

Adresse Tron USDT Mise a Jour