Senior Full Stack Engineer (Frontend-leaning)

About OutsideHire

Outside Hire is a growing outsourcing company with over 75 employees, building custom products and solutions for our clients. We're dynamic, fast-paced, and always evolving!

----------

Why OutsideHire?

- An inclusive and dynamic work environment that values creativity and collaboration
- Opportunities to work on cutting-edge projects that make an impact
- Perks: Competitive salary, remote work, professional development support, etc.
- A team that truly values your skills and contributions

About the Role

You will own the payment SDK: the embeddable React layer that collects payment credentials inside isolated iframes, exchanges them for tokens, and routes transactions to the correct gateway based on server-issued session intent. This is not a role about building forms and CRUD screens. It is infrastructure that other engineers integrate against and that real money flows through, where a bug is not a broken layout but a failed transaction, a double charge, or a compliance i ---------- . The work is front-end-heavy, but backend competence is a hard requirement. You cannot build a secure payment SDK without understanding what happens on the other side of the wire.

What You'll Be Building

- The SDK core. Hosted-fields integration with iframe isolation and cross-origin messaging, and a gateway-agnostic public API so integrators write one integration regardless of the processor behind it.
- The payment state model. Session intent so the client never d ---------- which gateway processes a transaction, plus idempotency, retries, declines, 3DS challenges, timeouts, and the partial states that need reconciliation.
- The integration surface. Versioning and deprecation policy so we can evolve without breaking live merchants, documentation and sandbox examples, and client-side observability on the payment step.

What We're Looking For

Required
- 7+ years building production software, with the majority of that time in frontend engineering
- Deep React and TypeScript. Not "I use React." You understand rendering behavior, state boundaries, effect lifecycles, memorization tradeoffs, and how to design a component API other engineers will consume
- Real backend capability. .NET, Java, or Node.js preferred. You can read and write server-side code, reason about API contracts you did not design, debug across the stack, and hold your own in an architecture discussion
- Security fundamentals as instinct. Same-origin policy, CSP, CORS, XSS vectors, iframe isolation, token handling, why secrets never live in client bundles
- Payment integration experience. Gateway APIs, tokenization, hosted fields, webhooks, or equivalent work in a domain where correctness is non-negotiable
- SDK or library authoring experience, or a track record of building interfaces other engineers integrate against
- Testing discipline. You write tests because untested payment code is a liability, not because a policy says to

Strong Plus
- Hands-on experience with gateway and tokenization stacks
- PCI DSS scope reduction, SAQ A or SAQ A-EP work
- 3D Secure 2 implementation
- Cloud and DevOps exposure (Azure or AWS), CI/CD ownership
- Fluency with AI coding tools (Claude Code, Cursor, Codex, Copilot). We use them heavily. Willingness to learn fast is acceptable, resistance is not

How We Work

We move fast and requirements change. You will not get a fully specified ticket handed to you. You will get a problem, the business context behind it, and the autonomy to solve it.

- You ask the sharp question before writing code, not after shipping the wrong thing
- You escalate ambiguity early instead of guessing quietly
- You push back when an approach is wrong, with a better alternative
- You are comfortable working directly with product and client stakeholders
- You do not need to be managed into producing work you are proud of

If you have only worked in environments with detailed specs, dedicated QA, and long review cycles, you will find this uncomfortable. If you have worked in startups or fast-moving product teams, this will feel familiar.

The Bar

We are explicit about this because it saves everyone time.

We are hiring for craft. That means naming things well, keeping abstractions honest, deleting code that should not exist, reading the gateway documentation rather than guessing, and caring what the integration feels like for the engineer on the other side. We would rather ship one correct payment flow than five that mostly work.

If that sounds like unnecessary perfectionism, we are not a fit. If it sounds like how software should have been built all along, we want to talk.