PampaPay

Context

PampaPay is a production fintech platform with two moving parts: a Flutter mobile app and a Go backend. The product handles money movement, so the hard requirements are correctness, compliance, and availability rather than raw speed.

Architecture

The backend is event-driven and split into layers:

• Client requests hit a versioned REST API (/api/v1).
• State lives in PostgreSQL, with object uploads on S3 and delivery through CloudFront.
• Commands are published to an event transport. Production uses AWS SQS, while non-production falls back to an HTTP client.
• External processors call back through webhooks, and KYC updates arrive from a third-party provider.
• A notification service bridges the backend to Towncryer for credential tokens and notification state.

What I worked on

• Led development and maintenance of the production Flutter app.
• Built and maintained Go APIs for authentication, wallets, KYC, and payment workflows.
• Hardened transaction rules, including closing a loophole that let banned users transact and adding a cap for unverified accounts.
• Improved stability through production monitoring, debugging, and performance tuning.

What the system taught me

Event-driven backends make retries and idempotency a first-class concern. Every webhook and every queue consumer has to assume it will see the same message twice, so the write path has to be safe to repeat. Most of the interesting bugs lived there.