--- title: "Diseño e implementación de un sistema de (micro)pagos" date: 2020-03-25 language: es topics: ["Amsterdam", "design", "iPad", "lemmid-store", "money", "payments", "programming", "server", "tablet", "vim", "work"] source_url: https://willem.com/es/2020-03-25_diseno-e-implementacion-de-un-sistema-de-micro-pagos/ --- # Diseño e implementación de un sistema de (micro)pagos *Cómo monetizo mi blog con café, Apple Pay y Mollie* > 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. ## 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 (https://www.youtube.com/watch?v=ViWnJDomhsM) ![Steve Jobs presenta la app Keynote en la Macworld de 2003 y bromea diciendo que la hicieron para él, un probador beta mal pagado](https://willem.com/global/images/0027da9ce9fa.webp) 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. ![Bocetos de concepto de la interfaz, con distintas opciones para dejar un mensaje y comprar varias tazas de café](https://willem.com/global/images/b5830cd60667.webp) ## 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. ![Del boceto del diseño (izquierda) al prototipo (derecha) en el iPad](https://willem.com/global/images/2d289b8f000c.webp) 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 (https://www.vim.org) en tmux (https://github.com/tmux/tmux/wiki) sobre Mosh (https://mosh.org), con la genial Blink (https://blink.sh) app_para_iPadOS (https://apps.apple.com/en/app/blink-shell-mosh-ssh-client/id1156707581). La taza de café la dibujé con Picta_Graphic_para_iPad (https://apps.apple.com/en/app/graphic-for-ipad/id363317633), una preciosa app de dibujo que exporta a imágenes vectoriales (SVG). ![Diseñando la taza de café con Picta Graphic para iPad](https://willem.com/global/images/e35470bb82d5.webp) ## 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 (https://apps.pdyn.net/inspect/) 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. ![Desarrollando la interfaz con Blink e Inspect Browser en el iPad](https://willem.com/global/images/cddef4803d92.webp) ## 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 (https://en.wikipedia.org/wiki/Sequence_diagram) muestran las interacciones de un programa a lo largo del tiempo. ![Diagrama de secuencia dibujado a mano del proceso de pago](https://willem.com/global/images/a24f596e619d.webp) 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. ![Mollie es un proveedor de pagos que admite muchos métodos distintos, como tarjetas de crédito, PayPal, iDEAL, Sofort, Giropay, SEPA, varias apps de bancos y Apple Pay](https://willem.com/global/images/a04e328d248f.webp) El proveedor de pagos que uso es Mollie (https://mollie.com), una empresa con_sede_en_Ámsterdam (https://jobs.mollie.com) y una plataforma de pagos fantástica. Su API está muy_bien_documentada (https://docs.mollie.com/) y ofrece paquetes (https://www.mollie.com/en/developers/packages) para integrar fácilmente su sistema de pago en tu servidor de backend. ![Llamando a Mollie desde NodeJS con JavaScript basado en promesas](https://willem.com/global/images/d214aa5c60ef.webp) Igual que con mis otros servidores de backend, elegí implementarlo en NodeJS (https://nodejs.org/en/). Funciona en prácticamente cualquier cosa, desde una diminuta Raspberry PI hasta grandes nubes de computación. También puedes usar PHP (https://github.com/mollie/mollie-api-php), Ruby (https://github.com/mollie/mollie-api-ruby), Python (https://github.com/mollie/mollie-api-python) o cualquiera de los otros paquetes disponibles (https://www.mollie.com/en/developers/packages). La_referencia_de_la_API_de_Mollie (https://docs.mollie.com/reference/v2/payments-api/create-payment) 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. ![Gestión de las actualizaciones del estado del pago](https://willem.com/global/images/79791152064c.webp) 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. ![Conectar el frontend con el backend, tan fácil como 1-2-3](https://willem.com/global/images/acc0ecf42914.webp) 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é! ![A tomar café](https://willem.com/global/images/487f0979a7e9.webp) ## 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í ⬇️