L'Agent Merchant API de Rozo supprime cette hypothèse. Une EOA EVM peut s'enregistrer comme marchand avec une seule signature de wallet ; une fois l'accès approuvé, une seconde signature, nouvelle, autorise une API key limitée à Orders pour facturer et lire l'état des paiements. Les fonds sont réglés en USDC sur Base à l'adresse signataire, et l'agent peut interroger l'API jusqu'à ce que le règlement atteigne payout_completed. Ce guide parcourt toute la boucle.
Ce que l'agent obtient réellement
- Un compte marchand lié à son wallet : la première signature valide le crée, les signatures répétées rouvrent le même compte — jamais de doublon.
- Un règlement verrouillé côté serveur en USDC sur Base à l'adresse signataire. Aucun appel d'API ne peut détourner la destination des fonds.
- Une API key limitée à Orders : dans le contrat actuel, elle peut créer des factures et lire l'état des paiements de son compte. Elle ne peut ni émettre des identifiants Admin, ni gérer les réglages du compte, ni modifier le règlement.
- Un lien de paiement par facture, que l'agent partage avec le client. Pour les marchands EVM de cette alpha, le règlement est livré en USDC sur Base.
La boucle en cinq étapes
- Demandez un challenge : GET /account-nonce?chain=evm&address=$ADDRESS&intent=merchant_onboard. Le serveur renvoie le message exact à signer ; les nonces anonymes sont rejetés.
- Signez en local et enregistrez-vous : POST /account-onboard avec l'adresse, la signature et le nonce. La clé privée ne quitte jamais l'environnement de l'agent.
- Demandez l'accès et émettez un identifiant limité : appelez POST /account-credentials/request avec la session de wallet et renvoyez la même demande au plus quelques fois par jour pour vérifier son statut. Une fois approuvé, signez un nouveau challenge credential_issue et appelez POST /account-credentials avec scope "orders". L'identifiant émis a la portée Orders ; les identifiants Orders ne peuvent pas créer de clés Admin.
- Créez une facture : POST /payment-api avec un orderId stable, un Idempotency-Key, les informations d'affichage et le montant en USDC. N'envoyez pas destination. Après une panne réseau, réessayez avec le même orderId et la même clé d'idempotence.
- Interrogez l'état du paiement : faites du polling avec la key Orders et l'orderId stable jusqu'à payout_completed. Considérez l'état renvoyé comme faisant foi même si la livraison du webhook ou de l'e-mail échoue. Si la réponse contient le hash de la transaction de payout, vous pouvez en plus le vérifier sur Base.
Le contrat complet lisible par machine se trouve sur https://partners.rozo.ai/llms.txt — il est écrit pour être collé tel quel dans un agent.
Pourquoi les permissions sont volontairement étroites
Confier un identifiant de paiement à un agent autonome, c'est exactement l'endroit où être paranoïaque. L'API est conçue pour que le rayon d'impact d'une key d'agent divulguée reste réduit :
- Les keys limitées à Orders ne peuvent ni frapper d'autres keys ni changer le règlement, et leurs lectures se limitent à leur propre compte. Lister et révoquer les identifiants émis par wallet exige une signature nouvelle et liée à son objet.
- L'émission d'identifiants exige une nouvelle signature de wallet — un jeton de session volé ne suffit pas à frapper une key.
- Chaque challenge est à usage unique, à objet fixe, avec une expiration fournie par le serveur.
- L'adresse d'encaissement est l'adresse signataire, imposée côté serveur. Une key Orders divulguée ne peut pas changer l'adresse de règlement configurée, mais elle peut créer des factures indésirables et exposer l'état des paiements — révoquez-la sans délai avec une nouvelle preuve de wallet.
Obtenir l'accès (alpha)
Le programme d'identifiants fonctionne sur invitation pendant l'alpha. Après l'enregistrement, l'agent appelle POST /account-credentials/request et renvoie la même demande au plus quelques fois par jour pour vérifier son statut. L'approbation est une décision humaine côté Rozo, mais aucun e-mail ni message direct n'est requis. La boucle identifiants + facturation prend actuellement en charge les EOA EVM réglées en USDC sur Base. Les EOA Solana et Stellar peuvent s'enregistrer et régler l'USDC sur la chaîne de leur adresse signataire, mais restent hors de cette boucle d'identifiants.
Les wallets de contrat EVM ne sont pas pris en charge dans cette alpha, et les comptes wallet-seul n'ont aucune voie de récupération : si la clé signataire est perdue, Rozo ne peut ni récupérer le marchand ni transférer manuellement la propriété.
Commencez sur https://partners.rozo.ai/agent.