Proposal for Plata
Make it happen.
This site isn't a request for a role. It's a working prototype and an architecture, built to be reviewed, questioned and tested — the same way I'd want any engineer joining Plata to prove their thinking.
Repayment friction is costing Plata recoverable debt.
Every transaction routed through card rails costs more than it needs to.
The merchant relationship is up for grabs while Revolut Pay is still new to Mexico.
Klaqo is not a claim that these are solved. It's the architecture that makes them testable.
Klaqo explores how account-to-account payments become fast enough for the point of sale, transparent enough for the customer, and reliable enough to sit next to Plata's existing ledger.
The merchant POS creates the request, the customer wallet authorizes it. Watch the flows here — or open either app and run it yourself.
The interface is only the visible layer. Reliability comes from controlled state transitions, idempotent requests, a balanced ledger and clear failure handling.
QR_DISPLAYEDThe POS sends the amount with an idempotency key. In one serializable PostgreSQL transaction the API creates the payment intent, signs its QR and records the first events.
PAYMENT_INTENT_CREATEDQR_GENERATEDVue 3. Requests a payment with an idempotency key, shows the signed QR and polls its status every 1.5 s.
chi on net/http. Authenticates merchant sessions and wallet tokens, validates input, rate-limits and tags every request with an ID.
Stores each keyed request with a hash of its body and replays the stored response when it is retried.
Moves a payment only along allowed transitions, under a row lock, inside one PostgreSQL transaction. Final states never change.
HMAC-signed payload with a 120-second expiry and a nonce. A changed, expired or mismatched code is rejected.
Every transition is written as an event in the same transaction: an ordered, auditable history of each payment.
PostgreSQL is the source of truth. A retried request replays its first response, a final state never changes, and the POS only ever reads committed state — it polls every 1.5 seconds, so it cannot see a payment as settled before its ledger entries exist. Push updates over WebSocket or SSE are not built yet.
Every guarantee below is visible in the transaction above — follow one to see where it acts.
A retried request replays its stored response instead of creating a second payment.
No duplicate payments when a network call is retried.
HMAC signature, 120-second expiry and a nonce; a changed or expired code is rejected.
A customer can't be shown a tampered amount or merchant.
Merchant sessions and wallet tokens, stored as SHA-256 hashes; a wallet can only authorize for its own customer.
Protects the recovery and merchant flows this is meant to fix.
A payment moves only along allowed transitions, under a row lock; a degraded rail leaves it in processing, never half-done.
Fewer ambiguous transactions and support cases.
Every transfer posts balanced entries; PostgreSQL rejects an unbalanced one, and integration tests prove rollback and no overspending.
Customer, merchant and operations resolve to one outcome.
Failed, expired and cancelled stay distinct, each with its error code and its own event history.
A measurable, debuggable recovery journey — not a black box.
Klaqo's architecture was built without internal documentation from Mexican payment systems to reference — the state machine and the mock SPEI rail exist because the problem didn't come pre-solved.
The three opportunities above came from researching Plata's actual payment context and Mexican rail options — SPEI, DiMo — until a specific, testable mechanic emerged, not a generic “fintech idea.”
From the first line of code to a Go state machine on PostgreSQL, a double-entry ledger and two live apps: one person, end to end.
Instead of a CV in a general queue: a named opportunity, a working system, and a direct ask, sent straight to the people who'd decide. This site is the evidence for this one.
Not a Figma concept: a running Go backend, a balanced ledger covered by integration tests, and two live apps a visitor can operate in 04.
Every payment that just works was built by someone you never saw.
Let's schedule a technical review of the codebase and discuss how we can integrate this architecture into your ecosystem.
