Posso te ajudar, com isso se quiser. Pode me mandar um email (se quiser discutir mais a ideia de forma mais aprofundada e tals). Enfim, eu gosto de atuar em projetos assim.
Mas indo direto ao ponto, o Gateway fica no "Back".
Com as tecnologias que temos hoje em dia, como NextJS, Remix, e outras, o próprio FrontEnd está se tornando um estilo de "Back". Isso porque muitas empresas e pessoas estão adotando algo chamado Server Side Rendering, ou seja, fazer renderização de componentes do lado do servidor para entregar uma UX melhor. Ou seja, se você quisesse, daria pra fazer tudo isso junto em um único serviço (monolito).
Toda decisão arquiterural tem os seus trade-offs. Basicamente, não existe bala de prata. O mais importante é sempre fazer funcionar. Mas quando pensamos em fazer algo decente, legal, performático e escalável, devemos nos ater a detalhes e buscar soluções que sejam mais adequadas para resolver os problemas.
Então, nesse caso, você poderia seguir o caminho de separar aquilo que é front e o back. Dai no back, você poderia focar em usar tecnologias que tenham:
-
Velocidade (um gateway lida com muitas requisições por segundo) -> isso leva a adotar funções assíncronas, linguagens compiladas (Rust, C, C++, ou Go seriam excelentes escolhas) aqui;
-
Assincronicidade (pesquisa o que é);
-
Paralelismo (Rust ganha mais força aqui);
-
Segurança (Rust de novo);
.
.
.
(Continua)
Ou seja, fazer uma aplicação como o Stripe é bem complexo. Pra um projeto que não quer efetivamente ser um Gateway de pagamentos, fazer gateway para atender o seu problema não é o melhor dos caminhos. Você vai gastar muito menos tempo se simplesmente usar outras soluções existentes. Com isso você ganha tempo pra focar no principal do seu produto.
Se você começar a focar em problemas secundários não o problema central que você quer resolver, a consequecência é que você vai toda hora se esbarrar em problemas maiores que alguma outra empresa já resolveu bem.
No seu caso, você pode 1: tentar buscar por uma solução open source que já resolve o problema e partir dela. Ou então 2: de fato tentar contruir isso do zero. Ou por último, (a melhor opção na minha visão), 3: usar uma solução já pronta (procurar a mais barata e que não tenha cobrança sem uso, com isso você não vai gastar nada no começo - poderia ser o próprio Stripe), integrar isso no seu sistema e focar no principal da sua aplicação.
Depois que você conseguir validar que o seu produto de fato resolve a dor principal que a qual se propõem, dai sim, você pode tentar buscar melhorias e fazer por conta própria o Gateway da aplicação. Nessa parte, você deveria estar focando em já conseguir ganhar algum dinheiro com o projeto. Passando dessa fase, você validou que o projeto tem potencial, dai você investe mais tempo pra melhorar ele como disse.
É isso, se quiser, manda um email e falamos mais. Flws.