Si una empresa ve la página de DuskPay y empieza a estimar el coste de los pagos transfronterizos, yo primero pulsaría el botón de pausa. Mientras en la página se lee “Payments processed in seconds”, en otro lado también aparece “Better Payments Are Coming Soon”. Al poner estas dos frases juntas, lo que merece debate no es la velocidad, sino cuándo el producto pasará de la página promocional a un estado realmente accesible. Cuando leo la página hacia abajo, veo que el flujo para las empresas sigue siendo crear una cuenta, integrar DuskPay y, entonces, empezar a cobrar y a recibir pagos. A la vez, la página sigue invitando a los comercios a unirse a la waiting list. Este detalle me hace cambiar de criterio: la narrativa actual de pagos de DUSK se parece más a la recopilación de quienes se van a conectar, que a una prueba de lanzamiento que sustituya los sistemas de pago existentes. @Dusk al menos pone en la misma página “lo que se podrá hacer en el futuro” y “si hoy se puede conectar”.
El escenario de presión es bastante concreto: los comercios diseñan reembolsos y flujo de caja con la idea de “llegan en segundos” y luego descubren que la API, el entorno de pruebas y la conexión oficial todavía no están preparados. Los clientes no dejan de reclamar por el hecho de que el producto siga en waiting list, pero la empresa sí tiene que asumir el coste de cambiar de canal antiguo, volver a conciliar y ajustar las integraciones. Aquí no se pone a prueba si la transferencia en cadena es rápida o no, sino qué tan claras y delimitadas están las promesas antes del lanzamiento. Por eso no voy a tomar la página de DuskPay como evidencia de que el volumen de pagos ya está materializado. A continuación, lo que más me interesa ver son la documentación pública de la API, el sandbox, las explicaciones sobre liquidaciones y reembolsos, y qué pasos debe seguir un comercio para pasar de la waiting list a la conexión formal. Solo cuando el camino sea verificable, $DUSK la historia de pagos dejará de ser “muy rápido” y se convertirá en “las empresas se atreven a entregar sus procesos a esto”. #dusk
El escenario de presión es bastante concreto: los comercios diseñan reembolsos y flujo de caja con la idea de “llegan en segundos” y luego descubren que la API, el entorno de pruebas y la conexión oficial todavía no están preparados. Los clientes no dejan de reclamar por el hecho de que el producto siga en waiting list, pero la empresa sí tiene que asumir el coste de cambiar de canal antiguo, volver a conciliar y ajustar las integraciones. Aquí no se pone a prueba si la transferencia en cadena es rápida o no, sino qué tan claras y delimitadas están las promesas antes del lanzamiento. Por eso no voy a tomar la página de DuskPay como evidencia de que el volumen de pagos ya está materializado. A continuación, lo que más me interesa ver son la documentación pública de la API, el sandbox, las explicaciones sobre liquidaciones y reembolsos, y qué pasos debe seguir un comercio para pasar de la waiting list a la conexión formal. Solo cuando el camino sea verificable, $DUSK la historia de pagos dejará de ser “muy rápido” y se convertirá en “las empresas se atreven a entregar sus procesos a esto”. #dusk
