Home / POS Payment Applications / Semi-Integrated Payments

Semi-Integrated POS Payments

In a semi-integrated setup your POS stays in charge of the sale and sends the amount to a payment terminal. The terminal's certified payment application reads the card and talks to the processor, and only the result comes back to the POS. We build the layer that makes that work: the payment adapter inside your POS, the connection to the processor's terminal interface, and the handling for the cases that go wrong.

Two Routes

Semi-Integrated vs. Your Own Terminal Application

Dimension	Semi-Integrated	Your Own Terminal Application
Terminal application	The processor's, already certified	Yours, built on the terminal vendor's SDK
L3 certification	Normally none for the POS integration	Required per terminal and scheme, with your acquirer
Card data	Stays between terminal and processor; the POS sees results only	Handled by your application on the terminal
Terminal choice	Limited to the processor's supported devices	Any terminal whose SDK you build on
Host connection	The processor's	Yours to build, often ISO 8583 to your switch
Best fit	An existing POS adding card payments through one processor	Custom payment flows, or your own acquiring host

Design Principle

Any Processor API, Any Terminal It Supports

In semi-integrated mode the processor's interface is the integration point, and the processor decides which terminals can sit behind it. Whichever processor you have chosen, and whichever of its terminals you deploy, we build your POS integration to its interface.

We build the POS side around the processor rather than the terminal brand. A payment adapter factored by processor, with terminal support arriving as a property of each processor, keeps working when you add a second processor or a second country.

What We Build

The Integration Layer, End to End

POS Payment Adapter

One internal interface in your POS for sale, refund, void and status, independent of which processor sits behind it.

Processor Connector

The integration to the processor's terminal interface: device pairing, sessions, prompts and transaction results.

Gateway & Reconciliation

Voids, transaction lookups and settlement reporting, which some processors serve from a separate gateway API.

Configuration Records

Merchant, store, lane, device, MID and TID kept as configuration, out of your business logic.

Where It Goes Wrong

Design for the Response That Never Arrives

In a semi-integrated POS the failure that matters is rarely a declined card. It is the indeterminate state: the terminal approved the transaction and the POS never heard back, because of a timeout, a dropped connection or an app restart mid-flow. It passes sandbox testing and appears in a live lane later. The remedy is a unique reference for every transaction, a status inquiry that can resolve any reference after the fact, and an automatic reversal when no response arrives within a set time.

Where we stop: we do not develop EMV L2 kernels, perform L1 or L2 certification, or undertake PCI or PTS compliance work. In a semi-integrated design those sit with the terminal vendor and the processor.

FAQ

Semi-Integrated Payments, Explained

What is a semi-integrated payment integration?

Your POS sends the sale amount to a payment terminal, the terminal's certified payment application handles the card and the connection to the processor, and the result comes back to the POS. Card data stays between the terminal and the processor, not in the POS.

Does a semi-integrated POS need EMV L3 certification?

Usually not. The terminal runs the processor's already-certified payment application, so connecting your POS to it does not add a new L3 campaign. Your processor may still require its own integration validation before go-live.

Which processors and terminals can you integrate with?

Any processor whose semi-integrated interface you use, and any terminal that processor supports. Send us the processor's API documentation and your terminal list, and we build the integration to it.

Does semi-integration reduce PCI DSS scope?

It usually does for the POS, because card data travels from the terminal to the processor and the POS only receives the result. Your actual PCI DSS scope still has to be confirmed with your acquirer or assessor; we do not undertake PCI compliance work.

What happens if the POS loses the response mid-transaction?

That is the case to design for. The integration needs a unique reference for every transaction, a status inquiry that can resolve that reference afterwards, and an automatic reversal when no response arrives in time, so the POS never charges twice or loses an approved sale.

Can you build our own terminal payment application instead?

Yes. If you need your own application on the terminal rather than the processor's, that is our POS payment application work, followed by L3 certification with your acquirer.

Keep Reading

POS Payment ApplicationsPayment Switch IntegrationL3 Certification & Testing