Plateformes et marketplaces
Une adresse de dépôt crypto unique pour chaque utilisateur
Une seule adresse pour tout le monde, c’est le problème : l’argent arrive et rien ne vous dit à qui il appartenait. Créez un client avec votre propre identifiant et vous obtenez une adresse de dépôt permanente dérivée de votre portefeuille — chaque paiement s’identifie lui-même, et rien ne transite par nous.
Pourquoi une adresse partagée ne suffit pas
Toute plateforme qui accepte la crypto se heurte au même mur, dans le même ordre, en général après le premier ticket de support sur un paiement introuvable.
- Une adresse unique vous donne un montant et un expéditeur, jamais celui de vos utilisateurs à qui il revient. Le rapprochement par montant casse dès que deux personnes envoient la même somme.
- Le contournement habituel consiste à tout regrouper puis à reverser plus tard — ce qui transforme une fonctionnalité de paiement en détention de l’argent d’autrui, la chose la plus lourde qu’une plateforme puisse assumer.
- Demander un mémo ou une référence fonctionne jusqu’à ce que quelqu’un l’oublie, et c’est alors un humain qui rapproche une blockchain à la main.
Un appel par utilisateur, une seule fois
Vous envoyez votre propre identifiant d’utilisateur. Vous recevez des adresses qui ne changent jamais : l’appel a lieu à l’inscription, et plus jamais ensuite.
- 01
Créez le client avec votre identifiant
Transmettez l’identifiant existant de l’utilisateur dans `external_ref`. Unheld ne crée pas un identifiant que vous devriez ensuite stocker et faire correspondre — la fiche est indexée sur celui que votre base de données utilise déjà.
- 02
Conservez les adresses reçues
La réponse contient les adresses de dépôt de cet utilisateur, dérivées de votre propre portefeuille. Elles sont permanentes : vous pouvez les afficher, les mettre dans un QR code, ou laisser l’utilisateur les enregistrer et envoyer depuis n’importe où.
- 03
Créditez le compte à l’arrivée du webhook
Un paiement vers cette adresse est rattaché au client auquel elle appartient, et la notification vous renvoie votre propre `externalRef`. Votre application crédite un identifiant qu’elle connaît déjà, sans rapprocher de montants ni lire une chaîne.
L’appel réel
Requête
curl -X POST https://api.unheld.io/api/v1/customers \
-H "Authorization: Bearer $UNHELD_API_KEY" \
-H "Content-Type: application/json" \
-d '{
"external_ref": "user_8412",
"label": "Ada Lovelace",
"supported_assets": ["ETH", "USDC"],
"evm": true
}'Réponse
{
"id": "c7f1…",
"external_ref": "user_8412",
"label": "Ada Lovelace",
"evm_address": "0x…",
"supported_assets": ["ETH", "USDC"],
"receive_method": "auto"
}Nécessite une clé d’API avec le scope `customers:write` ; les relire demande `customers:read`. Les adresses pour chaque chaîne sur laquelle un utilisateur peut payer sont disponibles via `GET /api/v1/customers/:id/addresses`.
Comment un paiement retrouve son utilisateur
L’adresse EST l’identifiant. Comme elle appartient à un seul client et ne change jamais, un paiement entrant est rattaché sans mémo, sans champ de référence et sans recherche par montant — les trois choses qui cassent en production.
Les factures peuvent aussi être liées à un client via `customerId`, de sorte qu’un paiement ponctuel et une adresse de dépôt permanente se rattachent au même utilisateur, dans votre tableau de bord comme dans vos webhooks.
Où se trouve réellement l’argent
Les fonds arrivent sur des adresses dérivées de votre propre portefeuille. Unheld ne conserve que la partie publique, en lecture seule : il ne peut ni les déplacer, ni les geler, ni les perdre, et aucun solde n’est détenu ici pour vous être reversé plus tard.
Ce que cela ne vous dit pas, c’est si votre plateforme, elle, détient des fonds pour ses utilisateurs. C’est probablement le cas si les paiements arrivent sur des adresses que vous contrôlez et que vous devez cette valeur à vos utilisateurs. C’est une question propre à votre montage et à votre juridiction, à laquelle nous ne pouvons pas répondre à votre place — faites-vous conseiller. Nous ne pouvons affirmer que notre côté : l’argent ne transite jamais par Unheld.
Concevoir avec
Chacun de ces points est plus facile à anticiper maintenant qu’à découvrir en production.
- Chaque adresse d’utilisateur dérive d’un seul portefeuille : le vôtre. Vous n’avez donc qu’une phrase de récupération à protéger, pas une par utilisateur — et les fonds ne sont pas cloisonnés par utilisateur au niveau des clés.
- Une adresse permanente est réutilisée par conception, et c’est ce qui permet le rattachement. Cela signifie aussi que l’historique des paiements d’un utilisateur à votre intention peut être retracé et relié sur la blockchain par quiconque connaît son adresse.
- L’adresse d’un utilisateur est fixe par famille de chaînes : la même adresse EVM reçoit sur tous les réseaux EVM que vous avez activés. Activer une nouvelle chaîne n’oblige pas à réémettre les adresses.
- Supprimer un client arrête la surveillance de son adresse ; cela ne déplace pas — et ne peut pas déplacer — ce qui y a déjà été envoyé. L’argent qui arrive après la suppression reste le vôtre, mais rien ne vous en avertira.
Questions
Unheld détient-il les fonds de mes utilisateurs ?
Non. Les paiements vont sur des adresses dérivées de votre propre portefeuille et Unheld ne stocke que la clé publique en lecture seule : aucun solde ici, rien à retirer. Savoir si votre plateforme détient elle-même de la valeur pour ses utilisateurs est une autre question, propre à votre montage, et qui mérite un conseil juridique plutôt qu’une réponse sur une page marketing.
Combien d’utilisateurs peuvent avoir leur propre adresse ?
Il n’y a pas de limite d’adresses par utilisateur : elles sont dérivées, non prélevées sur un pool, donc créer le millionième client est la même opération que le premier. Ce qui est compté, c’est le quota de clients et le nombre de transactions de votre offre, indiqués sur la page des tarifs.
L’adresse d’un utilisateur peut-elle changer ?
Non. C’est la propriété sur laquelle repose tout le dispositif : l’adresse identifie l’utilisateur, elle est donc émise une fois et reste. Vous pouvez l’afficher, l’intégrer à un QR code ou laisser l’utilisateur l’enregistrer dans son portefeuille : elle sera encore juste un an plus tard.
Et si deux utilisateurs paient le même montant en même temps ?
Rien d’ambigu ne se produit, car les montants ne servent jamais à identifier qui que ce soit. Chaque paiement arrive sur une adresse appartenant à un seul client, et le webhook vous renvoie votre propre référence pour ce client — montants identiques, horaires identiques et expéditeurs identiques n’ont aucune importance.
Créez un client sur testnet
Faites l’appel avec une clé d’API de test, récupérez de vraies adresses, et envoyez-y un paiement de testnet pour voir le rattachement arriver — avant tout argent réel.
Commencer gratuitementDéveloppeurs · Abonnements · Tarifs · Non dépositaire · Réponses claires.