Custom payment integration services with smart routing, automatic fallback, and unified reconciliation. Proven at a $1B+ unicorn across 15+ markets and 40+ providers.
- Scope
- Ship
- Iterate
monthly subscription
Who this is for
You're a CTO or technical founder whose product has outgrown a single payment provider. Routing logic is bespoke code nobody wants to touch. PCI-DSS audits turn up gaps. Reconciliation between providers, your ledger, and the bank still takes someone a full day each month. I build the payment integration layer that replaces all of that: a single orchestration surface your product talks to, not forty.
The pain today
- One provider failing mid-peak with no fallback in place
- Each new market requiring a separate integration built from scratch
- Reconciliation across providers taking days of spreadsheet work
- PCI-DSS audits finding gaps in 3DS or SCA handling
- No single view of decline rates, fees, or chargeback ratios across providers
The outcome you get
- Single payment API your product code calls, regardless of which provider executes
- Rule-based routing by geography, currency, success rate, and cost
- Automatic failover when a provider declines or times out
- PCI-DSS SAQ A architecture — tokens everywhere, raw card data nowhere
- Unified reconciliation running daily: provider vs ledger vs bank, automatically
What payment integration services actually cover
Payment integration services means building the layer between your product and the providers you accept money through. At the simple end, that's one Stripe integration. At the complex end — the one I've built — it's an orchestration layer across 40+ providers, handling routing, retries, tokenization, compliance, and a reconciliation pipeline. The common thread in every custom payment processing integration I do: your product code should never know which provider is running underneath. It calls a single API. Everything else is the orchestration layer's job.
The pattern works because it separates concerns that tend to get mixed up in DIY builds. Provider-specific logic (auth flows, error codes, webhook schemas) lives in isolated adapters. Routing rules live in configuration, not in application code. Compliance (PCI-DSS, SCA, 3DS) is handled at the orchestration layer, not scattered across your product. That separation is what makes adding a new provider a 2-week task rather than a 2-quarter rewrite.
Single payment API your product code calls, regardless of which provider executes
Provider selection and when to add another one
Adding a second or third payment provider is almost always the right call for a business selling across geographies. Local acquiring matters: a card issued in Thailand processed through a US acquirer will decline at a meaningfully higher rate than the same card through a Thai acquirer. The business case for a regional provider is usually a 5–15 percentage point improvement in authorization rates in that market.
That said, every new provider has a maintenance cost: a new webhook schema to parse, a new error-code mapping to keep current, a new reconciliation feed to monitor. My honest rule: if a market generates enough transaction volume to justify the ongoing integration cost, add a dedicated provider. If not, a global acquirer with local acquiring agreements (Adyen, Stripe, Worldpay) usually does the job. At bolttech, 40+ providers across 15+ markets made sense for a $1B+ unicorn with direct relationships in every country. Most businesses get 90% of the benefit with three providers done well.
40+: Payment providers integrated.
Routing, retries, and failure modes
Three failure modes are worth designing for explicitly. Hard declines — the issuer says no — typically cannot be retried on a different provider without re-authorizing the customer. Soft declines (insufficient funds, do-not-honor codes) can be retried after a delay, sometimes on a different provider. Timeouts are the most operationally important: if a provider stops responding, you want to retry on a secondary provider immediately, invisibly to the customer.
The routing engine handles this with priority lists per geography and currency, a real-time health check per provider (success rate in the last 60 minutes), and configurable retry behavior by failure type. Cost routing sits on top of this: for markets where multiple providers have similar authorization rates, the engine can prefer the lower-cost option (interchange-plus vs blended pricing differences add up at volume). None of this is magic — it is configuration, and configuration that can be updated without a deploy.
Compliance: PCI-DSS, SCA, 3DS2
PCI-DSS is the compliance floor, and the goal is keeping your scope at SAQ A — the shortest self-assessment questionnaire, reserved for merchants where all card data entry is handled entirely by a third-party provider. Practically: use hosted payment fields (Stripe Elements, Adyen Web Components, Braintree Drop-in) so raw card numbers never touch your servers. Your application handles tokens only. SAQ A scope keeps your annual audit to a two-page questionnaire instead of a multi-week QSA engagement.
SCA and 3DS2 are the EU's authentication requirements. Any EU transaction above €30 requires a strong customer authentication challenge unless an exemption applies (transaction-risk analysis exemption, recurring transaction exemption, low-value exemption). The orchestration layer applies the right exemption request per transaction type and handles the 3DS2 challenge redirect when the issuer requires it. Getting this wrong means declined transactions on legitimate EU purchases — a quiet revenue leak that often goes unnoticed until someone pulls the data.
Reconciliation and ledger architecture
Every payment transaction lives in three places: the provider's settlement report, your internal ledger, and the bank statement. Reconciliation is proving these three agree, currency by currency, every day. The places they fail to agree are informative: partial captures the ledger missed, chargeback entries that arrived before the original transaction cleared, currency conversion differences, provider interchange fees not allocated per transaction.
I build a double-entry ledger with daily reconciliation jobs per provider. Each job fetches the provider's settlement file, matches entries against the ledger, and raises alerts when differences exceed a configurable threshold. Chargebacks and disputes arrive via webhook and update ledger state immediately. The finance team gets a dashboard that shows reconciliation status by provider by day. Month-close goes from a multi-day spreadsheet to a verification exercise. It is not glamorous work. It is the part that makes a payment platform actually trustworthy to the finance function.
How the bolttech payment integration ran
At bolttech I led the Payment Service that integrated 40+ providers across 15+ international markets. bolttech is a $1B+ unicorn in the insurtech space, and payments were core infrastructure: every policy purchase in every market ran through this service. The platform reached 99.9% uptime. Zero post-launch critical bugs on the Payment Service across the full rollout.
The architectural pattern that made the scale work: a provider-agnostic orchestration interface, per-provider adapters implementing a shared contract, a unified tokenization vault so a card stored against one provider could be replayed through another, and daily per-provider reconciliation. Adding a new market meant implementing one adapter — the core routing, tokenization, and ledger logic stayed unchanged. New providers went live in roughly 2 weeks once the framework existed. Those same patterns are what I apply to smaller payment integration builds. Transaction volume and provider count change. The architecture doesn't.
Testing before going live
Payment integration testing is one of the places where I see the most DIY shortcuts become production incidents. Most providers offer sandbox environments with test card numbers that simulate specific response codes — approved, declined, 3DS required, insufficient funds, timeout. A thorough payment API integration test suite covers each of these for each provider, plus edge cases: partial captures, refunds against partially-captured transactions, chargebacks arriving on the same day as the original settlement, webhook delivery failures and replay.
Beyond provider sandboxes, I run a load test against the routing layer before production launch — specifically simulating the provider-timeout scenario to confirm failover behavior works under real latency conditions. Contract tests between the product's payment API and the orchestration layer catch breaking changes before they reach production. These aren't optional extras — they are the difference between a confident go-live and a 2 a.m. incident in the first week.
Scope and what I don't do
I build payment integration infrastructure: the orchestration layer, provider adapters, tokenization, routing, reconciliation pipeline, and compliance architecture. I do not custody funds, operate as a payment facilitator, or hold PCI certification on your behalf. The SAQ A architecture I build lets you self-certify under the shortest questionnaire — you own the audit, I provide the architecture and supporting evidence.
I don't add providers without a clear volume justification. Each new integration has ongoing maintenance cost, and the honest advice is usually fewer providers done well. I don't replace your finance function — the reconciliation tools I build get operated by your team. Drawing these lines keeps the project scoped to real value.
Recent proof
A comparable engagement, delivered and documented.
Unified payment orchestration across Asia and Europe
Delivered the payment orchestration platform at bolttech, a $1B+ unicorn, with 40+ integrations across multiple regions.
Read the case studyFrequently asked questions
The questions prospects ask before they book.
At bolttech: 40+ across Asia and Europe, including Stripe, Adyen, and regional providers per market. On other projects: Stripe, Adyen, Square, PayPal, Braintree, Razorpay, and regional LatAm providers. New providers follow the same adapter pattern — typically 2 weeks per provider once the orchestration layer is in place. The adapter interface is the same regardless of provider, so each new one is an implementation exercise, not an architecture decision.
By building with provider-hosted payment fields (Stripe Elements, Adyen Web Components, Braintree Drop-in). Card data goes from the browser directly to the provider's infrastructure. Your application receives a token, not a card number. This keeps your PCI scope at SAQ A — the shortest compliance questionnaire available. Your servers never see, transmit, or store raw card data, which is both the security goal and the compliance goal.
Yes. The routing engine supports layered rules: primary routing by geography and currency for local acquiring benefits, secondary routing by provider success rate using real-time data from the last 60 minutes, and tertiary routing by cost when multiple providers have comparable authorization rates. All routing rules are configuration — no deploy needed to adjust weights or add a new rule. That means your operations team can tune routing in response to a provider outage without touching code.
A first version with 2 providers, PCI-compliant architecture, and basic reconciliation typically takes 6 to 8 weeks. Each additional provider adds roughly 2 weeks on top of that once the orchestration framework is built. Complex compliance requirements (SCA for EU, regional licensing dependencies) can extend the timeline. Most customers continue on the monthly subscription after the initial build to expand to new markets and providers — the average cadence once the framework is established is one new provider every 4 to 6 weeks.
Platform services give you routing and provider connectivity faster, at the cost of a per-transaction fee, vendor lock-in, and constraints on how deeply you can customize behavior. Custom orchestration trades faster initial deployment for full control over routing logic, tokenization vault ownership, reconciliation design, and no transaction-based pricing. At bolttech's scale — 40+ providers across 15+ markets — custom was clearly right. For a business early in its multi-provider journey, the decision usually comes down to transaction volume and the degree of control you need over routing and data.
Each provider's dispute webhook feeds the internal ledger with the dispute state immediately on receipt. Evidence submission goes through a standardized admin workflow that pulls the original transaction record, shipping data, and any fraud-signal logs. Chargeback-ratio monitoring per provider alerts when a provider's ratio approaches thresholds that trigger penalty tiers or account reviews. The unified view across providers is what gives your ops team actionable information — most teams working with multiple providers separately only discover a ratio problem after the provider has already flagged the account.
Yes, where transaction volume justifies the integration cost. BNPL providers (Klarna, Afterpay, Affirm) integrate through the same orchestration adapter pattern as card providers. Crypto payments via Stripe or dedicated providers (Coinbase Commerce) work the same way. The honest filter: I scope APM integrations against actual transaction volume. A crypto payment option generating $8k/mo in volume is not worth a custom integration and its ongoing maintenance. At $500k/mo it usually is.