How far can you extend a POS system? A look at SAP Customer Checkout
When companies evaluate a POS system, the feature list only answers part of the question. Most projects come with requirements that no standard product covers: a closing procedure the staff has followed for years, an ordering system the till has to talk to, a report that accounting expects in a specific format. Whether such requirements can be implemented at all, and at what cost, depends on how the product can be extended.
An evaluation should therefore ask early on what happens when a requirement is not covered by the product. For many POS systems the answer is a configuration workaround or a change request to the vendor. SAP Customer Checkout answers this differently. I have been building extensions for it since 2019, and this article describes what its extension model allows in practice.
The short version
SAP Customer Checkout (CCO) is SAP's point-of-sale product for retail, hospitality and quick service, from single shops to football stadiums. It has two parts: the POS software on the till, which keeps a local database and keeps selling through a network outage, and the Manager, the central component for master data, configuration and ERP integration, with prebuilt scenarios for S/4HANA. It comes as an on-premise product and as a cloud edition where SAP operates the Manager for you.
What makes it interesting for the question above is the extension model. CCO extensions are not sandboxed companion apps that live next to the till. A plugin is loaded into the till software itself and can hook into practically every step of a sale: an item is added, a price is found, a payment starts, a receipt prints, the day closes. It can add its own buttons and whole screens, talk to external systems, drive hardware. The current cloud release documents well over a hundred of these hook points, and where none fits, a plugin can intercept the internal service calls directly. Because all of this runs on the till, it keeps working when the connection to the server is gone.
Three examples from real projects show what this looks like.
A graphical table plan
CCO's table service shows open tables as a list of tiles, which works, but tells you nothing about the room. This plugin adds a table plan tab: the real floor plan, live status per table, tap a table and the till jumps into the sale. Layouts come from a file that a bundled drag-and-drop editor writes, so the restaurant can rearrange tables without anyone touching code.
This is a pure UI extension. The product does not know it exists, no core code was changed, and it survives product updates as a separate jar.
Room charges posted to the hotel PMS
A hotel restaurant, and the guest says "put it on my room". This plugin adds a room charge payment method to the till: the waiter enters the room number, the plugin asks the hotel property management system live which guests are checked in, and posts the charge to the guest folio the moment the receipt closes. A cancellation at the till posts the matching credit, so till and folio always reconcile.
The screenshot is from my test setup against a real cloud PMS sandbox. The pattern is the interesting part: a payment method that did not exist in the product, talking to a system SAP has never heard of, live during the sale.
AI food recognition at the checkout
In a canteen, a camera above the counter recognises the dishes on a tray and books them onto the receipt. Solutions like this typically bring their own user interface and their own workflow for the guest or cashier; the POS screen is not visible at all. CCO runs behind that interface as the booking and fiscal engine. The plugin receives the recognised articles, puts them on the receipt and completes the sale through the regular POS services, including payment and the fiscal signature.
The recognition itself is a third-party AI service. The plugin is the connection between the two systems: it maps what the camera saw to articles and processes the sale in the background. This category, connecting a system the product never planned an interface for, is where most of my plugin work happens.
Integration through the Manager
The examples so far run on the till. The other half of the extension story is the Manager, the central integration point of a CCO landscape. SAP ships prebuilt scenarios for its own backends, S/4HANA in particular: master data such as articles, prices, customers and stock flows down to the tills, receipts and financial transactions flow back up.
These scenarios are a starting point, not the limit. The Manager has its own extension model, with custom actions and scheduled jobs that run centrally instead of on every till, and REST APIs for master data, receipts, configuration and users. In one project I used this to connect a non-SAP ERP: articles, prices and customers come out of the ERP, and every receipt is posted back as an invoice, with no SAP backend involved. Adjusting an existing connection is the same kind of work, for example filtering or enriching what gets posted, mapping to a different account structure, or forwarding receipt data to an additional consumer such as a data warehouse or a reporting platform.
The Manager also relays live requests during a sale. When the cashier checks stock, for example, the request goes from the till through the Manager to the ERP, and the answer comes back to the till. Requests the standard scenarios do not cover, a credit check, say, or a customer's open items from a non-SAP backend, follow the same route as project work: a till plugin talks to a central service that owns the backend connection.
And plenty more
The same mechanisms carried, among others: a day-end closing that runs reports, payment terminal closing, backup and shutdown as one button. Team-based table service for a festival tent, although the product has no concept of waiter teams. Gift cards on RFID wristbands. Scales, multi-scanner setups, tax-free processes. An accessibility mode for the self-checkout. Even tiny things, like a daily changing symbol on kitchen tickets so staff can spot yesterday's leftovers, are a plugin of a few hundred lines.
What it takes
This flexibility has a price. Plugins are Java development inside the till process, and that cuts both ways: a badly written plugin can take the till down with it. Anything near fiscal logic is constrained by law, not by the product. And a plugin has to be re-tested when the customer moves to a new feature pack. This is proper software work with real responsibility, usually done by an experienced developer or a partner, not something you click together.
But it is normal software work. Build a jar, distribute it centrally through the Manager, done. There is no marketplace approval and no certification queue between your requirement and your rollout, and that changes project timelines more than any single feature.
If you are looking around because every special requirement on your current POS turns into a vendor escalation, CCO is worth an afternoon of your time. I am happy to compare notes on concrete requirements, get in touch. If you want the technical depth instead, start with how I treat CCO plugins as real software or the web app bridge for building full screens inside the till.