Créer un contexte
Décrivez la commande, la session, les preuves ou la tâche de l'agent séparément des faits de paiement.
Demandez un paiement sans prendre le contrôle du portefeuille.
Créez une Payment Request standard, ajoutez un contexte métier, laissez le client examiner et signer localement, puis suivez le résultat via un modèle de statut cohérent.
Official Testnet integration is open for supported flows. Mainnet settlement, commercial pricing, and service-level commitments are not offered.
Une frontière plus claire
Votre système demande. Le portefeuille du client décide.
VelarumPay maintient une séparation entre les systèmes marchands, les systèmes d'agents et les responsabilités de signature du portefeuille.
Demander un paiement
Envoyez un montant exact, un actif, un réseau, un destinataire, une expiration et une clé d'idempotence.
L'utilisateur approuve
Le client examine les risques et les faits de la transaction avant de signer sur son appareil.
Observer le statut
Votre intégration lit des statuts et événements déterministes sans acquérir d'autorité de signature.
Parcours d'intégration
Un protocole, plusieurs façons de se connecter.
Choisissez la surface adaptée à votre application. Chaque parcours pris en charge converge vers velarum.payment_request.v1.
Intégrez directement avec la Platform API.
Utilisez le contrat OpenAPI publié pour l'appairage, les connexions, les contextes de transaction, les Payment Requests, le statut et les événements. Les services côté serveur valident les portées, l'expiration, les montants exacts et l'idempotence.
Utilisez des assistants typés autour des mêmes contrats.
Le JavaScript SDK regroupe l'appairage, la validation, la création de contexte, la création de Payment Request et l'interrogation du statut dans une surface client plus réduite. L'API et JSON Schema restent la source de vérité.
Donnez aux agents des outils de demande, jamais des clés de portefeuille.
Le serveur MCP et les connecteurs exposent un ensemble d'outils volontairement restreint pour l'appairage, la création de contexte, la demande de paiement et la lecture du statut. Ils ne peuvent pas approuver, signer, exporter des clés ni contourner la vérification du portefeuille.
Adéquation à l’Official Testnet
Commencez là où le modèle de contrôle compte.
Une intégration prise en charge doit avoir un utilisateur, un demandeur, un motif de paiement et un flux d’approbation testable clairement définis.
Paiement marchand
Évaluez l'appairage du portefeuille et les demandes de paiement depuis un flux de commande sans demander au marchand de gérer les clés utilisateur.
Applications de confiance
Connectez des logiciels qui ont besoin de paiements approuvés par l'utilisateur et d'un statut auditable sans autorité dépositaire.
Flux de travail d'agents IA
Permettez à un agent local ou hébergé de proposer un achat tout en préservant une validation déterministe et une approbation humaine.
Ce que votre intégration doit préserver
Faits clairs, portées limitées et état observable.
Une bonne intégration permet à l'utilisateur du portefeuille de vérifier facilement la demande et à votre équipe de diagnostiquer facilement le résultat.
- Chaînes de montants décimaux exactes et identité explicite de l'actif
- Contrôles du réseau, du destinataire, des frais, de l'expiration et de l'idempotence
- Contexte de transaction séparé des faits de paiement immuables
- Portées limitées aux capacités dont votre application a réellement besoin
- Gestion sûre des tokens de connexion et états d'erreur déterministes
- Aucune clé privée, phrase de récupération ou élément de signature dans votre service
Official Testnet integration support
Tell us what you want to integrate.
Share your use case, integration surface, intended user approval flow, and test environment. This support request does not grant mainnet or commercial production access.
Aucune donnée sensibleN'incluez pas de clés API, d'adresses de portefeuille, de phrases de récupération, de clés privées, de données client de production ni d'éléments de signature.
Vous préférez examiner les contrats d'abord ?
Le sous-domaine développeur contient le Quickstart, la surface REST, les schémas du protocole et le guide MCP.