area · Backend & Payments
Two backend stacks, TypeScript/NestJS and Python/FastAPI, over PostgreSQL, Redis and queues. At a regulated fintech I built the payment orchestrator of an online collections site and co-develop an in-house payment gateway on PSE and Bre-B, designed to never charge twice.
measured impact · before → after
33.66 ms → 0.42 ms
◆ PaymentFlowSimulator
Simulate a charge's lifecycle. Try «Double-click pay»: the second attempt finds the obligation's lock and returns the same payment with the same idempotency key. At the end, replay the webhook: the already-applied event is ignored.
Demo with fictitious data: no real clients and nothing from production.
Online collections for an institutional client: payer return with precedence rules, verified webhooks and anti-abuse that never blocks a payment.
Read the case study →A PSP straight to the rails, without holding funds: idempotency, a transactional outbox, signed webhooks and field encryption.
One engine for 10 business domains, with a job queue, streaming to object storage and keyset pagination.
Read the case study →Backend and payment site
Collections platform an institutional client's borrowers use to pay online via PSE and Bre-B. Certified by the payment processor and deployed; in pre-production testing before cutover.
Core co-developer
A PSP connected directly to the PSE and Bre-B rails without holding funds, designed to never charge twice, always notify and expose explicit payment states. On its way to certification.
Sole author of the core
Financial data exports without timeouts or unbounded memory: registry pattern, job queue, multipart streaming to object storage, keyset pagination and a job status API.
I reply in English or Spanish.