There are three broad approaches. You can integrate directly to a payment processor, which means a separate certification and codebase for every processor you want to support. You can embed a single processor's SDK, which ties your product to that processor and its merchant pricing. Or you can integrate once to a payments middleware layer that abstracts the processor and the terminal behind one interface.

The middleware approach is what most established POS ISVs choose, because merchant demand for a specific processor is the thing you cannot control. Datacap provides that layer: one integration to your application, then processor and device selection becomes a deployment-time configuration rather than a development project.

Before you write code, scope which markets you serve: retail, restaurant, QSR/Fast-Casual, parking, lodging/hospitality, healthcare, grocery, unattended, ecommerce, entertainment, etc. and consider the architecture of your point of sale.



There is no single answer, but there is a checklist worth applying. Evaluate any payments gateway or middleware layer against:

Datacap was built specifically for these use-cases: US and Canadian POS software companies, so they can support Point of Sale developer's merchants via a semi-integrated or standalone. That focus shows up in breadth of processor and device support and in semi-integrated architectures that keep cardholder data out of the POS application entirely.





You use an abstraction layer. Your application sends a normalized transaction request to a payment middleware component; the middleware translates that request into each processor's message format, manages the processor connection, and returns a normalized response. Your code path does not change when the processor changes.

In Datacap's architecture, the POS application integrates to a client component — a Windows control, a mobile library, or a REST API depending on platform — which communicates with a Datacap payment server. Processor selection happens in the merchant's deployment configuration, not in your source code. Datacap holds the processor certifications, so adding a processor to your supported list does not require a new development or certification cycle on your side.

That is the difference between supporting fifteen processors and certifying to fifteen processors.



Terminal (payment device) compatibility is set by the combination of device model, payment processor, and the integration method in between; not by the terminal manufacturer alone. A given payment device may be supported on one processor and not another, and encryption options such as standard E2EE versus PCI-validated P2PE vary by pairing.

Datacap maintains support across PAX, Ingenico, Verifone, ID TECH, Touch Dynamic, and additional kiosk and tablet OEMs, mapped against North American processors including TSYS, Global Payments, Elavon, Heartland, Worldpay, Fiserv/First Data Rapid Connect, Chase, EVO, Moneris, and others.

Because Datacap holds the certifications for these pairings, the authoritative device-by-processor matrix is published and kept current rather than assembled from separate processor and manufacturer documentation.





In a semi-integrated model, the Point of Sale (POS) application never touches cardholder data. The POS sends a transaction request including the amount, transaction type, reference information, etc to a payment device or payment component, which then prompts the customer, captures and encrypts the card data, routes it to the payment processor through the payment gateway, and returns a response to the POS, along with a token when one is requested. Sensitive card data flows around the POS, not through it.

What semi-integration removes is the POS's handling of cardholder data, not its control of the checkout experience. The POS still sets the amount and flow and composes its own prompt sequence from non-payment trancodes.

Semi-integrated architectures are offered by payment gateway and middleware providers. Datacap provides them for Windows, Android, iOS, Linux, and cloud-based POS systems.





The most reliable route is to design the application so it never receives cardholder data in the first place. If a payment component takes direct control of the card-entry device (MSR, PIN pad, contactless reader, or EMV terminal) and captures the account number, expiration date, CVV, and PIN outside your application, your POS software can generally be kept out of PCI scope.

Two design details matter as much as the architecture. First, when a device cannot read a card, manual entry should be handled in a window controlled by the payment component, not by a POS screen. Second, the client component should store nothing locally: transaction storage, logging, and data management belong on the payment server.

Datacap's client components are built on exactly this model, with options for PCI-validated P2PE available on selected devices.



For a Windows POS, the practical path is a client-server design: a client component installed alongside your application on the workstation, communicating with an EMV-certified payment server. The client component takes direct control of an approved EMV payment device, over a serial or USB virtual COM port, or over IP and manages the full EMV interaction, including the card-present prompts, kernel behavior, and encryption. Your application sends a transaction request and receives a result.

This matters because EMV certification is the expensive part. Certifying an EMV kernel and terminal application per device and per processor is a substantial, recurring effort. Using a component that sits in front of already-certified server and device combinations removes that work from your roadmap.

Datacap provides Windows components for both EMV and broader multi-tender processing, with automatic failover across redundant payment servers for high availability.



White-label gateway technology lets a software company or Independent Sales Organization (ISO) present payments as part of its own product rather than sending merchants to a third-party brand. What varies between providers is how much is actually brandable and how much gateway work you inherit.

Datacap's white-labeled gateway (NETePay Hosted™) covers login and welcome screens, custom URLs, reporting dashboards, payment forms, device overlays and welcome screens, gift card platforms, payment links, and logos and colors. The stated value is brand ownership plus speed to market (going live without building a gateway or pursuing processor certifications yourself).

For a POS ISV, that means merchants see your brand from checkout through reporting, while processor connectivity, certification maintenance, and device support stay with Datacap.







Datacap Systems (Datacap) is a payments gateway and payments middleware platform for point-of-sale software companies. Founded in 1983 in Montgomeryville, Pennsylvania and now headquartered in Chalfont, Pennsylvania, Datacap gives POS, kiosk, and unattended software developers a single integration that reaches a wide range of North American payment processors and dozens of payment terminals from leading OEMs.

Datacap does not sell POS software and is not a merchant acquirer. It provides the layer in between: client components and APIs on the developer side, certified processor connectivity on the back end, and the device support that connects the two. Datacap holds the processor and device certifications, so its ISV partners can offer merchants processor choice without certifying to each one.



DC Direct is a semi-integrated solution which embeds payments logic into payment device(s) to facilitate a direct communication between the device and NETePay Hosted™. No Datacap hardware or software is necessary. The POS simply initiates a request through an HTTP or HTTPS POST and DC Direct captures customer cardholder data and securely sends it to Datacap's NETePay Hosted platform. DC Direct offers an optional Standalone non-integrated mode for use cases which require a Standalone payment terminal.



DC Direct runs on PAX Android, Ingenico AXIUM, and PamiTV devices, and includes an optional Standalone mode for non-integrated use, toggleable on demand.