For payment stacks that stay out of card-data scope
Payment Gateway & Payments Software Development
A payment flow that works in the sandbox and fails at settlement is the most expensive kind of working software. This practice builds gateway integrations, orchestration, wallets and the reconciliation and dispute machinery behind them, with PCI DSS 4.0 scope, PSD2 authentication and ISO 20022 messaging treated as design inputs. We build and integrate the stack; we are not a payment service provider.
Keeping a payments product out of card-data scope
Tokenisation, provider integration and the line between building a stack and being a PSP.
90 secSample frame · video pending01Before choosing between one provider and many
One gateway or orchestration is a real decision, not a preference.
Adding an orchestration layer too early buys complexity nobody needs; staying on one provider too long buys outages and fees nobody notices. Four questions settle which stack a product should carry now.
Does volume justify routing?
Routing by cost or approval rate only pays off once transaction volume across markets is large enough for the savings to exceed the engineering and operations cost.
How far into PCI scope is your product?
Hosted fields and tokenisation keep most products at the lightest self-assessment level. Handling raw card numbers anywhere pulls the whole platform into a heavier assessment.
Which SCA exemptions can you use?
Transaction risk analysis, low-value and merchant-initiated exemptions under PSD2 shape approval rates, and using them well depends on the acquirer and provider you have.
Where does settlement actually break today?
Most payment pain lives after authorisation: settlement files that never match, refunds that cross a batch boundary, disputes handled late. Fix that before adding providers.
| Single gateway | Orchestration layer | |
|---|---|---|
| Integration effort | One provider API and its webhooks | Abstraction across several providers plus routing |
| Failover | Depends on the provider's own uptime | Retries through a second provider by rule |
| Token portability | Tokens locked to one provider | Vault-level tokens usable across providers |
| Best fit | Single market, early volume | Multi-market volume with fee or approval pressure |
02Agreed before the first transaction
The ledger that keeps a payments build honest
Payments engagements go wrong when the line between building a stack and operating as a payment provider is assumed rather than agreed. This ledger fixes what you bring, what gets built, what you receive, and which obligations stay with you and your licensed providers.
- Your side
You bring
- The checkout and settlement flows the product needs to support
- Your provider accounts with Stripe, Adyen or Braintree
- The markets, currencies and payment methods in scope
- Our side
We build
- A gateway integration with tokenised card capture that keeps card data off your servers
- Webhook handling, idempotency and retry logic for every payment state
- 3-D Secure 2 challenge flows with SCA exemption logic under PSD2
- Your side
You receive
- A production payment flow tested against provider sandboxes and failure states
- A PCI DSS 4.0 scope statement showing what your systems never touch
- Reconciliation between provider settlement files and your ledger
Never leaves you
- The merchant agreement and the relationship with the provider
- Pricing, refund and dispute policy
- The decision on which payment methods to switch on
Where the line sitsWe integrate the gateway; the provider processes the payment and holds the acquiring relationship. Your product stays outside card-data scope by design.
03From provider sandbox to reconciled settlement
Four stages, each closing on a reconciled result
Payment builds that fail after launch usually skipped a failure-state test or a reconciliation check here. This system closes each stage with evidence a finance lead could examine.
Map the payment flows and the PCI scope
Every flow, method and market is mapped with the resulting PCI DSS 4.0 scope written down, so the assessment level is chosen rather than discovered.
Scope settled with the assessor in mindIntegrate and test against provider sandboxes
Authorisation, capture, refund, retry, timeout and webhook-replay paths are tested against each provider's sandbox before a live key exists.
Built against every failure stateTune 3-D Secure 2 and SCA handling
Challenge, frictionless and exemption paths are configured and measured on real traffic samples, so strong authentication protects approval rates instead of eroding them.
Authentication tuned, not just enabledReconcile settlement and rehearse disputes live
Settlement files are reconciled to the ledger through a parallel period, and the dispute workflow is rehearsed against real chargeback deadlines before cutover.
Settlement matched before go-live
04Where the estimate moves
Four drivers, priced from the flow map
Payments work is priced from the flow map, because these four factors change the scope by multiples from one product to the next.
Number of providers, methods and markets
One provider in one market with cards only is a bounded integration. Several providers, local methods and currencies multiply the test matrix and the reconciliation rules.
PCI DSS scope your architecture accepts
Staying behind hosted fields and tokens keeps the assessment light. Any component that touches raw card data brings segmentation, scanning and evidence work with it.
Depth of settlement and dispute automation
A daily reconciliation with explained breaks costs more to build than a nightly report, and chargeback evidence automation adds scope beyond a manual dispute queue.
Legacy ledger and core integration
Writing settlement into an ageing ledger or a core banking connection costs more than feeding a new product's own accounting model.
05Evidence and proof
Settlement that matched the ledger once real money moved.
Payments proof is a settlement figure that reconciles and a PCI scope statement an assessor accepted. Each record is a placeholder and waits for written client approval before production.
Explore case studiesA checkout moved behind tokenised capture without losing approval rate.
A merchant platform handled card numbers in its own forms and faced a heavier PCI assessment. Moving capture to hosted fields and tokens, with 3-D Secure 2 tuned per market, reduced scope while approvals held.
- PCI DSS assessment scope
- Reduced
- Approval rate after SCA tuning
- Held steady
Settlement reconciled daily, with every break assigned to a person.
A payments platform reconciled settlement files by hand and found breaks weeks late. A reconciliation engine matched settlement to ledger daily and explained each unmatched item, with disputes tracked against their deadlines.
- Time to detect a settlement break
- Weeks to same day
- Disputes missed past deadline
- None after launch
For the first time our finance team trusted the settlement number before the bank statement arrived.
Sample · pending client approval
06Read this first
When payments engineering is the wrong first step
If the real need is a licence, an acquiring relationship or a merchant account, engineering will not supply it, and the honest exits are marked here. Once the providers are contracted, the work runs on their APIs with standard vaulting, orchestration and reconciliation patterns.
You want to become a licensed gateway or acquirer
Licensing, scheme membership and acquiring are regulatory and commercial undertakings, not software builds. We integrate with licensed providers; we do not stand in for one.
- FinTech
You need a merchant account, not an integration
A product that only needs to accept payments should sign up with a provider directly. Engineering starts once the provider agreement and the flows are known.
- Team extension
You need payments engineers inside your own team
If your team already owns the provider relationships and the payments roadmap, team extension fits better than a commissioned build.
| Shape | Best when | You direct | We carry |
|---|---|---|---|
| Scoped build | Providers are contracted and flows are known | Provider choice and payment policy | Integration, testing and reconciliation |
| Delivery pod | Methods and markets will keep expanding | Product and finance priorities each cycle | Engineering, monitoring and dispute tooling |
| Team extension | Your leads own the payments roadmap | Architecture and provider standards | Named engineers and continuity |
07Straight answers
Asked before a payments build is approved.
01Are you a payment gateway or a payment service provider?
No. We build and integrate payment software against licensed providers such as Stripe, Adyen or Braintree. The provider processes the payment and holds the acquiring relationship; your product and our work stay outside that licence.
02How do you reduce PCI DSS 4.0 scope?
By keeping card data with the provider: hosted fields, network tokens and a vault the application never reads raw numbers from. The resulting scope statement is written for your qualified security assessor to review, not asserted by us.
03How does 3-D Secure 2 affect approval rates?
Badly when every transaction is challenged, and well when frictionless flows and PSD2 exemptions are used correctly. We tune challenge and exemption logic on real traffic samples and measure the result per market.
04Can you route transactions across several providers?
Yes, through an orchestration layer that routes by rule, cost or provider health and fails over without double charging. Tokens are vaulted so a saved payment method still works when the route changes.
05Do you handle ISO 20022 messaging?
Where bank or scheme rails require it. Messages are modelled so remittance and party data reach reconciliation intact, which matters most when settlement runs across several banking partners.
06What happens when settlement does not match the ledger?
The reconciliation engine explains the break, assigns it to a person and keeps it visible until resolved. Deciding whether to adjust, contest or write off remains a finance decision you make.
07How long does a payment gateway integration take?
It depends on providers, methods and markets in scope. A single provider with cards and wallets moves quickly; orchestration across providers with local methods and daily reconciliation takes longer to test properly.
08What does payment software development cost?
Cost is priced from the flow map: provider count, PCI scope accepted, reconciliation depth and ledger integration. A hosted-fields checkout costs far less than an orchestration layer with dispute automation.