paint-brush
Cómo creamos una tarjeta de débito desde cero en solo 4 mesespor@danielishigami
584 lecturas
584 lecturas

Cómo creamos una tarjeta de débito desde cero en solo 4 meses

por Daniel Ishigami 9m2024/04/25
Read on Terminal Reader

Demasiado Largo; Para Leer

¡Revelaré los secretos detrás de crear una tarjeta de débito desde cero en solo 4 meses! Desde navegar por el complejo ecosistema fintech hasta seleccionar los socios perfectos, analizaré estrategias, desafíos e ideas. Sumérjase en la pila tecnológica, descubra el proceso de integración de API y explore cómo utilizamos herramientas como Java Spring Boot, React y Cloudflare para hacer realidad la visión.
featured image - Cómo creamos una tarjeta de débito desde cero en solo 4 meses
Daniel Ishigami  HackerNoon profile picture
0-item

En tan solo cuatro meses, se desarrolló un ambicioso viaje desde el concepto a la realidad cuando nos embarcamos en la creación de una solución de tarjeta de débito única. ¡Este es el artículo que desearíamos haber leído!


Soy Daniel Ishigami, un desarrollador y emprendedor autodidacta radicado en Londres y cofundador de Fana. Junto con mi socio Robin Yan, lanzamos una tarjeta de débito que transforma el gasto cotidiano en un acto de filantropía. Fana se fundó para cambiar la forma en que las personas contribuyen a las causas que les importan, permitiendo el impacto a través de compras regulares, permitiendo así a las personas, los creadores y las marcas asignar fondos a causas significativas.


¿Alguna vez le ha molestado que le pidan donar para recaudar fondos o aceptar redadas para causas con las que no se identifica cuando está gastando dinero?


Fundamos Fana porque vivimos en una generación obsesionada con el impacto positivo. Las generaciones Y, Z y A son en conjunto el grupo demográfico de consumidores de mayor crecimiento y su gasto representa el 60% de las ventas en línea. La experiencia de caridad y donaciones actualmente simplemente no coincide con esta intención ni patrón de gasto. Queríamos crear una tarjeta real en la que los consumidores pudieran registrarse y pagar, permitiéndoles posteriormente donar a una organización benéfica de Fana en la aplicación y comprar en una marca que devuelva recompensas por donaciones al usuario para crear un mayor impacto.


Este artículo profundiza en las complejidades del desarrollo de una tarjeta de débito desde cero y cubre todo, desde la fase de concepto inicial hasta el lanzamiento final. Compartiremos información valiosa sobre nuestro proceso de selección, marco de evaluación y las decisiones estratégicas que allanaron el camino para nuestro éxito. Obtendrá una visión exclusiva de nuestro ciclo de desarrollo, incluidos los desafíos que enfrentamos y cómo los superamos, ofreciendo una guía completa para cualquiera que desee embarcarse en un viaje similar.


La visión detrás de este ambicioso proyecto era cerrar una brecha en el mercado que yo, como consumidor y donante, había experimentado personalmente. Existe una vasta comunidad de personas deseosas de apoyar causas significativas y lograr un impacto positivo, pero a menudo se encuentran perdidas, disuadidas por procesos de donación obsoletos que culminan en reconocimientos insatisfactorios. De manera similar, numerosas marcas aspiran a contribuir al bien social, pero estos esfuerzos encomiables frecuentemente pasan desapercibidos, enterrados en las notas a pie de página de los informes anuales de sostenibilidad. Nuestro objetivo era ser pioneros en la primera fase de una plataforma que uniera perfectamente a los consumidores y las marcas en su búsqueda por marcar la diferencia.



Únase a nosotros mientras desentrañamos las capas de nuestro proceso de desarrollo, compartimos las herramientas y tecnologías que lo hicieron posible y discutimos las lecciones aprendidas a lo largo del camino. Si es un emprendedor en ciernes, un desarrollador experimentado o simplemente siente curiosidad por la innovación en tecnología financiera, este artículo lo transporta a través del camino hacia la creación de una tarjeta de débito.


El proceso de selección: un rompecabezas de 100 piezas Navegando por el complejo panorama del ecosistema financiero integrado, nos embarcamos en nuestro viaje desde el punto de partida en un campo poblado por casi cien proveedores, muchos de los cuales se especializan en realizar una sola tarea crítica para el funcionamiento de una tarjeta de débito. La falta de información disponible públicamente no nos disuadió; en cambio, comenzamos desde cero, contactando y participando en debates con diferentes actores del ecosistema con los que podíamos conectarnos (los grupos de Slack son tus amigos). Estas conversaciones iniciales desmitificaron gradualmente las complejidades de las finanzas integradas y revelaron los componentes esenciales necesarios para hacer realidad nuestra visión:


  • Licenciatario de EMI y patrocinador de BIN: un actor clave regulado por la Autoridad de Conducta Financiera (FCA), responsable de retener los fondos depositados por sus clientes.
  • Monitoreo KYC y AML: la emisión de un instrumento de pago como una tarjeta de débito requiere un proceso sólido de "Conozca a su cliente" (KYC) para incorporar a los clientes. Además, el monitoreo continuo contra el lavado de dinero (AML) es crucial para garantizar el cumplimiento de los estándares regulatorios.
  • Procesamiento de pagos: un proveedor capaz de manejar las transacciones de cuentas y tarjetas de sus clientes es esencial para el buen funcionamiento del servicio. Fabricación de tarjetas: si opta por emitir tarjetas físicas, se requiere que un fabricante autorizado las produzca.
  • Gestión del programa de tarjetas: Es necesaria la coordinación con un miembro de la red EMV para emitir un programa de tarjetas con éxito.


Para aquellos interesados en profundizar en el espectro de emisores y sus capacidades, hay disponible una descripción general completa aquí ( https://docsend.com/view/uia26zpnucyvgxqa ).




Nuestra evaluación para seleccionar el socio adecuado se centró en:


  1. Capacidad para actuar como una solución llave en mano para los componentes anteriores. Dado que la integración de 3 o 4 proveedores para lo anterior aumentará los gastos generales y el tiempo de comercialización, tiene sentido decidirse inicialmente por un proveedor incluso si elimina cierto control sobre los componentes.

  2. Transparencia de su documentación técnica y disponibilidad de una zona de pruebas (“pruébelo antes de comprar”), lo cual fue vital para probar y experimentar con la integración dado que ahora construiríamos una pieza central de nuestro producto sobre los cimientos de su API.

  3. Rentabilidad y escalabilidad que determinamos mediante modelos de costos durante un período de 3 a 5 años para una variedad de escenarios comerciales. Era imperativo que nuestro socio elegido no solo ofreciera precios competitivos sino también un modelo de precios que respaldara la escalabilidad, capaz de adaptarse a nuestro crecimiento y a los diferentes volúmenes operativos.




  1. Capacidad de respuesta y velocidad de ejecución. Como empresa nueva, la agilidad y la rápida ejecución son invaluables. Evaluamos a los socios potenciales en función de su capacidad de respuesta y la velocidad de su ejecución. La capacidad del equipo de un proveedor para organizar reuniones rápidamente, responder consultas y hacer avanzar los proyectos fue un indicador crítico de su alineación con nuestras necesidades dinámicas.


Finalmente llegamos a weavr https://www.weavr.io/ ya que cumplían con todos los criterios anteriores. Ofrecieron toda la cadena de suministro para entregar nuestro producto de tarjeta, entendían y podían avanzar al ritmo de una startup, tenían una zona de pruebas que nos permitía probar lo suficiente y ganar confianza en la capacidad de integrarnos con su API y, por último, tenían un modelo comercial que permitido para escalar.


Planificación: una meta sin un plan es solo un deseo

En paralelo al proceso anterior, creamos un mapa de características y un conjunto de historias de usuarios que sirvieron como base para la funcionalidad que necesitábamos crear.





Esto también podría usarse como base de discusión con partes interesadas comerciales, así como con diseñadores y desarrolladores (miro es una herramienta fantástica para esto https://miro.com/templates/ ). Tras un acuerdo sobre lo anterior, tuvimos que analizar las secuencias API en un diagrama para todas las funciones, como crear un usuario, crear una cuenta y una tarjeta. Una vez que se configuró esta secuencia, se probó en postman (una herramienta de prueba de API) a través de una colección útil que estuvo disponible. En este proceso, cualquier error ya se puede solucionar antes del proceso de compilación. Paralelamente a las pruebas, nuestro diseñador discutió un resumen del mapa de características e historias de usuarios junto con la secuencia que teníamos que seguir para las llamadas API y creó una versión de demostración en Figma que el equipo pudo probar inicialmente. Esto incluía, antes de la implementación, una prueba A/B que se podía realizar en los usuarios: la aprobación/rechazo se determinaba mediante la tasa de finalización y la revisión a través del formulario que vinculamos al final de las pantallas de demostración.


Mientras lo anterior se realizaba por parte del desarrollador, decidimos comenzar con una versión web que nos permitiría iterar más rápidamente dado que la distribución a través de los mercados de Apple y Google a menudo está sujeta a múltiples procesos de revisión que pueden agregar fácilmente 1 mes o más a una línea de tiempo de publicación. . Sentimos que sería mejor entregar lo más rápido que pudiéramos e iterar antes de comprometernos con una versión móvil.


Ejecución: Ejecutar, Ejecutar, Ejecutar Para entregar el producto final configuramos nuestra infraestructura de la siguiente manera:



Nuestro servicio instantáneo de backend utiliza Java Spring Boot, una opción impulsada por el sólido ecosistema, la facilidad de desarrollo y la eficiencia del rendimiento de Spring Boot (cientos de dependencias útiles disponibles listas para usar a través del inicializador de Spring https://start.spring.io/ ). . Este microservicio es la columna vertebral de nuestra aplicación y maneja todas las acciones inmediatas basadas en eventos que son fundamentales para una experiencia de usuario perfecta (por ejemplo, registro, inicio de sesión, administración de sesiones, todas las operaciones con tarjetas). Si bien empleamos aspectos del patrón de diseño Modelo-Vista-Controlador (MVC), centrándonos específicamente en Modelos y Controladores, nuestra arquitectura está diseñada principalmente para crear servicios API. Este enfoque nos permite separar eficazmente nuestra lógica de negocios y los procesos de manejo de solicitudes, garantizando una organización de código limpia y fácil de mantener.


Este es el servicio que integra múltiples API externas y, lo más importante, las de nuestro proveedor de finanzas integrado, así como otros componentes críticos como Stripe para facturación y Sendgrid para notificaciones instantáneas.


Nuestro Programador de tareas distribuidas backend es un servicio diseñado para gestionar tareas periódicas. Este componente desempeña un papel fundamental para garantizar la confiabilidad y puntualidad de las operaciones en segundo plano, desde notificaciones, conciliación contable y financiera, así como, cuando sea necesario, sondeo de datos de proveedores externos. Admite varios tipos de activadores, incluidos activadores cron, manuales y basados en eventos, lo que proporciona flexibilidad sobre cómo y cuándo se ejecutan las tareas.


El front-end de nuestra aplicación web está construido con React, con un enfoque en ser fácil de usar para dispositivos móviles. En la medida de lo posible, utilizamos componentes listos para usar que se ven geniales tanto en computadoras de escritorio como en dispositivos móviles para poder reducir la necesidad de animaciones personalizadas y tener capacidad de respuesta lista para usar.


Para el monitoreo y la observabilidad en nuestro sistema, hemos integrado Spring Boot con una biblioteca diseñada específicamente para exponer las métricas de Prometheus (Prometheus es un conjunto de herramientas de alerta y monitoreo de sistemas de código abierto creado originalmente en SoundCloud), que luego son consumidas por Grafana para monitoreo y fines de visualización. Esta configuración, conectada a una réplica de solo lectura de nuestra base de datos de producción, nos brinda información crítica necesaria para rastrear errores y fallas en producción, el comportamiento del usuario y las cosas que pueden no funcionar tan bien como se esperaba, y el seguimiento de la conversión/embudo. Nos permite elaborar y visualizar consultas adicionales a pedido. Junto con Google Analytics, este enfoque ofrece una visión integral de las interacciones del usuario en cada momento. Además, utilizamos las sólidas capacidades de registro de nuestro proveedor de servicios en la nube para un seguimiento detallado de los errores.


A la hora de gestionar nuestro sistema de nombres de dominio (DNS), que es vital para configurar diversos clientes de servicios que van desde plataformas de marketing por correo electrónico hasta herramientas de análisis, confiamos en Cloudflare. Cloudflare no solo sirve como nuestro sistema de administración de DNS, sino que también funciona como nuestra red principal de entrega de contenido (CDN). Esta doble función es crucial para nuestra operación, ya que garantiza que nuestros activos digitales, incluidos archivos de imágenes y videos, se almacenen y distribuyan de manera eficiente en todo el mundo. El uso de Cloudflare mejora el rendimiento y la seguridad de nuestro sitio web, ofreciendo tiempos de carga rápidos y una protección sólida contra amenazas cibernéticas. Esta configuración es fundamental para mantener un acceso fluido a nuestro contenido, facilitar una experiencia de usuario óptima y proteger los datos del usuario, respaldando así nuestra estrategia integral en línea.


Conclusión Para nuestras estrategias de marketing, particularmente cuando se trataba de pruebas A/B para optimizar la generación de tráfico y evaluar la efectividad de varias campañas, elegimos Webflow como nuestra herramienta principal para diseñar y desarrollar nuestras páginas de destino y de marketing. Esta plataforma nos permitió iterar rápidamente el diseño y el contenido, lo que permitió realizar ajustes en tiempo real basados en los resultados de las pruebas. La interfaz fácil de usar y las potentes funciones de Webflow ayudaron a nuestro equipo a crear páginas visualmente atractivas y de alto rendimiento, esenciales para atraer a nuestro público objetivo e impulsar nuestros objetivos de marketing.


Al concluir nuestro recorrido desde el concepto hasta el lanzamiento de nuestra exclusiva solución de tarjeta de débito, es evidente que el camino fue a la vez desafiante y gratificante. Durante estos meses, navegamos por las complejidades del ecosistema fintech, interactuamos con innumerables proveedores y reunimos los componentes necesarios para hacer realidad nuestra visión. Se espera que los conocimientos compartidos en este artículo, desde el proceso de selección inicial hasta la implementación estratégica de tecnologías como Java Spring Boot, React y Cloudflare, ayuden a cualquiera que busque integrar servicios financieros y reducir algunos de los obstáculos que encontramos en el camino.


Al reflexionar sobre nuestro viaje, la conclusión clave es que crear una solución fintech como la nuestra es más que un simple esfuerzo técnico; es un esfuerzo impulsado por la misión de mejorar la forma en que contribuimos a la sociedad a través de las transacciones cotidianas. A medida que avanzamos, nos entusiasma poder construir sobre esta base, mejorar continuamente nuestra oferta y ampliar el impacto de nuestro trabajo.


Obtenga más información sobre Fana: https://www.fanaverse.io/