How We Built a Debit Card From Scratch in Only 4 Months

In just four short months, an ambitious journey from concept to reality unfolded as we embarked on the creation of a unique debit card solution. This is the article we wish we’d read! I'm Daniel Ishigami, a self-taught developer and entrepreneur based in London, and the co-founder of Fana. Along with my partner Robin Yan, we've launched a debit card that transforms everyday spending into an act of philanthropy. Fana was founded to change the way that people contribute to causes they care about, by enabling impact through regular purchases, thereby allowing individuals, creators and brands to allocate funds towards meaningful causes. Has it ever bothered you being asked to donate to collection pots or agree to roundups for causes you don’t identify with when you’re spending money? We founded Fana because we live in a generation obsessed with positive impact. Gen Y, Z and A are collectively the largest growing consumer demographic and their spending comprises 60% of online sales. The charity and giving experience currently just doesn’t match this spending intent, nor pattern. We wanted to create an actual card that consumers can sign up to and pay with, subsequently then enabling them to donate to a Fana charity in-app, and shop at a brand that gives donation rewards back to the user to create more impact. This article is a deep dive into the intricacies of developing a debit card from scratch, covering everything from the initial concept phase to the final launch. We'll share valuable insights into our screening process, evaluation framework, and the strategic decisions that paved the way for our success. You'll get an exclusive look at our development cycle, including the challenges we faced and how we overcame them, offering a comprehensive guide for anyone looking to embark on a similar journey. The vision behind this ambitious project was to bridge a gap in the market that I, as both a consumer and a donor, had personally experienced. There exists a vast community of individuals eager to support meaningful causes and make a positive impact, yet they often find themselves at a loss, deterred by outdated donation processes that culminate in unsatisfying acknowledgments. Similarly, numerous brands aspire to contribute to societal good, yet these commendable efforts frequently go unnoticed, buried in the footnotes of annual sustainability reports. Our goal was to pioneer the first phase of a platform that seamlessly united consumers and brands in their quest to make a difference. Join us as we unravel the layers of our development process, share the tools and technologies that made it all possible, and discuss the lessons learned along the way. Whether you're a budding entrepreneur, a seasoned developer, or simply curious about fintech innovation, this article transports you through the journey to the creation of a debit card. The Screening Process: A 100 piece puzzle Navigating the complex landscape of the embedded finance ecosystem, we embarked on our journey starting from square one in a field populated by nearly a hundred providers, many of which specialize in performing just a single task critical for the operation of a debit card. The lack of publicly available information did not deter us; instead, we started from scratch, reaching out and engaging in discussions with different players in the ecosystem we could connect with (Slack groups are your friend). These initial conversations gradually demystified the intricacies of embedded finance, revealing the essential components required to bring our vision to life: EMI Licensee & BIN Sponsor: A key player regulated by the Financial Conduct Authority (FCA), responsible for holding the funds deposited by your customers. KYC & AML Monitoring: Issuing a payment instrument like a debit card necessitates a robust 'Know Your Customer' (KYC) process to onboard customers. Additionally, ongoing Anti-Money Laundering (AML) monitoring is crucial to ensure compliance with regulatory standards. Payment Processing: A provider capable of handling account and card transactions for your customers is essential for the smooth operation of the service. Card Manufacturing: Should you opt for issuing physical cards, a licensed manufacturer is required to produce them. Card Program Management: Coordination with a member of the EMV network is necessary to issue a card program successfully. For those interested in a deeper dive into the spectrum of issuers and their capabilities, a comprehensive overview is available here (https://docsend.com/view/uia26zpnucyvgxqa ). Our evaluation to select the right partner then focused on: Ability to act as a turnkey solution for above components. Since integrating 3 or 4 providers for the above will increase overhead and time to market it makes sense to initially settle on one provider even if it removes some control over components. Transparency of their technical documentation and availability of a sandbox (“try before you buy”) which was vital to test and experiment with the integration given that we would now build a core piece of our product on the foundations of their API. Cost-effectiveness and scalability which we determined via cost modelled out over a 3-5 year period for a variety of commercial scenarios. It was imperative that our chosen partner not only offered competitive pricing but also a pricing model that supported scaling — capable of adapting to our growth and varying operational volumes. Responsiveness and execution speed. As a start-up, agility and quick execution are invaluable. We evaluated potential partners on their responsiveness and the speed of their execution. The ability of a provider’s team to swiftly set up meetings, respond to inquiries, and move projects forward was a critical indicator of their alignment with our dynamic needs. We ultimately landed on weavr https://www.weavr.io/ since they met all the above criteria. They offered the entire supply chain to deliver our card product, understand and could move at the pace of a startup, had a sandbox that allowed us to sufficiently test and gain confidence in the ability to integrate with their API and lastly had a commercial model that allowed for scaling. Planning: A goal without a plan is just a wish In parallel to the above process we created a features map and set of user stories that served as the basis of what functionality we needed to build. This could also be used as a basis of discussion with commercial stakeholders as well as designers and developers (miro is a fantastic tool for this https://miro.com/templates/). Following an agreement on the above, we had to scope out the API sequences in a diagram for all functions such as creating a user, creating an account, and a card. Once this sequence was set up, it was tested on postman (an API testing tool) via a helpful collection that was made available. In this process, any errors can be already addressed before the build process. In parallel to testing, a brief of features map and user stories alongside the sequence we had to adhere to for API calls was discussed with our designer and he built out a demo version on Figma that could be tested by the team initially. This included before implementation an A/B test that could be performed on users - the pass/fail was determined by completion rate and review via typeform that we linked at the end of the demo screens. While the above was being performed on the developer side we decided to commence with a web version that would allow us to iterate more quickly given that distribution via Apple and Google’s marketplaces is often subject to multiple review processes that can easily add 1mo+ to a publishing timeline. We felt that itwould be better to deliver as fast as we could and to iterate before committing to a mobile release. Execution: Execute, Execute, Execute To deliver the final product we set up our infrastructure as follows: Our Backend Instant Service is using Java Spring Boot, a choice driven by Spring Boot’s robust ecosystem, ease of development, and performance efficiency (hundreds of useful dependencies available out of the box via spring initializer https://start.spring.io/). This microservice is the backbone of our application, handling all immediate, event-driven actions that are critical to a seamless user experience (e.g. signup, login, session management, all card operations). While we employ aspects of the Model-View-Controller (MVC) design pattern, specifically focusing on Models and Controllers, our architecture is primarily designed for building API services. This approach enables us to effectively separate our business logic and request handling processes, ensuring clean and maintainable code organization. This is the service that integrates multiple external APIs, and most critically those of our embedded finance provider as well as other critical components such as Stripe for billing, and Sendgrid for instant notifications. Our Backend Distributed Task Scheduler is a service designed to manage periodic tasks. This component plays a pivotal role in ensuring the reliability and timeliness of background operations, from notifications, accounting & financial reconciliation as well as where required polling of data from external providers. It supports various trigger types, including cron, manual, and event-based triggers, providing flexibility in how and when tasks are executed. Our web app's Front End is built with React, with a focus on being mobile user-friendly. As much as possible we used ready-to-use components that look great on both desktop and mobile so we could reduce the need for custom animations and have responsiveness out of the box. For monitoring and observability in our system, we've integrated Spring Boot with a library specifically designed to expose Prometheus metrics (Prometheus is an open-source systems monitoring and alerting toolkit originally built at SoundCloud), which are then consumed by Grafana for monitoring and visualization purposes. This setup, connected to a read-only replica of our production database, empowers us with critical insights needed to track errors and bugs in production, user behaviour and things that may not work as well as intended, and tracking of conversion/funnel. It enables us to craft and visualize additional queries on demand. Coupled with Google Analytics, this approach offers a comprehensive view of user interactions at every juncture. Furthermore, we utilize our cloud service provider's robust logging capabilities for detailed error tracking. In managing our domain name system (DNS), which is vital for configuring various service clients ranging from email marketing platforms to analytics tools, we rely on Cloudflare. Cloudflare not only serves as our DNS management system but also functions as our primary content delivery network (CDN). This dual role is crucial for our operation, as it ensures that our digital assets, including images and video files, are stored and distributed efficiently across the globe. Utilizing Cloudflare enhances our website's performance and security, offering fast loading times and robust protection against cyber threats. This setup is instrumental in maintaining seamless access to our content, facilitating an optimal user experience, and safeguarding user data, thereby supporting our comprehensive online strategy. Conclusion For our marketing strategies, particularly when it came to A/B testing to optimize traffic generation and evaluate the effectiveness of various campaigns, we chose Webflow as our primary tool for designing and developing our landing and marketing pages. This platform enabled us to swiftly iterate on design and content, allowing for real-time adjustments based on testing outcomes. Webflow's user-friendly interface and powerful features supported our team in creating visually appealing and high-performing pages, essential for engaging our target audience and driving our marketing objectives forward. As we conclude our journey from concept to the launch of our unique debit card solution, it's evident that the path was both challenging and rewarding. Over these months, we navigated the complexities of the fintech ecosystem, engaged with myriad providers, and pieced together the components necessary to bring our vision to life. The insights shared in this article, from the initial screening process to the strategic deployment of technologies like Java Spring Boot, React, and Cloudflare, will hopefully help anyone looking to embed financial services and reduce some of the hurdles we encountered along the way. Reflecting on our journey, the key takeaway is that creating a fintech solution like ours is more than just a technical endeavor; it's a mission-driven effort to enhance how we contribute to society through everyday transactions. As we move forward, we're excited to build on this foundation, continuously improve our offering, and expand the impact of our work. Find out more about Fana: https://www.fanaverse.io/ In just four short months, an ambitious journey from concept to reality unfolded as we embarked on the creation of a unique debit card solution. This is the article we wish we’d read! In just four short months, an ambitious journey from concept to reality unfolded as we embarked on the creation of a unique debit card solution. This is the article we wish we’d read! I'm Daniel Ishigami, a self-taught developer and entrepreneur based in London, and the co-founder of Fana. Along with my partner Robin Yan, we've launched a debit card that transforms everyday spending into an act of philanthropy. Fana was founded to change the way that people contribute to causes they care about, by enabling impact through regular purchases, thereby allowing individuals, creators and brands to allocate funds towards meaningful causes. Has it ever bothered you being asked to donate to collection pots or agree to roundups for causes you don’t identify with when you’re spending money? Has it ever bothered you being asked to donate to collection pots or agree to roundups for causes you don’t identify with when you’re spending money? We founded Fana because we live in a generation obsessed with positive impact. Gen Y, Z and A are collectively the largest growing consumer demographic and their spending comprises 60% of online sales. The charity and giving experience currently just doesn’t match this spending intent, nor pattern. We wanted to create an actual card that consumers can sign up to and pay with, subsequently then enabling them to donate to a Fana charity in-app, and shop at a brand that gives donation rewards back to the user to create more impact. This article is a deep dive into the intricacies of developing a debit card from scratch, covering everything from the initial concept phase to the final launch. We'll share valuable insights into our screening process, evaluation framework, and the strategic decisions that paved the way for our success. You'll get an exclusive look at our development cycle, including the challenges we faced and how we overcame them, offering a comprehensive guide for anyone looking to embark on a similar journey. The vision behind this ambitious project was to bridge a gap in the market that I, as both a consumer and a donor, had personally experienced. There exists a vast community of individuals eager to support meaningful causes and make a positive impact, yet they often find themselves at a loss, deterred by outdated donation processes that culminate in unsatisfying acknowledgments. Similarly, numerous brands aspire to contribute to societal good, yet these commendable efforts frequently go unnoticed, buried in the footnotes of annual sustainability reports. Our goal was to pioneer the first phase of a platform that seamlessly united consumers and brands in their quest to make a difference. Join us as we unravel the layers of our development process, share the tools and technologies that made it all possible, and discuss the lessons learned along the way. Whether you're a budding entrepreneur, a seasoned developer, or simply curious about fintech innovation, this article transports you through the journey to the creation of a debit card. The Screening Process: A 100 piece puzzle Navigating the complex landscape of the embedded finance ecosystem, we embarked on our journey starting from square one in a field populated by nearly a hundred providers, many of which specialize in performing just a single task critical for the operation of a debit card. The lack of publicly available information did not deter us; instead, we started from scratch, reaching out and engaging in discussions with different players in the ecosystem we could connect with (Slack groups are your friend). These initial conversations gradually demystified the intricacies of embedded finance, revealing the essential components required to bring our vision to life: The Screening Process: A 100 piece puzzle EMI Licensee & BIN Sponsor: A key player regulated by the Financial Conduct Authority (FCA), responsible for holding the funds deposited by your customers. KYC & AML Monitoring: Issuing a payment instrument like a debit card necessitates a robust 'Know Your Customer' (KYC) process to onboard customers. Additionally, ongoing Anti-Money Laundering (AML) monitoring is crucial to ensure compliance with regulatory standards. Payment Processing: A provider capable of handling account and card transactions for your customers is essential for the smooth operation of the service. Card Manufacturing: Should you opt for issuing physical cards, a licensed manufacturer is required to produce them. Card Program Management: Coordination with a member of the EMV network is necessary to issue a card program successfully. EMI Licensee & BIN Sponsor: A key player regulated by the Financial Conduct Authority (FCA), responsible for holding the funds deposited by your customers. EMI Licensee & BIN Sponsor: KYC & AML Monitoring: Issuing a payment instrument like a debit card necessitates a robust 'Know Your Customer' (KYC) process to onboard customers. Additionally, ongoing Anti-Money Laundering (AML) monitoring is crucial to ensure compliance with regulatory standards. KYC & AML Monitoring: Payment Processing: A provider capable of handling account and card transactions for your customers is essential for the smooth operation of the service. Card Manufacturing: Should you opt for issuing physical cards, a licensed manufacturer is required to produce them. Payment Processing: Card Program Management: Coordination with a member of the EMV network is necessary to issue a card program successfully. Card Program Management: For those interested in a deeper dive into the spectrum of issuers and their capabilities, a comprehensive overview is available here ( https://docsend.com/view/uia26zpnucyvgxqa ). https://docsend.com/view/uia26zpnucyvgxqa Our evaluation to select the right partner then focused on: Ability to act as a turnkey solution for above components. Since integrating 3 or 4 providers for the above will increase overhead and time to market it makes sense to initially settle on one provider even if it removes some control over components. Transparency of their technical documentation and availability of a sandbox (“try before you buy”) which was vital to test and experiment with the integration given that we would now build a core piece of our product on the foundations of their API. Cost-effectiveness and scalability which we determined via cost modelled out over a 3-5 year period for a variety of commercial scenarios. It was imperative that our chosen partner not only offered competitive pricing but also a pricing model that supported scaling — capable of adapting to our growth and varying operational volumes. Ability to act as a turnkey solution for above components. Since integrating 3 or 4 providers for the above will increase overhead and time to market it makes sense to initially settle on one provider even if it removes some control over components. Ability to act as a turnkey solution for above components. Since integrating 3 or 4 providers for the above will increase overhead and time to market it makes sense to initially settle on one provider even if it removes some control over components. Transparency of their technical documentation and availability of a sandbox (“try before you buy”) which was vital to test and experiment with the integration given that we would now build a core piece of our product on the foundations of their API. Transparency of their technical documentation and availability of a sandbox (“try before you buy”) which was vital to test and experiment with the integration given that we would now build a core piece of our product on the foundations of their API. Cost-effectiveness and scalability which we determined via cost modelled out over a 3-5 year period for a variety of commercial scenarios. It was imperative that our chosen partner not only offered competitive pricing but also a pricing model that supported scaling — capable of adapting to our growth and varying operational volumes. Cost-effectiveness and scalability which we determined via cost modelled out over a 3-5 year period for a variety of commercial scenarios. It was imperative that our chosen partner not only offered competitive pricing but also a pricing model that supported scaling — capable of adapting to our growth and varying operational volumes. Responsiveness and execution speed. As a start-up, agility and quick execution are invaluable. We evaluated potential partners on their responsiveness and the speed of their execution. The ability of a provider’s team to swiftly set up meetings, respond to inquiries, and move projects forward was a critical indicator of their alignment with our dynamic needs. Responsiveness and execution speed. As a start-up, agility and quick execution are invaluable. We evaluated potential partners on their responsiveness and the speed of their execution. The ability of a provider’s team to swiftly set up meetings, respond to inquiries, and move projects forward was a critical indicator of their alignment with our dynamic needs. We ultimately landed on weavr https://www.weavr.io/ since they met all the above criteria. They offered the entire supply chain to deliver our card product, understand and could move at the pace of a startup, had a sandbox that allowed us to sufficiently test and gain confidence in the ability to integrate with their API and lastly had a commercial model that allowed for scaling. https://www.weavr.io/ Planning: A goal without a plan is just a wish Planning: A goal without a plan is just a wish In parallel to the above process we created a features map and set of user stories that served as the basis of what functionality we needed to build. This could also be used as a basis of discussion with commercial stakeholders as well as designers and developers (miro is a fantastic tool for this https://miro.com/templates/ ). Following an agreement on the above, we had to scope out the API sequences in a diagram for all functions such as creating a user, creating an account, and a card. Once this sequence was set up, it was tested on postman (an API testing tool) via a helpful collection that was made available. In this process, any errors can be already addressed before the build process. In parallel to testing, a brief of features map and user stories alongside the sequence we had to adhere to for API calls was discussed with our designer and he built out a demo version on Figma that could be tested by the team initially. This included before implementation an A/B test that could be performed on users - the pass/fail was determined by completion rate and review via typeform that we linked at the end of the demo screens. https://miro.com/templates/ While the above was being performed on the developer side we decided to commence with a web version that would allow us to iterate more quickly given that distribution via Apple and Google’s marketplaces is often subject to multiple review processes that can easily add 1mo+ to a publishing timeline. We felt that itwould be better to deliver as fast as we could and to iterate before committing to a mobile release. Execution: Execute, Execute, Execute To deliver the final product we set up our infrastructure as follows: Execution: Execute, Execute, Execute Our Backend Instant Service is using Java Spring Boot, a choice driven by Spring Boot’s robust ecosystem, ease of development, and performance efficiency (hundreds of useful dependencies available out of the box via spring initializer https://start.spring.io/ ). This microservice is the backbone of our application, handling all immediate, event-driven actions that are critical to a seamless user experience (e.g. signup, login, session management, all card operations). While we employ aspects of the Model-View-Controller (MVC) design pattern, specifically focusing on Models and Controllers, our architecture is primarily designed for building API services. This approach enables us to effectively separate our business logic and request handling processes, ensuring clean and maintainable code organization. Backend Instant Service https://start.spring.io/ This is the service that integrates multiple external APIs, and most critically those of our embedded finance provider as well as other critical components such as Stripe for billing, and Sendgrid for instant notifications. Our Backend Distributed Task Scheduler is a service designed to manage periodic tasks. This component plays a pivotal role in ensuring the reliability and timeliness of background operations, from notifications, accounting & financial reconciliation as well as where required polling of data from external providers. It supports various trigger types, including cron, manual, and event-based triggers, providing flexibility in how and when tasks are executed. Backend Distributed Task Scheduler Our web app's Front End is built with React, with a focus on being mobile user-friendly. As much as possible we used ready-to-use components that look great on both desktop and mobile so we could reduce the need for custom animations and have responsiveness out of the box. Front End For monitoring and observability in our system, we've integrated Spring Boot with a library specifically designed to expose Prometheus metrics (Prometheus is an open-source systems monitoring and alerting toolkit originally built at SoundCloud), which are then consumed by Grafana for monitoring and visualization purposes. This setup, connected to a read-only replica of our production database, empowers us with critical insights needed to track errors and bugs in production, user behaviour and things that may not work as well as intended, and tracking of conversion/funnel. It enables us to craft and visualize additional queries on demand. Coupled with Google Analytics, this approach offers a comprehensive view of user interactions at every juncture. Furthermore, we utilize our cloud service provider's robust logging capabilities for detailed error tracking. monitoring and observability In managing our domain name system (DNS), which is vital for configuring various service clients ranging from email marketing platforms to analytics tools, we rely on Cloudflare. Cloudflare not only serves as our DNS management system but also functions as our primary content delivery network (CDN). This dual role is crucial for our operation, as it ensures that our digital assets, including images and video files, are stored and distributed efficiently across the globe. Utilizing Cloudflare enhances our website's performance and security, offering fast loading times and robust protection against cyber threats. This setup is instrumental in maintaining seamless access to our content, facilitating an optimal user experience, and safeguarding user data, thereby supporting our comprehensive online strategy. Conclusion For our marketing strategies, particularly when it came to A/B testing to optimize traffic generation and evaluate the effectiveness of various campaigns, we chose Webflow as our primary tool for designing and developing our landing and marketing pages. This platform enabled us to swiftly iterate on design and content, allowing for real-time adjustments based on testing outcomes. Webflow's user-friendly interface and powerful features supported our team in creating visually appealing and high-performing pages, essential for engaging our target audience and driving our marketing objectives forward. Conclusion As we conclude our journey from concept to the launch of our unique debit card solution, it's evident that the path was both challenging and rewarding. Over these months, we navigated the complexities of the fintech ecosystem, engaged with myriad providers, and pieced together the components necessary to bring our vision to life. The insights shared in this article, from the initial screening process to the strategic deployment of technologies like Java Spring Boot, React, and Cloudflare, will hopefully help anyone looking to embed financial services and reduce some of the hurdles we encountered along the way. Reflecting on our journey, the key takeaway is that creating a fintech solution like ours is more than just a technical endeavor; it's a mission-driven effort to enhance how we contribute to society through everyday transactions. As we move forward, we're excited to build on this foundation, continuously improve our offering, and expand the impact of our work. Find out more about Fana: https://www.fanaverse.io/ https://www.fanaverse.io/