Para se especializar em pagamentos como dev back-end, você precisa dominar três camadas ao mesmo tempo: a engenharia de sistemas que não podem errar (filas, idempotência, consistência), o vocabulário do negócio financeiro (MDR, liquidação, chargeback, conciliação) e a integração com provedores reais. O caminho mais curto não é ler sobre fintech. É construir um fluxo completo de cobrança em sandbox e fazê-lo sobreviver a falhas. Esse tripé é o que eu sigo até hoje na Granpag, e é o que eu recomendo para quem quer entrar nesse nicho.

Por que pagamentos é um bom nicho para dev back-end?

Porque quase todo produto digital, cedo ou tarde, precisa cobrar alguém. E quando chega essa hora, a maioria dos times descobre que integrar um checkout é fácil, mas manter dinheiro correto em produção é difícil. Webhook que chega duas vezes, estorno parcial, repasse para vários recebedores, extrato do provedor que não bate com o banco: tudo isso aparece depois do primeiro mês.

Dev que já passou por esses problemas tem um valor desproporcional, por três motivos:

  1. O custo do erro é alto e visível. Um bug de layout irrita; um bug de cobrança duplicada gera chargeback, suporte e perda de confiança.
  2. O conhecimento é transferível. Os conceitos de Stripe, Pagar.me, Asaas ou Zoop são parecidos. Aprendendo o modelo mental, você troca de provedor sem começar do zero.
  3. Pouca gente gosta do assunto. Conciliação e regras de liquidação não são glamourosas. Isso reduz a concorrência.

No meu caso, pagamentos apareceram primeiro como necessidade dos produtos (o Horalis precisava cobrar assinatura, o Vinea precisava lidar com contribuições) e depois virou o centro de tudo com a Granpag.

O que um dev de pagamentos precisa saber além do framework?

Laravel, Node.js ou Python são só o veículo. O que diferencia é um conjunto de fundamentos que aparecem em qualquer stack:

  1. Dinheiro como inteiro. Valores em centavos, nunca em float. Arredondamento é decisão de negócio, não detalhe de implementação.
  2. Idempotência. Idempotência é a garantia de que executar a mesma operação duas vezes produz o mesmo efeito que executar uma. Toda chamada que move dinheiro precisa disso.
  3. Filas e retentativas. Saber quando um job pode ser repetido com segurança, como configurar backoff no Horizon e o que acontece se o worker morre no meio.
  4. Máquina de estados. Um pagamento passa por estados bem definidos e nem toda transição é válida.
  5. Consistência entre sistemas. Seu banco, o provedor e o banco liquidante são três fontes de verdade que vão divergir. Você precisa de um processo para detectar e resolver isso.
  6. Auditoria. Registro imutável de quem mudou o quê e quando. Em financeiro, "não sei por que esse saldo mudou" é inaceitável.
  7. Segurança e compliance. Noções de PCI DSS (o padrão de segurança para quem lida com dados de cartão), LGPD e KYC, que é o processo de verificar a identidade do cliente, normalmente feito com ferramentas como Sumsub.

Dois exemplos curtos do que eu considero o mínimo. Primeiro, um value object para dinheiro:

final class Money
{
    public function __construct(
        public readonly int $cents,
        public readonly string $currency = 'BRL',
    ) {}

    public static function fromDecimal(string $value): self
    {
        return new self((int) bcmul($value, '100', 0));
    }
}

Segundo, transições de estado explícitas com enum:

enum PaymentStatus: string
{
    case Pending = 'pending';
    case Authorized = 'authorized';
    case Paid = 'paid';
    case Refunded = 'refunded';
    case Failed = 'failed';

    public function canTransitionTo(self $next): bool
    {
        return in_array($next, match ($this) {
            self::Pending => [self::Authorized, self::Paid, self::Failed],
            self::Authorized => [self::Paid, self::Failed],
            self::Paid => [self::Refunded],
            default => [],
        }, true);
    }
}

Nenhum dos dois é sofisticado. O ponto é o hábito: quem trabalha com pagamentos para de tratar status como string solta e valor como float logo no primeiro incidente.

Quais termos do mercado financeiro um dev precisa entender?

Boa parte da dificuldade em entrevistas e no dia a dia não é técnica, é de vocabulário. Quando o financeiro diz "o repasse veio com MDR errado", você precisa entender a frase antes de abrir o código.

Termo O que significa na prática
Adquirente Empresa que processa a transação de cartão junto às bandeiras.
Subadquirente Intermediário que agrega lojistas sob uma adquirente; muitos gateways operam assim.
MDR Taxa descontada do lojista sobre cada venda no cartão.
Liquidação O momento em que o dinheiro efetivamente cai na conta do recebedor.
Antecipação Receber antes do prazo de liquidação, pagando uma taxa por isso.
Chargeback Contestação da compra pelo portador do cartão, que reverte o valor.
Split Divisão de um pagamento entre vários recebedores na origem.
Conciliação Conferência entre o que você registrou e o que o provedor ou banco reportou.
Open Finance Compartilhamento de dados bancários autorizado pelo cliente, via agregadores como a Pluggy.

Vale também entender o básico de Pix e boleto: Pix confirma em segundos e não tem chargeback como o cartão, mas tem devolução e mecanismos de contestação próprios; boleto tem compensação em dias úteis e pode ser pago com valor diferente do emitido. Cada meio de pagamento muda o desenho do seu fluxo.

Como ganhar experiência em pagamentos sem trabalhar numa fintech?

Todo provedor sério tem ambiente de sandbox. Use isso a seu favor e construa um projeto que simule problemas reais, não um CRUD com botão de pagar. Minha sugestão de escopo:

  1. Cobrança com dois meios. Cartão e Pix via Stripe ou Asaas em modo de teste.
  2. Webhooks robustos. Endpoint que valida assinatura, grava o evento bruto, responde rápido e processa em fila. Force o reenvio do mesmo evento e prove que nada duplica.
  3. Estorno parcial. Cobre R$ 100, estorne R$ 30 e garanta que todo o resto do sistema (saldo, relatório, nota) reflete isso.
  4. Split. Divida a cobrança entre a plataforma e um recebedor, incluindo o que acontece com a taxa e com o estorno.
  5. Conciliação. Um job diário que busca as transações no provedor e marca divergências com o seu banco.
  6. Testes de falha. Derrube o worker no meio de um job, simule timeout do provedor, envie webhook fora de ordem.

Documente no README as decisões e, principalmente, os problemas que você encontrou. Um repositório desses vale mais em entrevista do que cinco certificações, porque mostra que você pensou em falha e não só no caminho feliz.

Se você já trabalha numa empresa que cobra clientes, o caminho é ainda melhor: ofereça-se para cuidar da integração de pagamentos, dos relatórios financeiros ou da investigação de divergências. Normalmente ninguém disputa essas tarefas.

Como mostrar experiência em pagamentos no currículo e na entrevista?

Evite frases genéricas como "integração com gateways de pagamento". Isso todo mundo escreve. Descreva o problema e a garantia que você entregou:

  • Em vez de "integrei com Pagar.me", algo como "implementei processamento idempotente de webhooks com fila e deduplicação por ID de evento".
  • Em vez de "trabalhei com financeiro", algo como "criei rotina de conciliação diária entre extrato do provedor e registros internos".

Na entrevista, as perguntas que separam quem já viveu o problema de quem só leu sobre ele costumam ser estas:

  1. Como você evita cobrar o cliente duas vezes se a requisição ao provedor der timeout?
  2. O que acontece se o webhook de pagamento aprovado chegar antes da sua transação de criação commitar?
  3. Como você distribui um centavo de arredondamento num split entre três recebedores?
  4. Como você descobre que um pagamento foi aprovado no provedor mas ficou pendente no seu banco?

Se você consegue responder essas quatro com exemplos de código e trade-offs, você já está acima da média do mercado.

Quais erros de carreira evitar ao entrar nesse nicho?

  1. Virar especialista em um único provedor. Saber todos os endpoints de um gateway é útil por um tempo. Saber o modelo por trás de todos dura a carreira inteira.
  2. Ignorar o lado operacional. Pagamentos envolvem suporte, financeiro e jurídico. Dev que conversa com o time de operações entende os problemas antes deles virarem incidente.
  3. Achar que regulação é problema de outra pessoa. Você não precisa ser advogado, mas precisa saber quando uma funcionalidade esbarra em regras do Banco Central, em KYC ou em LGPD.
  4. Otimizar cedo demais. Em financeiro, correção vem antes de performance. Um job lento e correto é melhor que um rápido que perde centavos.
  5. Não registrar o que aprende. Cada incidente é material. Anote causa, correção e como detectar mais cedo. Este blog existe exatamente por isso.

Por onde começar na prática

Se eu tivesse que recomeçar hoje, faria assim: nas primeiras semanas, leria a documentação de webhooks, estornos e split de dois provedores diferentes, comparando como cada um modela a mesma coisa. Em seguida, construiria o projeto de sandbox descrito acima, com foco em quebrar o próprio sistema. Por último, escreveria sobre o que deu errado, num README ou num blog, e levaria esse material para as entrevistas.

O dev de pagamentos não é quem conhece mais APIs. É quem, diante de qualquer fluxo que move dinheiro, pergunta automaticamente: e se isso rodar duas vezes, chegar fora de ordem ou falhar no meio? Treine essa pergunta até ela virar reflexo, e o nicho se abre.