SPRINGBROOK SOFTWARE

Technical Role Specification

Senior Payments Engineer

Payments Platform & PCI (.NET / PHP) — Technical Specification

Role Overview

Senior engineer on Payments within the Springbrook suite of products — ERP, Payments, and shared services. Local government customers use the suite to collect utility bill payments, taxes, permit fees, and over-the-counter cashiering across online portals, IVR, kiosks, point-of-sale terminals, and recurring autopay. When payments fail, customers cannot collect public revenue.

This is a deep specialist role, not a generalist one. It is for engineers whose primary craft is payments: gateway and processor integrations, tokenization and vaulting, the payment lifecycle from authorization through settlement and reconciliation, refunds and chargebacks, and the controls that hold PCI DSS scope.

It is also a player-coach role, weighted heavily toward individual contribution — roughly 75–85% hands-on in code. The coaching expectation is real but it is discharged through the work: reviewing payment changes, pairing on hard integrations, and writing the design notes and documentation that make payments and PCI knowledge transferable. There is no people-management component at either level.

Player-coach balance

Roughly 75–85% hands-on delivery, 15–25% design, review, and coaching. This role is deliberately more individual-contributor than the Platform Modernization lead: payments depth is the scarce thing being hired for, and the majority of the time should be spent applying it, not directing others.

Payments does not stand alone: it consumes shared services for identity, integration, and common data access, and it must stay in step with ERP for receivables, cashiering, and general ledger posting. Engineers in this role own payment components end to end — design, implementation, tests, deployment, instrumentation, and the production behavior — including the contracts Payments exposes to the rest of the suite.

Depth is what distinguishes this role. Springbrook is hiring for genuine payments expertise — engineers who have integrated real processors, debugged real settlement breaks, and carried PCI controls through an assessment — rather than general web engineers who will learn payments on the job.

AI-assisted development is the expected working method here too, with payments-grade discipline about what may and may not be exposed to those tools.

Levels

This specification covers two levels on the same track. The technical content is shared; the difference is scope of independent judgment.

Senior Payments Engineer

Owns significant payment components and integrations end to end. Delivers independently within an established architecture, reviews peers’ work, and is trusted in production incidents on the payment path.

Staff / Lead Payments Engineer

Sets payments architecture across the product, owns the gateway abstraction and the PCI engineering posture, arbitrates cross-product payment decisions, and is the company’s primary technical authority on payments. Mentorship and technical direction are explicit expectations; formal people management is not. Hands-on share shifts to roughly 70–75%.

Technical Environment

Product surface

Payments within the Springbrook suite — ERP, Payments, and shared services; online portals, IVR, kiosks, POS terminals, and cashiering.

Shared services

Identity and authentication, common data access, integration and messaging; ERP contracts for receivables, cashiering, and general ledger posting.

Payment rails

Card-not-present and card-present; ACH / e-check; recurring and autopay; split tender and partial payments.

Gateways

Multiple card gateways and processors behind an internal abstraction layer — examples in market: Stripe, Adyen, Braintree, Authorize.Net, CyberSource, Worldpay, Fiserv, Global Payments, Elavon, Paya.

Card data

Gateway and network tokenization, vaulting, stored credentials, account updater, hosted fields / iframes / redirects for scope minimization, EMV and P2PE where card-present.

Compliance

PCI DSS v4.0 — CDE scoping and segmentation, SAQ/ROC/AOC evidence, secure SDLC requirements, logging and retention.

Backend

C# / .NET — legacy .NET Framework through current .NET (8/9+). PHP — legacy 5.x/7.x through modern 8.x.

Data

MySQL and Microsoft SQL Server; transaction ledger, settlement and reconciliation data, live financial migrations.

Cloud

Azure — Virtual Machines, App Service, Azure Functions, Logic Apps, queue- and event-driven services, VNet segmentation, Key Vault and HSM-backed keys.

Front-end / mobile

Angular and React with TypeScript; mobile payment flows via native, cross-platform, or responsive web.

Delivery

Azure DevOps or GitHub Actions with security gates, approvals, and separation of duties; IaC via Bicep/ARM or Terraform.

AI tooling

GitHub Copilot, Claude Code, Cursor or equivalent, used daily under documented data-handling boundaries; synthetic and test-card data only.

Scope of Technical Ownership

Payment processing architecture. End-to-end design of the payment path — authorization, capture, void, refund, settlement, reconciliation — across card-not-present, card-present, and ACH rails.

Gateway and processor integrations. Integration architecture and the lifecycle of every gateway relationship in code: onboarding, certification, versioning, sunsetting, and the abstraction that keeps them interchangeable.

Cardholder data security. Tokenization, vaulting, encryption, key management, PAN masking and truncation, and the technical decisions that keep systems out of PCI scope wherever possible.

PCI DSS engineering. Control implementation, secure development requirements, segmentation, logging and monitoring, and the engineering evidence a QSA assessment consumes.

Money movement correctness. Idempotency, retry and reversal semantics, the payment ledger, settlement matching, and reconciliation accuracy — the guarantee that no payment is lost, doubled, or misapplied.

Legacy modernization in the payment path. Upgrading legacy .NET and PHP payment components to current supported runtimes without interrupting revenue collection, including MySQL and MS SQL migrations on live payment data.

Cloud architecture. Payment workloads across Azure VMs and serverless, with the network segmentation, secrets management, and audit posture PCI requires.

Payment interfaces. Technical direction for Angular and React payment UIs and mobile payment flows, including the embed patterns that minimize PCI scope.

Suite integration. The contracts Payments exposes to and consumes from the rest of the suite — shared identity and data access, and the ERP interfaces for receivables, cashiering,



and general ledger posting — kept versioned and backward-compatible as each product modernizes at its own pace.

AI-augmented delivery. Daily use of AI tooling on payments work within documented data-handling boundaries, and contribution to the team’s context assets, prompts, and review standards for AI-generated code.

Technical influence. Code quality and review standards on the payment path, and distributing payments and PCI knowledge so it is not concentrated in one person.

Responsibilities Payments architecture and integration

Design and evolve the payment service architecture: gateway abstraction layer, payment method registry, transaction state machine, and event model.

Build and maintain card gateway/processor and ACH origination integrations, including certification and sandbox-to-production promotion.

Implement and own tokenization and vaulting — network or gateway tokens, stored-credential flows, recurring billing, account updater handling.

Own 3-D Secure / SCA, AVS and CVV verification, and fraud-signal integration.

Implement card-present flows where in scope: EMV, P2PE-validated terminals, semi-integrated POS, cashiering hardware.

Design idempotent, replay-safe payment APIs with correct retry, timeout, reversal, and duplicate-detection behavior under partial failure.

Own webhook and callback processing — signature verification, out-of-order and duplicate delivery, guaranteed eventual consistency with the ledger.

Design the settlement and reconciliation pipeline: batch close, deposit matching, funding reports, fee accounting, and workable exception queues.

Own refunds, voids, disputes and chargeback representment, and the accounting entries each produces.

Handle public-sector payment requirements: convenience and service fees, split tender, partial payments, payment plans, NSF/returned-item handling, receipts.

PCI DSS and security engineering

Implement and maintain PCI DSS v4.0 controls across the payments surface and produce the engineering evidence an assessment requires — at the staff/lead level, own that posture outright.

Drive scope reduction as deliberate strategy — hosted fields, iframes, redirects, P2PE, tokenization — so as few systems as possible touch cardholder data.

Maintain accurate CDE boundaries: data-flow diagrams, network segmentation, segmentation testing, inventory of PAN-touching components.

Implement PCI-required controls in code and infrastructure: strong cryptography in transit and at rest, key management and rotation (Key Vault, HSM-backed keys), least privilege, MFA on CDE access, secure defaults, tamper-resistant audit logging with required retention.

Enforce secure SDLC: threat modeling of payment changes, secure code review, SAST/DAST/SCA in the pipeline, vulnerability remediation SLAs, auditable change control.

Guarantee PAN, sensitive authentication data, and bank account numbers never reach logs, error reports, analytics, support tools, test fixtures, or non-production environments — and build the automated detection that proves it.

Own payment-path incident response readiness, including suspected cardholder data exposure escalation and forensic log availability.

Track card brand mandates, NACHA rule changes, and gateway deprecations, and turn them into a dated engineering plan before the deadlines bite.

AI-augmented engineering process

Weighted equally with the two sections above.

Establish AI-assisted development as the team’s default working method — coding assistants and agentic tools used daily for implementation, refactoring, and integration work.

Define and enforce the AI data-handling boundary for a payments team: approved tools only, no cardholder data or production payment payloads in prompts or context, synthetic and test-card data for all AI-assisted work, with technical controls and audit trail that make the rule enforceable rather than aspirational.

Use AI on the work that traditionally bottlenecks payments engineering: reading and summarizing gateway and processor specifications, generating integration scaffolding and client code from API documentation, and mapping field-level differences between processors.

Apply AI to legacy payment code comprehension — documentation, call graphs, and behavioral summaries for undocumented .NET and PHP payment logic so it can be safely modernized.

Drive AI-generated test coverage across the payment path: characterization tests before refactoring, edge-case and failure-mode matrices (declines, timeouts, partial captures, duplicate webhooks, reversal races), and reconciliation scenarios — synthetic data only.

Use AI to assist reconciliation and settlement analysis: anomaly explanation, exception clustering, and drafting root-cause narratives, with human verification before any financial conclusion is acted on.

Integrate AI into the delivery pipeline: automated code review with payments-specific and PCI-specific review prompts, PR summarization, static-analysis and vulnerability triage, test-failure diagnosis, release notes.

Build AI-assisted compliance tooling where it earns its place — drafting control narratives, mapping code changes to PCI requirements, pre-screening diffs for PAN-logging risk — while keeping a human accountable for every compliance assertion.

Define the review policy for AI-generated code with a higher bar inside the payment path: mandatory human review, no auto-merge in the CDE, provenance tracking, and explicit checks for hallucinated APIs, insecure crypto, and silent behavior changes.

Maintain the team’s AI context assets — repository instruction files, architectural and domain context documents, reusable prompts, and custom agents encoding Springbrook’s payments conventions and PCI constraints.

Measure and report impact — throughput, defect and escaped-defect rate, review latency, coverage gain — so AI adoption is defended with evidence.

Coach the team on effective and skeptical AI use, in a domain where a subtle error moves real money.

Engineering and modernization

Write, review, and ship production code in C#/.NET and PHP, plus TypeScript for payment front-ends.

Lead the upgrade of legacy .NET and PHP payment components to current LTS runtimes, sequenced so revenue collection is never interrupted.





Author and tune SQL against both MySQL and Microsoft SQL Server; own safe, auditable migrations of live payment and ledger data.

Design payment workloads across Azure VMs and serverless, choosing correctly with cost, latency, compliance scope, and operational burden accounted for.

Build and maintain CI/CD pipelines with security gates, approvals, and separation of duties appropriate to a payment system.

Instrument the payment path for the metrics that matter — authorization success rate, decline reasons, gateway latency and error rate, settlement lag, reconciliation break volume — and lead escalated incident response.

Provide technical direction for Angular and React payment interfaces and mobile payment flows, including accessibility and PCI-minimizing embed patterns.

Coaching and technical influence

Coach through the work — pair on hard integrations, review with explanation rather than verdicts, and leave behind design notes that teach the reasoning.

Review peers’ payment code with an explicit payments and security lens, and raise the standard by example rather than by mandate.

Build payments and PCI literacy across the team — pairing, written design notes, and internal documentation — so knowledge is not concentrated in one person.

Communicate payment risk and trade-offs clearly to engineers and to non-engineering stakeholders.

Work effectively with distributed and offshore contributors, including being clear about what payment work may and may not be performed outside approved environments.

At the staff/lead level: set payments architecture across the product, own the gateway abstraction and PCI engineering posture, and arbitrate cross-product payment decisions.

Problem solving and quality

Diagnose and resolve the hardest class of payments defects: intermittent gateway failures, race conditions between callbacks and user actions, duplicate charges, settlement mismatches, and money in an indeterminate state.

Decompose ambiguous, high-stakes problems in legacy code with no tests and undocumented business rules into tractable, sequenced, reversible work.

Retire technical debt in the payment path deliberately, with a stated cost of inaction expressed in risk and dollars.

Hold the line on correctness — financial accuracy and cardholder data safety outrank delivery speed, and say so when a deadline threatens either.

Technical Requirements Payments domain

Deep working knowledge of the card payment lifecycle: authorization, capture, void, refund, settlement, funding, interchange and fee mechanics, and the roles of merchant, acquirer, processor, gateway, and card network.

Production experience integrating at least two card gateways or processors, including certification and cut-over.

ACH / e-check experience with working familiarity of NACHA operating rules, return codes, and settlement timing.

Tokenization and vaulting in practice — gateway or network tokens, stored credentials, recurring and autopay flows, account updater.

Card-not-present scope-minimizing patterns: hosted payment pages, hosted fields, iframes, redirects, client-side tokenization.

Command of money-movement correctness: idempotency keys, exactly-once effects over at-least-once delivery, reversal and compensation, double-entry or append-only ledger design, reconciliation to the penny.

4+ years building or operating payment systems that handled real money at volume.

PCI DSS and security

Practical command of PCI DSS v4.0 as an implementer, not just awareness — SAQ types, ROC/AOC, CDE scoping, segmentation testing, customized-approach option.

Direct hands-on involvement in at least one PCI assessment cycle as an engineer or engineering owner: scope, controls implemented, evidence produced, findings remediated.

Applied cryptography for payments: TLS configuration, encryption at rest, key management and rotation, HSM or KMS-backed keys, and knowing what must never be stored versus what may be stored masked or truncated.

Secure development practice: threat modeling, secure code review, SAST/DAST/SCA integration, vulnerability management, auditable change control.

Secrets management and least-privilege access design in a cloud environment.

Stack

Deep C#/.NET expertise spanning legacy .NET Framework through current .NET (8/9+), including ASP.NET MVC to ASP.NET Core migration patterns.

Strong PHP expertise including contemporary PHP 8.x, Composer, and upgrading legacy PHP 5.x/7.x codebases.

Production experience with both MySQL and Microsoft SQL Server — schema design, indexing, query optimization, low-downtime migrations on live financial data.

Hands-on Azure across compute, serverless, storage, networking, and Key Vault; ability to design serverless architectures and to say where serverless is wrong.

Infrastructure-as-code and CI/CD (Bicep/ARM/Terraform; Azure DevOps or GitHub Actions).

Working proficiency in Angular and React with TypeScript, sufficient to review code, set standards, and contribute directly.

Mobile development exposure — native, cross-platform, or responsive mobile web — including mobile payment flows and device-based payment methods.

AI-assisted engineering — required

Demonstrated daily working use of AI coding assistants and agentic development tools on production code, with specific delivered work to point to.

Strong prompting and context engineering on large legacy codebases.

Defensible judgment about AI use in a regulated, money-moving environment: what data may never be exposed, where human review is mandatory, and how to prove compliance with those boundaries.

Ability to identify hallucinated APIs, plausible-but-wrong logic, insecure generated crypto, and output that should be discarded.

Experience introducing AI tooling to a team — standards, review policy, change management.

Comfort integrating AI into automation: CI checks, automated review, test generation, or internal developer tooling built on LLM APIs.

Engineering judgment

Exceptional analytical and debugging ability under production pressure, with the temperament for incidents where money is at stake.

Highly capable at complex problem solving — a track record of resolving payment and data-integrity problems others could not.

Clear technical writing — design documents, control narratives, incident reports, and migration plans that satisfy an auditor and an engineer alike.

Sound judgment on scope, risk, and sequencing.

7+ years building and operating production web applications, with the majority of recent work in payments or financial systems.

Staff/lead level: demonstrated architectural ownership of a payments surface and evidence of having raised other engineers’ payments capability.

Springbrook Software — internal technical specification. 25 August 2026. Describes payment control surface; handle as internal only.

📌 Lead Payments Engineer .Net (Gurugram)
🏢 iKrux
📍 Gurugram