Idempotency first
Every externally triggered write carries an idempotency key, and the service stores the result of the first successful attempt, so a replay returns the same answer instead of charging again.
Payment integration development for platforms that cannot afford silent failure.
Gateway and PSP integrations, webhook pipelines, idempotent transaction handling, reconciliation and refunds, built in .NET and ASP.NET Core by engineers who have worked inside PCI DSS scoped payment platforms.
Scope
What we build and fix.
- Gateway and PSP integrationCard payments, alternative methods and acquirer APIs, built behind an internal abstraction so a provider change does not reach your domain code.
- Webhook intake pipelinesSignature verification, deduplication, ordering, replay and dead letter handling.
- Idempotent transaction handlingIdempotency keys, outbox pattern, retry and timeout budgets, single effect guarantees at the application boundary.
- Reconciliation and settlementMatching internal records against provider settlement files, exception queues and a defensible daily position.
- Refunds, disputes and chargebacksPartial and full refunds, state machines that survive provider lag, and dispute evidence workflows.
- Merchant dashboards and back officeTransaction search, settlement views, exports and role based access in React and TypeScript.
- Provider migrationsParallel running, staged cutover and a documented way back.
- E-commerce and ERP integrationsStorefront, order management and ERP connections around the payment flow.
Technical approach
How we build integrations that survive bad days.
Explicit state machines
Payment intents, captures, refunds and disputes are modelled as explicit states with allowed transitions, so a late webhook cannot move a transaction backwards.
Outbox and asynchronous delivery
Outbound calls and events are written in the same transaction as the state change and dispatched by a worker, so a crash between the two cannot lose a payment event.
Retries with budgets
Timeouts, bounded retries with exponential backoff and circuit breaking, so a slow provider degrades checkout instead of taking it down.
Reconciliation as a feature
Settlement files are ingested and matched on a schedule, and unmatched items are raised as exceptions for a human rather than silently dropped.
Observability and audit trail
Correlation identifiers across hops, structured logs, metrics on the states that matter, and an append only audit trail of who changed what.
Scope aware data handling
Card data stays inside the boundary your compliance programme defines: tokens and references by default, key management through KMS and least privilege IAM, with data discovery when scope has to be proven.
Tested failure paths
Provider timeouts, duplicate webhooks, out of order events and partial failures are covered by tests, because that is where payment bugs live.
Engagements
Three ways to start.
Entry level engagement
Payment Integration & Reliability Review
A fixed scope, fixed fee review of one payment integration or transaction flow. We read the code and the configuration, map the failure paths, and hand you a written assessment ranked by risk. It is the fastest way to find out whether your integration behaves the way you think it does, with no obligation to continue.
Request the reviewYou receive a findings document ranked by risk, a prioritised remediation plan, and a ninety minute walkthrough with the engineers who did the review. If you continue with a build engagement, the review fee is credited against it.
What we examine
- Integration boundaries and failure modes
- Idempotency, retries, timeouts and duplicate protection
- Webhook signature verification, ordering and replay
- Reconciliation, refunds, chargebacks and exception handling
- Secrets, key management and data handling in scope
- Observability: logs, metrics, alerting and audit trail
Integration build and migration
Scoped delivery of a new payment integration, a provider migration, or the reliability work identified in the review. We own the integration layer and hand it over tested and documented.
Embedded senior engineering
A senior engineer or a small team working inside your sprints, your repository and your review process for a defined period, so the knowledge stays in your team.
Custom software development
Payments is our specialism, not our limit. We also build and maintain general purpose backends, internal platforms and web applications on the same .NET and React stack.
Questions we are asked
Before you write to us.
Do you work with a specific payment provider?
We integrate against documented REST and webhook APIs, which covers most gateways, PSPs and acquirers. We hold no partner or reseller status with any provider, and we will tell you plainly how much of a given provider's flows we have worked with before.
Can you work on a live production integration?
Yes. We start read only: code and configuration review, log and failure analysis, then an agreed change plan. Changes go through your deployment process, behind feature flags or a parallel path where the risk justifies it.
Who owns the code?
You do. We work in your repository, or hand over a repository with documentation, tests and deployment configuration.
Do you handle card data?
Only where the engagement requires it and your compliance programme allows it. In most engagements we work with tokens and references, which keeps cardholder data out of scope by design.
What if we only need a second opinion?
Take the Payment Integration & Reliability Review. It is scoped so you get a written technical assessment without committing to a build.
Contact
Discuss your project
The more concrete, the better: the provider you integrate with, the part of the flow that hurts, the stack it runs on, and when it needs to be done.
- Emailcontact@theia-software.net
- ResponseWithin one business day, from an engineer
- EngagementsRemote, B2B, clients in the EU and beyond
- LanguagesEnglish, Romanian