Skip to content
XSIS
A card is used at a payment terminal

Enterprise Applications & Integration

Commerce and Payments

Every sale, stock move and settlement on one record.

Why It Matters

A card payment touches the terminal, a gateway, an acquirer and the issuer in a few seconds. The money and fees arrive later in files someone must match to the sale.

The work fails in three ways. Stores and the ERP sync overnight, settlement files pile up across acquirers, and card data sits in systems that should not hold it. We move sales and stock in real time, match each settlement to its sale, and keep card numbers out of your estate.

What We Do

  • We connect your storefront, checkout and order management so prices, stock and orders follow one set of rules.

  • We connect the payment providers that serve your markets and handle authorisations, refunds and reversals for each one.

  • Store terminals use the same prices, promotions and stock as the online store, and each sale reaches the ERP once.

  • Stock, orders and prices move between stores, online and the ERP in real time, with failed updates retried and shown.

  • We collect settlement and fee files from each acquirer, check them against sales, and list every difference for your team.

What Changes for You

  1. Sales, returns, prices and stock stay in step across stores, online and the ERP, with a current view rather than last night's.

  2. Settlement and fee files from each provider are matched to sales, and differences reach your team with the evidence.

  3. The checkout can accept a payment from an AI agent, and a signed mandate records what the customer approved.

Systems We Connect

We connect the places you sell to the providers that take the money and the ERP that holds the record.

  • Stores and Terminals

    Terminals use the same prices, promotions and stock as the online store.

  • Online Checkout

    The storefront sends each order and payment to the same record as a store sale.

  • Payment Providers

    We connect each acquirer and gateway through the interface it supports, including refunds and reversals.

  • The ERP

    Sales, stock and settlement postings reach the ledger once, with a reference back to the sale.

How It Connects

One drawing follows a sale from a terminal to the ERP. The other follows a card payment through its provider to settlement.

POS to ERP: Every Sale Posted OnceSales 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.POSPOS terminalsEvery till in everystoreData storeStore or POS cloudserverKeeps selling whileofflineXSISIntegration layerEvent queue,mapping, duplicateprotectionERPERPSales, inventory andfinanceServiceRetry queueRetries with back-off,then a dead-letterqueuePeopleStore operationsteam12REST/JSON3OData · REST/JSON4REST/JSON5REST/JSON678

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

  1. From POS terminals to Store or POS cloud server: Sales, returns and voids (primary flow).
  2. From Store or POS cloud server to Integration layer: Sales events and end-of-day totals, through an event queue, over REST/JSON (asynchronous).
  3. From Integration layer to ERP: Sales and stock movements posted, over OData · REST/JSON (primary flow).
  4. From ERP to Integration layer: Prices, promotions and item data, by API or file export, over REST/JSON (primary flow).
  5. From Integration layer to Store or POS cloud server: Price and stock updates, over REST/JSON (primary flow).
  6. From Integration layer to Retry queue: Posting failed (exception path).
  7. From Retry queue to Integration layer: Retried (exception path).
  8. From Retry queue to Store operations team: Still failing: alert with the details (exception path).
Card Payments: Authorised at the Till, Settled Later, Reconciled in the ERPThe 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.POSCard terminal oronline checkoutChip, contactless ande-commerceGatewayPayment gatewayTokenisation androutingBankAcquirerAuthorisation andsettlementThird partyCard scheme andissuerApproves or declinesERPERPSales, fees andpayoutsXSISIntegration layerSettlement parsingand matchingPeoplePaymentsoperations teamMismatches, disputesand chargebacks1EMV · REST/JSON2ISO 85833ISO 85834ISO 85835SFTP6REST/JSON7ISO 8583 04008

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

  1. From Card terminal or online checkout to Payment gateway: Authorisation request, over EMV · REST/JSON (primary flow).
  2. From Payment gateway to Acquirer: Authorisation, over ISO 8583 (primary flow).
  3. From Acquirer to Card scheme and issuer: Routed to the issuer, over ISO 8583 (primary flow).
  4. From Acquirer to Payment gateway: Approved or declined, over ISO 8583 (asynchronous).
  5. From Acquirer to Integration layer: Settlement and fee files, over SFTP (asynchronous).
  6. From Integration layer to ERP: Settled sales, fees and payouts, over REST/JSON (primary flow).
  7. From Payment gateway to Card terminal or online checkout: No response in time: automatic reversal, over ISO 8583 0400 (exception path).
  8. From Integration layer to Payments operations team: Settlement mismatch or chargeback (exception path).

Go-Live and Switch-Over

Each stage has a check your teams can see. The old route stays open until the new one passes it.

  1. Follow One Sale

    You walk us through a sale from till to ledger. We agree the first channel and the checks that will prove it.

  2. Certify With Providers

    You provide test accounts and a named contact at each provider. We run their test cases and fix what they find.

  3. Pilot in a Few Stores

    A small group of stores goes live first. Your store and finance teams compare daily totals.

  4. Roll Out Store by Store

    You decide the order of the remaining stores. Each one goes live after its totals match.

  5. Watch the First Settlement

    We follow the first settlement cycle with your finance team. Every difference is fixed before the cycle closes.

Compliance in Every Market

Payment and tax rules differ by market. We keep card data and settlement evidence in one controlled layer.

Card numbers stay out of your systems, and each payment keeps a record of what the customer authorised. Market-specific formats sit at the edge. A change there does not touch the sale record.

Read the Country Guides

Platforms and Technologies

ISO 8583 is the message format card acquirers use for authorisations and reversals. ISO 20022 is the newer payment message standard. EMV is the chip and contactless standard, and EMV 3-D Secure adds a check during an online payment. SoftPOS lets a phone accept a contactless card. PCI DSS is the card-data security standard. AP2 is an open protocol for payments made by AI agents with signed mandates. REST is the common web interface, and webhooks let a provider send an event. SFTP is a secure file channel for settlement files, and Apache Kafka carries events between stores and the ERP. Go is a programming language we use for high-volume payment and stock services.

Languages
  • Go
Data and analytics
  • Apache Kafka
Banking standards and channels
  • ISO 20022
  • SFTP (H2H)
Payments
  • ISO 8583
  • EMV
  • EMV 3-D Secure
  • SoftPOS
  • PCI DSS
  • Agent Payments Protocol (AP2)
Integration
  • REST
  • Webhooks

Naming a product does not mean a partnership with its vendor.

Questions

The questions retail and finance teams ask before they change payments.

Can we keep our current acquirers and terminals?

Yes, if they support the connection you need. We confirm each provider's interface, certification rules and settlement files first. We replace a provider only when the current one cannot meet the requirement.

How do we start?

We follow one sale from the till or checkout to the ledger. Your store and finance teams show us where it breaks. We then agree the first channel, the first provider and the checks that will prove it works.

Who owns the payment integration?

You do. The interface code, settlement rules and runbooks are yours at hand-over. The acquirer still owns its network and rules. We document the boundary so each side knows its responsibility.

What drives the cost?

The number of channels, providers and store formats, the certification each provider requires, and the state of the stock and settlement data. Provider fees are separate. We estimate by channel so you can go live in steps.

What is not included?

Terminals, card processing and network services are bought from their providers. We do not set your prices or credit rules. We list those dependencies in the plan, with the owner of each one.

Visit the Knowledge Base

Tell Us What You Need to Run, Build or Secure.

Describe the service, the systems and the pressure you are under. The right team takes it from there.