Si une entreprise voit la page DuskPay et commence déjà à estimer le coût des paiements transfrontaliers, je commencerais par appuyer sur pause. D’un côté, la page affiche « Payments processed in seconds », de l’autre « Better Payments Are Coming Soon » ; une fois ces deux phrases mises ensemble, ce qui mérite d’être discuté n’est pas la vitesse, mais le moment où le produit passe de la page de présentation à un état réellement intégrable. En faisant défiler la page, je constate que le parcours entreprise reste : créer un compte, intégrer DuskPay, puis commencer à encaisser et à recevoir des paiements. Et la page continue en plus d’inviter les commerçants à rejoindre la waiting list. Détail qui change mon jugement : aujourd’hui, le discours de paiement de DUSK ressemble davantage à une collecte des futurs connectés qu’à une preuve de mise en ligne qui remplacerait des systèmes existants. <@Dusk > au moins met « ce que l’on pourra faire à l’avenir » et « est-ce qu’on peut déjà s’intégrer aujourd’hui » sur la même page.
Le scénario sous pression est en réalité très concret : les commerçants conçoivent d’abord les remboursements et la trésorerie en se basant sur « quelques secondes pour recevoir », puis découvrent que l’API, l’environnement de test et l’intégration officielle ne sont pas encore prêts. Les clients ne vont pas cesser de relancer parce que le produit est encore sur la waiting list ; l’entreprise, elle, doit supporter le coût lié au basculement vers l’ancien canal, à la refonte de la réconciliation et à la modification des interfaces. Ici, l’enjeu n’est pas de savoir si les virements on-chain sont rapides, mais si les limites des engagements avant la mise en ligne sont assez claires. C’est pourquoi je ne considérerai pas la page DuskPay comme une preuve que le volume de paiements est déjà déployé. Ensuite, j’aimerais plutôt voir des documents d’API publics, un environnement sandbox, des explications sur la compensation et le remboursement, ainsi que les étapes à suivre pour passer de la waiting list à l’intégration officielle. Ce n’est que si le parcours est vérifiable que l’histoire de paiement de <$DUSK > pourra passer de « très bientôt » à « les entreprises osent confier le processus ». <#dusk >
Le scénario sous pression est en réalité très concret : les commerçants conçoivent d’abord les remboursements et la trésorerie en se basant sur « quelques secondes pour recevoir », puis découvrent que l’API, l’environnement de test et l’intégration officielle ne sont pas encore prêts. Les clients ne vont pas cesser de relancer parce que le produit est encore sur la waiting list ; l’entreprise, elle, doit supporter le coût lié au basculement vers l’ancien canal, à la refonte de la réconciliation et à la modification des interfaces. Ici, l’enjeu n’est pas de savoir si les virements on-chain sont rapides, mais si les limites des engagements avant la mise en ligne sont assez claires. C’est pourquoi je ne considérerai pas la page DuskPay comme une preuve que le volume de paiements est déjà déployé. Ensuite, j’aimerais plutôt voir des documents d’API publics, un environnement sandbox, des explications sur la compensation et le remboursement, ainsi que les étapes à suivre pour passer de la waiting list à l’intégration officielle. Ce n’est que si le parcours est vérifiable que l’histoire de paiement de <$DUSK > pourra passer de « très bientôt » à « les entreprises osent confier le processus ». <#dusk >
