Yuno is a payment orchestration platform: a single API merchants use for pay-ins, payouts, fraud prevention, and reconciliation across more than a thousand payment methods and providers, with routing and retries deciding where each transaction goes.
I work there as a group staff engineer. The main thing I own is the One Integration Platform, the engine I built from scratch to replace more than 300 bespoke per-provider integration services with signed connector configs running on one reusable runtime. A provider connection stops being a service the team maintains and becomes a configuration the platform executes.
What I built
- The runtime itself: a connector registry, provider HTTP preparation, provider state tracking, reusable workflows, ingress handling, and webhook verification. Purchase, refund, void, payout, and notification flows are expressed as connector config against these primitives instead of handwritten per provider.
- The protocol and auth coverage the long tail demands: REST, SOAP, and ISO 8583 transports; header, Basic, OAuth, request-signing, and mTLS auth; JOSE, JWE, JWS, and WS-Security envelopes; AES and HMAC compatibility modes; multipart uploads; and a durable inbox with workflows for providers that answer late or twice.
- Contract verification in CI: record real provider traffic once, pin it as the connector’s expected behavior, and replay every change against it. Coverage tracking shows which connectors are pinned and which are quarantined, so drift gets caught before it reaches production.
- The first connector ports and cutovers: moving live providers off their bespoke services onto pinned connectors, with recorded-behavior parity checked first and gateway traffic moved after, never the other way around.
- A second delivery path so new integrations are built directly as connectors. No new bespoke service gets created for a provider the engine can already express.
- The PCI boundaries around it: credential and signing material stays out of connector config, with egress and secret handling owned by dedicated services instead of each integration.
Outside the platform
- Routing and catalog work in the transaction core: registering new gateways, wiring their traffic over, and covering the routing, fallback, and recovery decisions with tests.
- An HTTP contract pilot for the payment API: a machine-checked spec with runtime validation, designed to extend across the service fleet.
- Coverage and documentation baselines across the integration fleet: per-service test gates, README claims verified against the code, and English documentation where only Spanish existed.
- Dependency and security maintenance: version bumps with the changelog reviewed against actual usage, and upgrade cascades that touch dozens of modules routed to the owning teams instead of forced through.
- Planning behind adjacent moves: auditing the legacy retirement, porting behaviors from a second engine into the new runtime, and program planning for a white-label partnership migration.
Hard parts
Three hundred providers means three hundred dialects for the same handful of operations, and the differences live in the tail: encrypted payloads with unusual key derivation, non-JSON acknowledgements, nested encodings, early acknowledgements that still require durable follow-through, retries that must not double-charge. Every behavior the engine cannot express becomes either a new primitive or a carve-out, and the whole design tension is keeping the primitive set small while the tail keeps growing.
Cutover is the other hard part. These integrations move money, so there is no flag day. The sequence is always pin the behavior first, match it second, move traffic last, with the old service still standing until the recordings agree. A migration must never change what a merchant sees by accident.
Stack
Go engine and tooling on Postgres, with Kafka between services; Docker and Compose for local and CI runs; AWS provisioned with Terraform; Drone for CI; Datadog for logs, traces, and monitors.