paint-brush
Как мы создали дебетовую карту с нуля всего за 4 месяцак@danielishigami
1,170 чтения
1,170 чтения

Как мы создали дебетовую карту с нуля всего за 4 месяца

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

Слишком долго; Читать

Я раскрою секреты создания дебетовой карты с нуля всего за 4 месяца! От навигации по сложной экосистеме финансовых технологий до выбора идеальных партнеров — я расскажу о стратегиях, задачах и идеях. Погрузитесь в технологический стек, познакомьтесь с процессом интеграции API и узнайте, как мы использовали такие инструменты, как Java Spring Boot, React и Cloudflare, чтобы воплотить эту идею в жизнь.
featured image - Как мы создали дебетовую карту с нуля всего за 4 месяца
Daniel Ishigami  HackerNoon profile picture
0-item

Всего за четыре коротких месяца мы развернули амбициозный путь от концепции к реальности, когда мы приступили к созданию уникального решения для дебетовых карт. Это статья, которую мы хотели бы прочитать!


Я Дэниел Исигами, разработчик-самоучка и предприниматель из Лондона и соучредитель Fana. Вместе с моим партнером Робином Яном мы запустили дебетовую карту, которая превращает повседневные расходы в акт благотворительности. Fana была основана, чтобы изменить способ, которым люди вносят свой вклад в дела, которые им небезразличны, предоставляя возможность воздействия посредством регулярных покупок, тем самым позволяя отдельным лицам, авторам и брендам выделять средства на значимые цели.


Беспокоило ли вас когда-нибудь, когда вас просили сделать пожертвование в благотворительные фонды или согласиться на сборы новостей по причинам, которые вы не идентифицируете, когда тратите деньги?


Мы основали Fana, потому что живем в поколении, одержимом положительным влиянием. Поколения Y, Z и A в совокупности представляют собой крупнейшую растущую потребительскую группу, и их расходы составляют 60% онлайн-продаж. Опыт благотворительности и пожертвований в настоящее время просто не соответствует ни этим намерениям, ни структуре расходов. Мы хотели создать настоящую карту, которую потребители могли бы зарегистрировать и использовать для оплаты, а затем дать им возможность делать пожертвования в благотворительную организацию Fana в приложении и делать покупки у бренда, который возвращает пользователю вознаграждение за пожертвование, чтобы оказать большее влияние.


Эта статья представляет собой глубокое погружение в тонкости разработки дебетовой карты с нуля и охватывает все этапы — от начальной стадии разработки концепции до окончательного запуска. Мы поделимся ценной информацией о нашем процессе отбора, системе оценки и стратегических решениях, которые проложили путь к нашему успеху. Вы получите эксклюзивную информацию о нашем цикле разработки, в том числе о проблемах, с которыми мы столкнулись, и о том, как мы их преодолели, а также предложим подробное руководство для всех, кто хочет отправиться в аналогичный путь.


Идея этого амбициозного проекта заключалась в том, чтобы заполнить пробел на рынке, с которым я, как потребитель и донор, столкнулся лично. Существует огромное сообщество людей, стремящихся поддержать значимые дела и оказать положительное влияние, однако они часто оказываются в растерянности, сдерживаемые устаревшими процессами пожертвований, кульминацией которых являются неудовлетворительные благодарности. Точно так же многие бренды стремятся внести свой вклад в общественное благо, однако эти похвальные усилия часто остаются незамеченными, похороненными в сносках ежегодных отчетов об устойчивом развитии. Нашей целью было создать первый этап платформы, которая органично объединила бы потребителей и бренды в их стремлении изменить ситуацию.



Присоединяйтесь к нам, чтобы мы раскрыли этапы нашего процесса разработки, поделимся инструментами и технологиями, которые сделали все это возможным, и обсудим уроки, извлеченные на этом пути. Независимо от того, являетесь ли вы начинающим предпринимателем, опытным разработчиком или просто интересуетесь инновациями в области финансовых технологий, эта статья проведет вас через путь к созданию дебетовой карты.


Процесс отбора: головоломка из 100 частей. Путешествуя по сложному ландшафту экосистемы встроенных финансов, мы начали свой путь, начиная с нуля, в области, населенной почти сотней поставщиков, многие из которых специализируются на выполнении только одной задачи, критической для работа дебетовой карты. Отсутствие общедоступной информации нас не остановило; вместо этого мы начали с нуля, налаживая контакты и участвуя в обсуждениях с различными игроками экосистемы, с которыми мы могли бы связаться (группы Slack — ваши друзья). Эти первоначальные разговоры постепенно прояснили тонкости встроенного финансирования, раскрыв основные компоненты, необходимые для воплощения нашего видения в жизнь:


  • Лицензиат EMI и спонсор BIN: ключевой игрок, регулируемый Управлением по финансовому надзору (FCA), отвечающий за хранение средств, внесенных вашими клиентами.
  • Мониторинг KYC и AML: выпуск платежного инструмента, такого как дебетовая карта, требует надежного процесса «Знай своего клиента» (KYC) для привлечения клиентов. Кроме того, постоянный мониторинг борьбы с отмыванием денег (AML) имеет решающее значение для обеспечения соблюдения нормативных стандартов.
  • Обработка платежей: Поставщик, способный обрабатывать транзакции по счетам и картам для ваших клиентов, необходим для бесперебойной работы службы. Производство карт. Если вы решите выпустить физические карты, для их производства потребуется лицензированный производитель.
  • Управление карточной программой: для успешного выпуска карточной программы необходима координация с членом сети EMV.


Для тех, кто заинтересован в более глубоком погружении в спектр эмитентов и их возможности, здесь доступен подробный обзор ( https://docsend.com/view/uia26zpnucyvgxqa ).




Наша оценка при выборе подходящего партнера была сосредоточена на:


  1. Возможность выступать в качестве готового решения для вышеуказанных компонентов. Поскольку интеграция 3 или 4 поставщиков для вышеуказанных целей приведет к увеличению накладных расходов и времени выхода на рынок, имеет смысл изначально остановиться на одном поставщике, даже если это устранит некоторый контроль над компонентами.

  2. Прозрачность их технической документации и наличие песочницы («попробуй, прежде чем купить»), которая была жизненно важна для тестирования и экспериментов с интеграцией, учитывая, что теперь мы будем строить основную часть нашего продукта на основе их API.

  3. Экономическая эффективность и масштабируемость, которые мы определили с помощью моделирования затрат на период 3–5 лет для различных коммерческих сценариев. Крайне важно, чтобы выбранный нами партнер предлагал не только конкурентоспособные цены, но и модель ценообразования, поддерживающую масштабирование, способную адаптироваться к нашему росту и изменяющимся объемам операций.




  1. Отзывчивость и скорость выполнения. На старте гибкость и быстрота выполнения неоценимы. Мы оценивали потенциальных партнеров по оперативности и скорости исполнения. Способность команды поставщика быстро назначать встречи, отвечать на запросы и продвигать проекты вперед была важнейшим показателем их соответствия нашим динамичным потребностям.


В конечном итоге мы остановились на weavr https://www.weavr.io/, поскольку они соответствовали всем вышеперечисленным критериям. Они предложили всю цепочку поставок для доставки нашего карточного продукта, поняли и могли двигаться в темпе стартапа, имели песочницу, которая позволила нам провести достаточное тестирование и обрести уверенность в способности интегрироваться с их API, и, наконец, имели коммерческую модель, которая разрешено масштабирование.


Планирование: Цель без плана — это всего лишь желание.

Параллельно с описанным выше процессом мы создали карту функций и набор пользовательских историй, которые послужили основой для того, какую функциональность нам нужно было создать.





Это также можно использовать в качестве основы для обсуждения с заинтересованными сторонами в коммерческом секторе, а также с дизайнерами и разработчиками (miro — фантастический инструмент для этого https://miro.com/templates/ ). Следуя соглашению по вышеизложенному, нам пришлось выделить на диаграмме последовательности API для всех функций, таких как создание пользователя, создание учетной записи и карты. После того как эта последовательность была настроена, она была протестирована на postman (инструменте тестирования API) с помощью предоставленной полезной коллекции. В этом процессе любые ошибки могут быть устранены еще до начала процесса сборки. Параллельно с тестированием с нашим дизайнером было обсуждено краткое описание карты функций и пользовательских историй, а также последовательность, которой мы должны были придерживаться для вызовов API, и он создал демо-версию на Figma, которую команда могла изначально протестировать. Это включало в себя перед реализацией A/B-тестирование, которое можно было проводить на пользователях: проходимость/неудачность определялась по степени выполнения и проверке с помощью типовой формы, ссылку на которую мы давали в конце демонстрационных экранов.


Пока вышеописанное выполнялось на стороне разработчиков, мы решили начать с веб-версии, которая позволит нам быстрее выполнять итерации, учитывая, что распространение через торговые площадки Apple и Google часто подвергается множественным процессам проверки, которые могут легко добавить 1 месяц+ к графику публикации. . Мы чувствовали, что было бы лучше выпустить продукт настолько быстро, насколько это возможно, и провести итерацию, прежде чем приступить к выпуску мобильной версии.


Выполнение: выполнение, выполнение, выполнение. Чтобы доставить конечный продукт, мы настроили нашу инфраструктуру следующим образом:



Наша внутренняя служба Instant использует Java Spring Boot — выбор, основанный на надежной экосистеме Spring Boot, простоте разработки и эффективности производительности (сотни полезных зависимостей доступны «из коробки» через инициализатор Spring https://start.spring.io/ ). . Этот микросервис является основой нашего приложения, обрабатывая все немедленные, управляемые событиями действия, которые имеют решающее значение для бесперебойной работы пользователя (например, регистрация, вход в систему, управление сеансами, все операции с картами). Хотя мы используем аспекты шаблона проектирования Модель-Представление-Контроллер (MVC), уделяя особое внимание моделям и контроллерам, наша архитектура в первую очередь предназначена для создания сервисов API. Такой подход позволяет нам эффективно разделить нашу бизнес-логику и процессы обработки запросов, обеспечивая чистую и удобную в сопровождении организацию кода.


Это сервис, который объединяет несколько внешних API, и, что наиболее важно, нашего поставщика встроенных финансов, а также другие важные компоненты, такие как Stripe для выставления счетов и Sendgrid для мгновенных уведомлений.


Наш серверный планировщик распределенных задач — это служба, предназначенная для управления периодическими задачами. Этот компонент играет ключевую роль в обеспечении надежности и своевременности фоновых операций, включая уведомления, учет и финансовую сверку, а также, при необходимости, опрос данных от внешних поставщиков. Он поддерживает различные типы триггеров, включая триггеры cron, ручные триггеры и триггеры на основе событий, обеспечивая гибкость в том, как и когда выполняются задачи.


Интерфейс нашего веб-приложения создан на основе React с упором на удобство для мобильных пользователей. Насколько это было возможно, мы использовали готовые к использованию компоненты, которые отлично смотрятся как на настольных компьютерах, так и на мобильных устройствах, поэтому мы могли уменьшить потребность в настраиваемых анимациях и обеспечить быстроту реагирования «из коробки».


Для мониторинга и наблюдения в нашей системе мы интегрировали Spring Boot с библиотекой, специально разработанной для предоставления метрик Prometheus (Prometheus — это набор инструментов для мониторинга и оповещения систем с открытым исходным кодом, изначально созданный в SoundCloud), которые затем используются Grafana для мониторинга и цели визуализации. Эта установка, подключенная к доступной только для чтения копии нашей производственной базы данных, дает нам важную информацию, необходимую для отслеживания ошибок и сбоев в производстве, поведения пользователей и вещей, которые могут работать не так, как предполагалось, а также отслеживания конверсий/воронки. Это позволяет нам создавать и визуализировать дополнительные запросы по требованию. В сочетании с Google Analytics этот подход предлагает комплексное представление о взаимодействии пользователей на каждом этапе. Кроме того, мы используем надежные возможности ведения журналов нашего поставщика облачных услуг для детального отслеживания ошибок.


В управлении нашей системой доменных имен (DNS), которая жизненно важна для настройки различных клиентов услуг, от платформ электронного маркетинга до инструментов аналитики, мы полагаемся на Cloudflare. Cloudflare не только служит нашей системой управления DNS, но также функционирует как наша основная сеть доставки контента (CDN). Эта двойная роль имеет решающее значение для нашей деятельности, поскольку она гарантирует, что наши цифровые активы, включая изображения и видеофайлы, будут эффективно храниться и распространяться по всему миру. Использование Cloudflare повышает производительность и безопасность нашего веб-сайта, обеспечивая быструю загрузку и надежную защиту от киберугроз. Эта настройка способствует обеспечению беспрепятственного доступа к нашему контенту, обеспечению оптимального взаимодействия с пользователем и защите пользовательских данных, тем самым поддерживая нашу комплексную онлайн-стратегию.


Заключение Для наших маркетинговых стратегий, особенно когда дело касалось A/B-тестирования для оптимизации генерации трафика и оценки эффективности различных кампаний, мы выбрали Webflow в качестве основного инструмента для проектирования и разработки наших целевых и маркетинговых страниц. Эта платформа позволила нам быстро работать над дизайном и контентом, позволяя вносить корректировки в режиме реального времени на основе результатов тестирования. Удобный интерфейс и мощные функции Webflow помогли нашей команде создать визуально привлекательные и высокопроизводительные страницы, необходимые для привлечения нашей целевой аудитории и достижения наших маркетинговых целей.


Когда мы завершаем наш путь от концепции до запуска нашего уникального решения для дебетовых карт, становится очевидным, что этот путь был одновременно трудным и плодотворным. За эти месяцы мы разобрались в сложностях финтех-экосистемы, взаимодействовали с множеством поставщиков и собрали воедино компоненты, необходимые для воплощения нашего видения в жизнь. Мы надеемся, что идеи, изложенные в этой статье, от первоначального процесса проверки до стратегического развертывания таких технологий, как Java Spring Boot, React и Cloudflare, помогут всем, кто хочет внедрить финансовые сервисы, и уменьшат некоторые препятствия, с которыми мы столкнулись на этом пути.


Размышляя о нашем пути, главный вывод заключается в том, что создание такого финтех-решения, как наше, — это больше, чем просто техническая задача; это целенаправленная попытка улучшить наш вклад в жизнь общества посредством повседневных транзакций. Двигаясь вперед, мы рады опираться на эту основу, постоянно улучшать наши предложения и расширять влияние нашей работы.


Узнайте больше о Фане: https://www.fanaverse.io/