Third-party API integration
Connecting your product to the services it depends on: authentication, rate limits, pagination, webhooks, retries and the failure states nobody documents.
Services
Integration & API Engineering
Making systems talk: payment rails, third-party APIs, AI services and the interfaces between your product and everything around it — with reconciliation and failure modes designed in, not discovered later.
Evidence
What this domain delivers
What we have shipped in this domain
- Payment and checkout integrations delivered inside Sonar — SEPA and card flows in a German banking-platform context. This is the proof section below.
- Third-party API and AI-service integration across our engagements: connecting products to external services, and wiring self-hosted model serving into live applications.
What we offer as capability
- UPI integration engineering for the Indian market — aggregator-based integration architecture, mandate/AutoPay flows and reconciliation patterns, engineered with the same discipline as our European payment work.
- API design and delivery: versioned contracts, error semantics and documentation built for the teams that will integrate against them.
- Reconciliation and failure design as a first-class deliverable — explicit state machines, idempotent operations and auditable end states.
Capabilities
What we do
API design and delivery
Designing the interfaces other teams build against: versioning, contracts, error semantics and documentation that survives being read by a stranger.
Payment and checkout integration
Gateway and PSP connections, checkout flows and reconciliation-friendly transaction design. See the payments section below.
AI-service integration
Putting model serving behind clean internal interfaces so a product can call ASR, translation or vision without knowing where it runs. The serving side is AI & model engineering.
Webhook and event handling
Idempotent receivers, replay tolerance, ordering assumptions made explicit, and dead-letter handling instead of silent loss.
Reconciliation and failure design
State machines that end in a definite, auditable state, so an operations or finance team can answer "what happened to this transaction?" without a database archaeologist.
Tech stack
- Payment gateway / PSP APIs
- REST and webhook integration
- event and queue handling
- AI-service interfaces (ASR, translation, vision)
- web platform integration
- containerized deployment
- CI/CD
- monitoring
Spotlight
Payments — the integration work we have taken furthest
Payments is where integration engineering stops being forgiving, so it is the honest place to show what this domain means in practice.
We have built payment and checkout integrations inside our long-term engagement with Sonar, connecting commerce flows into a platform used by German banks. That European platform context is where our production payment experience comes from — SEPA and card rails, integrated behind clean internal interfaces so a gateway can be replaced without rewriting the product.
How we engineer money paths. Idempotency and exactly-once semantics where the rails allow it; explicit failure states rather than optimistic happy paths; declines, partial failures, webhook replays and race conditions in the test plan from day one. Transaction records and states are structured so a finance team can actually reconcile them.
Card data stays out of scope. We design so raw card data never touches your servers — provider-hosted fields and tokenization keep you in the lightest PCI DSS posture (SAQ-A class) the provider supports. Where a stricter scope is unavoidable, we say so up front and design for it explicitly.
On UPI and India. We engineer UPI integrations the same way we engineer European rails: aggregator-based integration architecture, mandate/AutoPay flows and the reconciliation patterns that keep a collect request that expires and a mandate that debits on day 20 from becoming the same code path. The technical background is in our UPI/SEPA integration patterns article.
On naming providers. We work provider-agnostically: gateways and PSPs are evaluated against your market, pricing and feature needs, then integrated behind a clean interface so one can be replaced without rewriting the product. We name concrete gateways and PSPs, with context, in a direct conversation.
Method
How we work
-
Design for the failure case.
The interesting part of any integration is what happens when the other side is slow, wrong or absent. That is where we start.
-
Provider-agnostic boundaries.
We integrate behind clean internal interfaces, so a provider can be replaced without rewriting the product around it.
-
Reconciliation is a requirement, not a report.
If an operator cannot explain the state of a record from the data, the design is not finished.
-
Compliance posture inherited from banking work.
The same data-protection discipline we apply for financial-sector clients applies to integration data handling — see our security page.
FAQ
Frequently asked questions
What kinds of integrations have you actually delivered?
Payment and checkout integrations inside Sonar (SEPA and card rails, in a German banking-platform context), third-party API integrations across our product engagements, and AI-service integration wiring self-hosted model serving into live applications. The domain we go deepest in is payments — see the section above.
Have you done payment integrations in production?
Yes — payment and checkout integrations delivered inside Sonar, a video-consultation platform used by German banks, where we are the long-term engineering partner. Payment work in a banking-adjacent environment sets a high bar for correctness and data handling.
Can you integrate UPI for the Indian market?
Yes. We know the UPI landscape well (see our UPI/SEPA integration patterns article) and engineer UPI integrations end to end: aggregator selection, collect and intent flows, mandate/AutoPay handling and reconciliation, designed with the same rigor as our delivered European payment work.
Which payment providers can you integrate?
We work provider-agnostically: we evaluate gateways and PSPs against your market (India or Europe), pricing and feature needs, then integrate behind a clean interface so you are not locked in. We name concrete providers, with references, in a direct conversation.
How do you handle PCI DSS?
By keeping you out of the hard scope: we design integrations so raw card data never touches your servers — provider-hosted fields, tokenization, and minimal cardholder-data footprint. Where a stricter scope is unavoidable, we say so up front and design for it explicitly.
How do you handle failed or ambiguous transactions?
With explicit state machines, idempotent operations and webhook reconciliation — every transaction ends in a definite, auditable state. We design so your finance team can reconcile, not just so the happy path works.
Is integration data handled in a GDPR-compliant way?
Yes. We apply the same data-protection-first architecture we use for our financial-sector clients: minimal data retention, controlled flows, and no unnecessary third parties in the data path. Details of our operating model are on the security & data stewardship page.