Payments, agentic commerce (AP2) and POS
Card payments, agentic checkout and stores connected from terminal to ledger
When stores, checkouts and the ledger disagree
A card payment touches several systems in a few seconds: the terminal or checkout, a gateway, the acquirer, the card scheme and the issuer. The money and fees arrive later in settlement files that someone has to match to the sales in your ERP.
When stores, online checkouts and the ERP sync in overnight batches, stock is oversold during promotions and settlement differences pile up across acquirers. Checkout slows at the busiest moments. Now AI agents are starting to buy on customers' behalf too.
What changes for you
One view of stock and sales
Sales, returns, prices and stock in step across every store, storefront and the ERP, in real time rather than overnight.
Settlements that match
Settlement and fee files from every acquirer matched automatically to sales, with differences listed for your team.
Ready for agentic commerce
A checkout that can accept payments from AI agents with a verifiable record of what the customer authorised.
What we deliver
Gateway, acquirer and card-network connectivity
Authorisation, capture, refund and reversal flows over ISO 8583, ISO 20022 or the provider's API, with multi-acquirer orchestration and every response code handled.
AP2 and cryptographic mandate checkout
AP2 is an open protocol that lets an AI agent pay on a customer's behalf. Cryptographically signed mandates record what the customer approved, and we integrate them into your checkout.
EMV and SoftPOS terminals
EMV chip and contactless terminals, and SoftPOS, which accepts contactless cards on an ordinary phone or tablet, connected to your POS or kiosk software.
Automated settlement file processing
Acquirer settlement and fee files collected, validated, audited and turned into postings your ERP can match.
Real-time POS-to-ERP sync
Sales, returns, pricing, promotions and stock levels synchronised between every store and the ERP through an event-streaming layer.
Tokenisation and PCI DSS scope
Card numbers replaced with tokens and kept out of your POS and ERP, with a written view of which systems remain in PCI DSS scope.
Certification and roll-out
Test scripts and evidence for each provider's certification, a pilot in a few stores, then a store-by-store roll-out with daily totals compared.
How we work
Follow one sale
We follow a sale from the till or checkout to the ledger with your finance, store and IT teams, and agree the scope.
Design the integration
We choose the protocols, tokenisation approach and message flows, and write the interface specification.
Build and test
We build the payment, settlement and POS flows with automated tests, including declines, timeouts and refunds.
Certify with the provider
We run the provider's test cases in its test environment and fix what its certification finds.
Pilot, then roll out
We go live in a few stores or channels first, compare totals daily, and then roll out store by store.
Monitor and support
We watch approval rates, settlement files and store postings, and handle provider changes as they are announced.
Scroll sideways to see the whole drawing.
Card payments: authorised at the till, settled later, reconciled in the ERP
The terminal or checkout asks the gateway, the gateway asks the acquirer, and the acquirer routes to the card scheme and issuer. Settlement files arrive later and are matched to sales and fees in the ERP. A timeout triggers a reversal so the customer is never charged twice.
- Primary flow
- Asynchronous
- Exception path
The flow in 8 steps
The flow, step by step
- From EMV terminal or online checkout to Payment gateway: Authorisation request, over EMV · REST/JSON (primary flow).
- From Payment gateway to Acquirer: Authorisation, over ISO 8583 (primary flow).
- From Acquirer to Card scheme and issuer: Routed to the issuer, over ISO 8583 (primary flow).
- From Acquirer to Payment gateway: Approved or declined, over ISO 8583 (asynchronous).
- From Acquirer to Integration layer: Settlement and fee files, over SFTP (asynchronous).
- From Integration layer to ERP: Settled sales, fees and payouts, over REST/JSON (primary flow).
- From Payment gateway to EMV terminal or online checkout: No response in time: automatic reversal, over ISO 8583 0400 (exception path).
- From Integration layer to Payments operations team: Settlement mismatch or chargeback (exception path).
Scroll sideways to see the whole drawing.
POS to ERP: every sale posted once
Sales flow from the tills to the ERP as events, and prices and stock flow back. A store that goes offline keeps selling and catches up. A posting that fails is retried, then handed to a person.
- Primary flow
- Asynchronous
- Exception path
The flow in 8 steps
The flow, step by step
- From POS terminals to Store or POS cloud server: Sales, returns and voids (primary flow).
- From Store or POS cloud server to Integration layer: Sales events and end-of-day totals, through an event queue, over REST/JSON (asynchronous).
- From Integration layer to ERP: Sales and stock movements posted, over OData · REST/JSON (primary flow).
- From ERP to Integration layer: Prices, promotions and item data, by API or file export, over REST/JSON (primary flow).
- From Integration layer to Store or POS cloud server: Price and stock updates, over REST/JSON (primary flow).
- From Integration layer to Retry queue: Posting failed (exception path).
- From Retry queue to Integration layer: Retried (exception path).
- From Retry queue to Store operations team: Still failing: alert with the details (exception path).
Standards and protocols
Naming a product or a provider does not mean a partnership with it.
- Languages
- Go
- Frameworks
- Node.js
- Data and analytics
- Apache Kafka
- Databases
- Redis
- DevOps and observability
- Kubernetes
- Banking standards and channels
- ISO 20022
- Payments
- ISO 8583
- EMV
- EMV 3-D Secure
- PCI DSS
Proof in production
For a multi-brand GCC retail and mall group, we replaced overnight batch scripts with real-time POS-to-ERP sync. We also unified multi-acquirer payments with automated settlement, and built an inventory reservation service for flash-sale peaks.
How to start
Clear provider and store requirements go straight to a proposal. A new payments platform, or an agentic checkout, usually starts in the Blueprint Studio.
What happens next
Pre-consulting session
A free 30-minute online pre-consulting session: we go through your goals, systems and constraints.
Readiness review
In a free 48-hour readiness review, a Principal Architect checks your project against the 6-point Definition of Ready and recommends the track that fits.
Choosing the track
Scope-ready projects receive a binding proposal within 3–5 business days. Concept-stage projects start in the Blueprint Studio. A live system that is failing, undocumented or needs integration starts with a diagnostic of 1–2 weeks. The Blueprint Studio and the diagnostic each have a fixed fee, quoted in the proposal.
Delivery in five stages
Mobilisation, sprints with live demonstrations, integration and hardening, acceptance and go-live, then managed services. After launch comes a warranty period, then optional support and maintenance.
AI-native product teams
Managed, cross-functional pods of senior engineers, equipped with agentic coding and QA harnesses.
Fixed-outcome projects and round-the-clock managed services
Fixed-scope, milestone-driven delivery with named delivery leads, and round-the-clock application managed services under SLA governance.
Questions and answers
Do you work with ISO 8583 directly?
Yes, where the acquirer or processor offers it. ISO 8583 is a framework rather than one format: each acquirer publishes its own specification of fields and message types. We build from that specification, handle authorisations, reversals and advice messages, and test every response code.
What is AP2, and do we need it now?
The Agent Payments Protocol (AP2) is an open protocol for payments made by AI agents. Each purchase carries signed mandates showing what the customer authorised, so merchants, issuers and acquirers can trust and audit it. If AI agents are likely to shop with you, we can make your checkout AP2-ready alongside your current flows.
How do you reduce our PCI DSS scope?
We cannot remove PCI DSS, but we can reduce how much of your estate it applies to. Hosted payment pages, point-to-point encryption at the terminal and gateway tokens keep card numbers out of your POS, ERP and data warehouse. We document the data flows for your assessor.
Can we accept cards on phones instead of terminals?
Yes, with SoftPOS. Contactless cards and wallets are accepted on a supported phone or tablet through a certified payment app from your acquirer or provider. We integrate that app with your POS, sales and settlement flows like any other terminal.
What happens when a store loses its connection?
The store keeps selling. Sales are stored locally and sent to the ERP when the connection returns, each with a unique identifier so nothing is posted twice. Whether card payments can continue offline depends on your acquirer's rules and your risk appetite, and we design that with you.
Do you handle refunds and chargebacks?
Yes. Refunds and reversals are part of the payment flows we build. For chargebacks, we import the acquirer's dispute reports and link each one to the original sale and settlement. Your team gets a list to work through, with the evidence attached.
Ready to build? Ask for a proposal.
Send your requirements or RFP. Our architects validate them and return a binding, fixed-scope proposal.
What happens next
Readiness review
In a free 48-hour readiness review, a Principal Architect checks your project against the 6-point Definition of Ready and recommends the track that fits.
Binding proposal
After architecture validation at no cost, you receive a binding, fixed-scope proposal within 3–5 business days: milestones, architecture, team structure and SLAs. We sign a non-disclosure agreement (NDA) with you on request, before you share your requirements.
Mobilisation
Once you sign, our engineering pods begin Sprint 0 within 5–10 business days of contract signature.
Delivery in five stages
Mobilisation, sprints with live demonstrations, integration and hardening, acceptance and go-live, then managed services. After launch comes a warranty period, then optional support and maintenance.