Diseño e implementación de un sistema de (micro)pagos
Cómo monetizo mi blog con café, Apple Pay y Mollie
- Publicado
- Actualizado
- (creado )
- Escrito por
- Willem L. Middelkoop
- Temas
- Amsterdam · diseño · iPad · lemmid-store · dinero · pagos · programación · servidor · tablet · vim · trabajo
- Versión humana de este artículo
- https://willem.com/es/2020-03-25_diseno-e-implementacion-de-un-sistema-de-micro-pagos/
- English
- Designing and implementing a (micro) payment system
- Nederlands
- Het ontwerpen en implementeren van een (micro)betaalsysteem
- Deutsch
- Design und Implementierung eines (Mikro-)Zahlungssystems
- Français
- Concevoir et mettre en place un système de (micro)paiement
- Italiano
- Progettare e realizzare un sistema di (micro)pagamenti
- Português
- Conceber e implementar um sistema de (micro)pagamentos
- Papiamentu
- Desèño i implementá un sistema di pago (mikro)
- Frysk
- In (mikro)betelsysteem ûntwerpe en ymplemintearje
- Idiomas
- Traducido del original en inglés por un modelo de lenguaje en dos pasadas (traducción y corrección) con un glosario y un corrector ortográfico; aún no revisado por un hablante nativo.
Resumen
Los pagos online son hoy más importantes que nunca, ahora que el virus COVID-19 ha trastocado los negocios. Esto empuja a mis clientes a buscar nuevas formas de ganar dinero en internet. Yo diseñé e implementé un sistema de (micro)pagos. Este artículo va de cómo lograr la sencillez resolviendo retos complejos.
Texto completo
Entender la nueva tecnología
Cuando desarrollo tecnología o apps nuevas, siempre intento imaginar cómo funcionarían mejor. La forma más fácil de averiguarlo es diseñar el producto para ti mismo. Igual que Steve Jobs hizo que Apple desarrollara su app de presentaciones, Keynote, para él mismo. Es una de sus famosas bromas sobre sí mismo: ser un probador beta mal pagado

Si diseñas el producto para ti, piensa en lo que de verdad, de verdad, querrías. Para mí, eso significa el modelo de interacción más simple posible: quiero que mi software sea sencillo y fácil.
Caso de uso: invítame a un café
Para desarrollar la tecnología de pago, se me ocurrió un caso de uso: añadir un botón de “invítame a un café” a mi sitio web. Si funciona bien, la gente podrá usarlo para mostrar su aprecio por este blog invitándome a un café. Creo que este caso de uso es un reto perfecto para diseñar (y construir) un sistema de (micro)pagos.
Bocetos de ideas
Antes de programar una sola línea de código, suelo diseñar el software dibujando ideas a mano. Me parece que el proceso creativo de dibujar ayuda a explorar ideas, diseños y procesos. Es una de las razones por las que me gusta tanto trabajar en una tableta: dibujar ideas en digital me permite explorar varias a la vez, copiándolas y pegándolas en varias iteraciones.

Prototipo
Cuando ya has explorado ideas para tu interfaz de usuario, toca desarrollar un prototipo. Con un prototipo puedes probar la interfaz en distintos dispositivos y ver qué aspecto y qué tacto tiene.

Durante el prototipado suelo mirar el boceto del diseño mientras programo la primera versión. En el iPad puedes hacerlo con la pantalla dividida: pongo el boceto justo al lado de mi código, que escribo con VIM en tmux sobre Mosh, con la genial Blink app para iPadOS. La taza de café la dibujé con Picta Graphic para iPad, una preciosa app de dibujo que exporta a imágenes vectoriales (SVG).

Desarrollo del frontend
El siguiente paso es desarrollar una interfaz de usuario que funcione del todo, con botones que hagan algo. Durante el desarrollo muchas veces hay que averiguar qué está pasando, cazar errores y afinar mecanismos. Yo uso el Inspect Browser para iPadOS, que me da una pantalla táctil en miniatura, funcionando, justo al lado de mi código. Así puedo probar y perfeccionar la interfaz rápidamente.

Desarrollo del backend
Otro paso crucial es desarrollar la tecnología de backend que prepara y sigue los pagos online. Es tecnología del lado del servidor que se encarga de la comunicación entre la interfaz de usuario (el sitio web) y el proveedor de pagos (bancos, tarjetas de crédito, Apple Pay, etc.).
Diseñar el servidor de backend suele ser algo más abstracto que diseñar una interfaz de usuario (visible). Para saber qué llamadas a la API tienen que producirse y en qué orden, me resulta muy útil dibujar diagramas de secuencia UML. Los diagramas de secuencia muestran las interacciones de un programa a lo largo del tiempo.

En el diagrama de secuencia del proceso de pago ves tres columnas: frontend, backend y proveedor de pagos. Cada columna es un ordenador distinto que se comunica con los demás. El frontend se ejecuta en el dispositivo del usuario, el servidor de backend corre en un VPS que gestiono yo, y el proveedor de pagos es un servidor externo. El usuario interactúa con el sitio web al pulsar el botón de “invítame a un café”, y eso desencadena una cadena de llamadas a la API que fluyen de derecha a izquierda.
El servidor de backend se encarga de calcular el importe que debe pagar el usuario. Lo calcula el servidor y no el cliente, para que ningún usuario malintencionado pueda manipular el cálculo del precio (la tecnología de frontend se puede manipular desde el navegador).
Para preparar una sesión de pago se informa al proveedor de que el usuario va a pagar un importe determinado. Para ello se usa una clave de API secreta que le indica al proveedor a qué cuenta bancaria deben ir los pagos. El proveedor devuelve una URL de pago, que sirve para redirigir al usuario a la página de pago de verdad.

El proveedor de pagos que uso es Mollie, una empresa con sede en Ámsterdam y una plataforma de pagos fantástica. Su API está muy bien documentada y ofrece paquetes para integrar fácilmente su sistema de pago en tu servidor de backend.

Igual que con mis otros servidores de backend, elegí implementarlo en NodeJS. Funciona en prácticamente cualquier cosa, desde una diminuta Raspberry PI hasta grandes nubes de computación. También puedes usar PHP, Ruby, Python o cualquiera de los otros paquetes disponibles. La referencia de la API de Mollie da información detallada sobre los valores que puedes esperar.
Actualizaciones asíncronas del estado del pago
Poca gente se da cuenta de que consultar el estado de un pago es un proceso asíncrono, y que ese estado puede ser de varios tipos. En un mundo perfecto sabrías al instante si un pago ha salido bien o mal. Pero como los pagos online son distribuidos y los backends hablan con servidores distintos (bancos, tarjetas de crédito, etc.), nunca sabes con precisión cuándo se completará un pago.
Piensa en un usuario que cierra la página de pago, que deja su dispositivo desatendido o en un banco cuyo sistema de banca online se cae un rato. Pasa, y te toca a ti diseñar el servidor de backend para que gestione las actualizaciones del estado del pago por separado del proceso principal de interacción con el usuario.

El proveedor de pagos llama a un webhook de nuestro servidor de backend. Trae un mensaje del tipo “Oye, ha cambiado algo en el pago XYZ”. Ese mensaje solo dice que ha cambiado algo, pero no cuál es el nuevo estado. Es por seguridad: si no, un usuario malintencionado podría imitar la llamada a nuestro webhook. En su lugar, nuestro servidor pide el estado real del pago por un canal seguro, con nuestra clave de API secreta. El proveedor devuelve el estado y el servidor lo procesa. Según el estado, se toman las medidas oportunas, como enviar notificaciones por correo electrónico o iniciar la entrega de la mercancía.
Fullstack: unir frontend y backend
El último paso es conectar el frontend con la tecnología de backend para que todo el proceso funcione. Es lo que se llama “desarrollo fullstack”, porque trabajas en todo el sistema. El desarrollo fullstack es un arte aparte que pocos desarrolladores llegan a dominar: exige trabajar (depurar y desarrollar) en varios extremos a la vez, ¡y muchas veces en lenguajes de programación distintos al mismo tiempo!
En la práctica significa que vigilas varias partes del programa para ver si funcionan bien juntas. Miras los registros del servidor mientras intentas hacer un pago con el frontend recién creado. Es duro, pero también muy gratificante, porque el resultado es un producto que funciona.

El botón de “invítame a un café” resultante es, para el usuario, un proceso de 3 pasos engañosamente simple:
- paso 1: pulsa un simple botón de “invítame a un café”, sin formularios de pedido complicados ni códigos captcha irritantes: solo un botón
- paso 2: la interfaz se expande en el mismo sitio, conserva el contexto y te ofrece dejar un mensaje o invitarme a varios cafés. Además, el resto de elementos de la interfaz, como los botones de redes sociales, se ocultan solos para centrar la atención en el café
- paso 3: la pantalla del proveedor de pagos permite pagar con cualquier método disponible, como Apple Pay. Cuando el pago sale bien, ¡toca tomarse el café!

Conclusión
Diseñar e implementar un sistema de pago no es tan difícil cuando sabes lo que tienes que hacer. Eso sí, hacen falta muchos pasos para llegar a entenderlo. Mi botón de “invítame a un café” parece simple, pero para hacerlo tuve que resolver muchos retos distintos de diseño y programación.
No se puede exagerar la importancia de la sencillez, y aun así suele ser muy difícil de conseguir, porque exige entender todos los aspectos del reto. Como dijo Einstein: “La definición de genio es tomar lo complejo y hacerlo simple.” Y ahora, prueba el botón tú mismo: está justo aquí ⬇️