Chemin frontend
- 01Collectez le montant, la plateforme de paiement, la devise fiat et l'identifiant de paiement.
- 02Afficher les limites actuelles de la politique du fournisseur et exiger de l'utilisateur qu'il confirme l'admissibilité au compte, à la région et à la transaction.
- 03Transmettez le viem WalletClient connecté à useOfframp() ou createOfframp({ walletClient }).
- 04Affichez les états d’avancement : approving, registering, depositing, confirming, delegating, restricting, resuming et done.
- 05Pour une voie éligible nécessitant l’extension, interceptez EXTENSION_REGISTRATION_REQUIRED et exécutez usePeerExtensionRegistration(platform).
- 06Appelez deposits(address) au chargement de la page pour qu'un rafraîchissement ne laisse pas un vendeur en cours de transaction bloqué.
L'état que vous devriez stocker
| Champ | Raison |
|---|---|
| depositId | Identifiant principal pour close(), les liens OTC et le support |
| txHash | Preuve que l'utilisateur a signé et diffusé la transaction de dépôt |
| platform + currency | Affichage de la route, support et segmentation analytique |
| libellé d'identifiant | Référence de paiement lisible par un humain ; ne stockez pas de secrets |
| integratorId | Attribution stable pour la télémétrie produit et le support |
Contraintes d'UX
- Le SDK cible le mainnet Base ; il n'y a pas de sandbox public. Testez avec le minimum de 1 USDC.
- Chaque dépôt créé par le SDK délègue la tarification au vault Delegate. Ne présentez pas de contrôles de taux manuels pour ce chemin.
- Le fiat reste en dehors du SDK. L'acheteur et le vendeur règlent directement dans l'application de paiement sélectionnée.
- Reconcile narrow owner state with deposits(); use Peerlytics API for broader market data, deposits, intents, and analytics.