Companies in this catalog do not charge applicants. Never send money to apply.
We are looking for a Principal .NET Engineer to join Payforge as part of a very small team responsible for the backend of a client’s live, multi-tenant payments platform. Merchants on the platform take card payments online, through payment links, and — with a new physical terminal about to launch — in shops, restaurants, and venues. Volumes are growing week on week, and card-present traffic will add constant, bursty load from thousands of concurrent devices that cannot be asked to wait. The decisions made now have to hold at several times today’s load, so database performance, correctness under retries, and the cost of every request are commercial concerns rather than housekeeping. This is a hands-on role with no direct reports, by design: there is no separate architecture team, and the engineer who builds a feature designs it. You will work alongside the client’s technical lead on the parts of the system where design decisions have a direct financial consequence.
Key Responsibilities
Own features end to end — the business conversation, the design, the schema, the API, the tests, the deployment, and the follow-up when something behaves unexpectedly in production.
Build and harden online payment flows across multiple acquirers and payment providers, including hosted payment pages, card authentication, provider callbacks, and webhooks.
Keep a payment and its order consistent when a provider is slow, a callback never arrives, or a customer loses connection mid-checkout, and make refunds and repeat payments safe to retry.
Help carry the new card-present terminal product into production: ingest sales, refunds, and settlement data from thousands of concurrent devices and provider webhooks through Kafka into PostgreSQL as set-based batch writes.
Ensure transaction processing stays correct under bursty traffic, replay, duplicate delivery, partial failure, and rolling deploys, with idempotency and uniqueness guaranteed where they actually hold.
Own read performance for merchant-facing pages and reports over hundreds of thousands of rows per tenant, including a two-tier cache (local memory plus a ValKey cluster) with correct invalidation across nodes.
Treat database performance as a commercial concern: understand what a statement costs, measure it against production-sized data rather than estimating, and treat a slow query as a defect.
Provide design input early where small savings compound — milliseconds per request, avoided round trips, and avoided reads — including challenging designs specified by others before they ship.
Investigate unexplained production behaviour through to root cause, rather than closing work at the first passing test.
Take part in direct, written code review: give clear, constructive scrutiny and expect the same on your own work.
Manage your own delivery against agreed goals, and flag at-risk dates early rather than on the day.
Skills & Experience
Experience: 10+ years in backend engineering across several companies, technologies, and sectors — enough to have seen more than one way of building a system and watched some of them fail.
C# and .NET in production (ASP.NET Core; recent .NET versions), in systems with real users and real money or equivalent consequences.
Experience designing distributed backends across multiple application servers, with a shared cache and a database with a single writer and read replicas.
Real-world use of queues or event streams (Kafka, RabbitMQ, SQS, Azure Service Bus, or equivalent), including handling replay, duplicate delivery, and partial failure.
Fluency with async and await in .NET, and a clear understanding of the difference between waiting on I/O and consuming CPU.
Strong PostgreSQL (or similar) skills: reading query plans, choosing what to index and which index type suits a query shape, understanding why an index is or is not used, and recognising when a design will not survive a large tenant.
Experience with caching in multi-node environments, including invalidation strategies and staleness trade-offs.
Sound judgement on architecture, asynchronous processing, and event-driven systems — including when synchronous is the right answer — and the ability to estimate what a proposed design will cost per request before it is built.
A habit of measuring performance changes against realistic, production-sized data before shipping.
Practical, day-to-day use of AI coding assistants and LLMs for writing code, tests, and benchmarks, combined with the engineering judgement to own every design decision and to explain and defend any code you submit, however it was produced.
Comfortable receiving and giving direct written feedback, including being told that an approach should be replaced.
Experience working in distributed or remote teams, with strong written and verbal communication.
Preferred Qualifications
Payments experience: card processors and acquirers, 3-D Secure, refunds, settlement, and idempotent money movement.
Experience with card-present or terminal payments, or with integrations such as Worldpay, Stripe, Fiserv, or Verifone.
Deep SQL and index tuning experience.
Hands-on experience with Dapper, EF Core, Hangfire, Redis or ValKey, and Centrifugo or another websocket layer.
Comfortable on Linux and self-hosted infrastructure (bare metal, Proxmox), including the operational side when something breaks.
Experience with Rust, Go, or another systems language.
Has led a team before and would now rather be building.
Experience in a consultancy or professional-services environment working with client engineering teams.
What we value?
Ownership – engineers own what they submit. Any AI tooling is welcome; what matters is that the author understands the code and can justify it in review.
Judgement over tools – AI is used for writing code, tests, and benchmarks, but deciding what to build, how a system fits together, and which trade-off is right stays with the engineer.
Measure before you ship – changes that touch the database are benchmarked against production-sized data, and a slow query is treated as a defect.
Direct, written reviews – feedback is given plainly and in writing, and the same scrutiny is expected in return, including on the technical lead’s own work.
Small team, limited process – a short regular sync and no ceremony for its own sake.
Goal-based work – we agree what is being delivered and roughly when, the time is yours to manage, and a date at risk is flagged early rather than on the day.
Going further than the ticket – investigating an unexplained log entry until the cause is found, rather than closing the work at the first green test.
About Payforge
Payforge is a specialist professional-services company focused exclusively on payments and fintech. We help clients deliver high-quality, scalable technology solutions in an evolving global financial landscape.
Equal Opportunity Statement
Payforge is proud to be an equal-opportunity employer. All qualified applicants will receive consideration without regard to race, colour, religion, sex, sexual orientation, gender identity, national origin, disability or veteran status. We welcome applicants from all backgrounds.