Wink Checkout
Payment engine clearing real money — ACH and card rails, database-enforced transaction state, real-time ops alerting.
Product engineer — architecture, integration, alerting
The problem
Wink needed to accept payment for biometric-verified purchases across ACH and card. Off-the-shelf checkout solutions couldn't hook into the biometric auth flow that had to happen before payment authorization, and the ops team had no visibility into transaction health without pulling reports out of the gateway dashboards.
The approach
Built the checkout engine in .NET, with a database-first transaction persistence model (Postgres, every state transition captured). Wired both ACH and Pays gateways behind a single internal interface so the frontend didn't care which rail was clearing. Every processed transaction — success or failure — triggers a formatted Slack message to a dedicated ops channel with the amount, status, transaction ID, and a deep link back to the admin panel.
Selected details
- Transaction state machine is enforced at the database level, not just application code — prevents race-condition inconsistencies during retry logic.
- Idempotency keys on every gateway call; a duplicate charge is architecturally impossible even if the client retries.
- The Slack alerts started as "developer convenience" and became the primary ops monitoring tool — the finance team lives in that channel now.
- Reconciliation job runs nightly; discrepancies are auto-tagged and surfaced in OpsDesk.
Outcome
Live and processing real transactions. Zero payment-integrity incidents to date. The Slack-alert pattern was borrowed by two other Wink internal tools.
Stack