hyperswitch-prism

O que é hyperswitch-prism?

Hyperswitch Prism é uma biblioteca de conectores unificada e stateless para integração com processadores de pagamento. Ela foi projetada para fornecer um único schema de requisição/interação, permitindo que os mesmos padrões de chamada sejam usados em múltiplos processadores de pagamento com menos alterações de código.

O Prism foi extraído e é mantido pela equipe por trás do Hyperswitch, uma plataforma de pagamentos open-source. O repositório descreve o Prism como uma camada de transformação que foca na consistência da integração de conectores, deixando preocupações como vault/tokenização, retentativas e lógica de roteamento para o Hyperswitch.

Principais Recursos

• Um único schema de requisição unificado entre conectores: A mesma chamada de authorize funciona com múltiplos processadores (ex.: Stripe, Adyen) sem linhas de código adicionais dedicadas a cada processador.
• Biblioteca stateless (sem banco de dados, sem PII armazenado): O Prism não requer banco de dados e evita armazenar dados pessoais; afirma que credenciais não são armazenadas ou logadas pela biblioteca e existem apenas durante o tempo de vida do cliente HTTP.
• Controle de escopo PCI por design: A biblioteca pode evitar que dados de cartão entrem no Prism; os dados de cartão que fluem (ou não fluem) pela biblioteca são posicionados como uma escolha, com a possibilidade de usar um vault do processador de pagamento ou um vault PCI-certificado fornecido pelo usuário.
• Testes contínuos de conectores com modelo de status publicado: Conectores são testados continuamente contra ambientes sandbox/produção reais, com uma legenda de status cobrindo estados suportado, em andamento/parcial e precisa de validação.
• Interface idiomática e multi-língua (conforme docs do repositório): O Prism é descrito como uma interface type-safe e idiomática, empacotada como SDK multi-língua.

Como Usar hyperswitch-prism

1. Selecione o SDK Prism para sua linguagem e revise o guia do SDK para autenticação e padrões de requisição.
2. Escreva requisições de pagamento usando o schema unificado do Prism (por exemplo, usando a mesma estrutura de chamada authorize em diferentes processadores de pagamento).
3. Escolha onde dados de pagamento sensíveis são manipulados: use seu próprio vault PCI-certificado ou um vault do processador de pagamento, alinhado à nota do repositório de que serviços de vault/tokenização não estão embutidos no Prism.
4. Valide a cobertura de conectores para suas necessidades usando a página de cobertura/status de conectores do projeto, já que o Prism descreve níveis variados de suporte entre conectores.

Casos de Uso

• Integração de checkout multi-processador: Você quer rotear operações de pagamento para mais de um processador mantendo alterações mínimas no código da aplicação, confiando no schema de requisição unificado do Prism.
• Reduzindo estado e dados armazenados na camada de integração: Sua equipe prefere uma camada de conectores stateless onde o Prism em si não requer banco de dados e não armazena ou loga credenciais.
• Alinhando responsabilidades PCI via escolha de vault: Você quer controlar se dados de cartão são manipulados dentro da sua infraestrutura e escolher entre um vault do processador de pagamento ou seu próprio vault PCI-certificado.
• Equipes de engenharia mantendo lógica de conectores ao longo do tempo: Você precisa de uma camada de integração de conectores testada continuamente contra sandbox/produção e rastreada com status por conector.
• Integração de camada de transformação em uma plataforma de pagamentos maior: Você usa o Prism como camada de transformação, enquanto implementa lógica de retentativas/roteamento em outro lugar (o repositório aponta para Juspay Hyperswitch para esses aspectos).

FAQ

O Prism é responsável por tentativas de repetição e lógica de roteamento?
Não. O repositório afirma que tentativas de repetição ou lógica de roteamento estão no Juspay Hyperswitch; o Prism é apresentado como uma camada de transformação.

O Prism inclui um vault ou serviço de tokenização integrado?
Não. Isso é descrito como uma escolha de design; você pode trazer seu próprio vault ou usar o vault do processador de pagamentos.

O Prism armazena credenciais ou PII?
O repositório afirma que credenciais não são armazenadas ou registradas pela biblioteca, ela é stateless sem banco de dados, e não armazena PII. Também nota que credenciais existem apenas durante o tempo de vida do seu cliente HTTP.

Como posso saber quais processadores de pagamento e métodos de pagamento são suportados?
O Prism publica a cobertura de conectores com uma legenda indicando suportado (totalmente implementado e testado), não aplicável/não suportado, em progresso/parcial, e implementação precisando de validação em ambientes reais.

Quantas chamadas de pagamento preciso implementar para múltiplos processadores?
A alegação central do repositório é que um único schema de requisição permite que a mesma chamada de authorize funcione em processadores como Stripe e Adyen sem linhas de código específicas adicionais por processador.

Alternativas

• Integrações diretas por processador (múltiplos SDKs / APIs): Implemente contra cada processador de pagamento separadamente. Isso pode aumentar o código e a manutenção específicos por processador em comparação a um schema unificado.
• Plataformas de orquestração de pagamentos / conectores SaaS: Use orquestração de terceiros para abstrair múltiplos processadores. Essas alternativas tipicamente transferem a complexidade para a plataforma em vez de usar uma biblioteca de integração como camada de transformação.
• Outras bibliotecas de conectores stateless ou camadas de middleware: Escolha middleware que normalize requisições de pagamento entre provedores. As diferenças estarão em como lidam com vault/tokenização, se mantêm estado, e como gerenciam cobertura/testes de conectores.
• Usar a lógica de conectores do Hyperswitch diretamente (sem o Prism como extração): Se você já opera dentro do Hyperswitch, pode depender dos componentes mais amplos da plataforma em vez de adotar o Prism como biblioteca unificada standalone.