Thermal Receipt Printing API for Self-Service Kiosk Developers

A self-service kiosk generates a receipt at the end of almost every session — SIM activation confirmation, cash deposit slip, bill payment receipt, queue ticket, KYC acknowledgment. Without a receipt printer, the transaction is invisible to the customer.

The Azimut Thermal Printing API is the SDK layer that handles that output. The application submits a print job as a structured payload; the API translates it into printer commands, manages device state, and returns a pass-or-fail result. No driver code, no ESC/POS command tables, no paper-jam recovery logic in the application.

What the API covers

The Thermal Printing API treats the receipt printer as a first-class device in the SDK's hardware model, alongside cash acceptors, biometric scanners, and card terminals. The API exposes three operations that cover every print-required kiosk flow.

Print a document. The application sends a structured payload — transaction reference, timestamp, amount, line items, barcode data — and the API renders it to the printer's native format. The application does not build ESC/POS command bytes or manage paper width. It tells the API what to print.

Check device readiness. Before a print-required flow starts, the API reports whether the printer is online, has paper loaded, and has no active faults. Paper-low and cover-open states are surfaced before the customer reaches the print step, not after the print fails.

Log the outcome. Every print job returns a result — success, failure, timeout, or paper-jam — that is logged against the transaction record and reported to the management portal. Operations teams see print fault rates per device across the fleet without visiting the kiosk.

The same API contract works across printer models from different vendors. The application calls the same method whether the kiosk has a 58mm or 80mm thermal printer. The SDK handles the protocol translation.

Where the API runs in production

Receipt printing is the most frequently executed device action in the SDK's deployed base. Every completed kiosk session across the following deployments generates at least one print job through this API.

du (UAE) — 200+ kiosks print SIM registration confirmations and service receipts as part of every session. The API handles print volume across the full fleet, with per-device health monitoring surfacing paper-low and fault states before they affect customer sessions.

Bank Alfalah (Pakistan) — Cash deposit, cheque deposit, and bill payment receipts at Digital Branch kiosks. Each transaction prints a customer receipt that includes the transaction reference, deposited amount, account number mask, and timestamp.

Bank Al Habib (Pakistan) — Live production CDM deployments use the same API for receipt printing at session close on every cash and cheque deposit transaction.

Meezan Bank (Pakistan) — Cash deposit receipts issued via CDMs. Printer state is monitored as part of the SDK's kiosk health model — paper-low alerts reach operations before the printer runs out during a customer session.

PCFC (Dubai) — Government invoice generation and payment confirmation printing, built by Wavetec on the Azimut SDK runtime.

The print volume is not trivial. A single busy kiosk can generate hundreds of receipts per day. The API handles queuing, retries, and device-state reporting so that a paper jam at one machine does not block print jobs at others.

Integrating the API into a kiosk flow

Integrating thermal receipt printing into a self-service kiosk application follows the same pattern regardless of what the kiosk does. The application calls the SDK to check readiness, submits a print payload, and handles the result.

1
2
3
4
5
6
1. Customer completes transaction (cash deposit, SIM activation, bill pay)
2. Application calls SDK: check printer readiness → online, paper OK
3. Application builds print payload: reference, amount, timestamp, barcode data
4. Application calls SDK: print document
5. API renders the receipt, logs the result
6. Application receives success/failure → continues or surfaces error

The print payload is a structured object — not raw printer commands. The application defines what goes on the receipt; the SDK handles how it prints. This means the same application code works when a bank swaps from one thermal printer model to another, or when a telecom deploys a different kiosk chassis.

For developers, the integration surface is one API method with a documented payload schema. No ESC/POS reference manual, no serial-port configuration, no per-vendor SDK to learn. The SDK abstracts the printer layer the same way it abstracts cash acceptor and biometric scanner layers.

Why a shared print API matters for a multi-vendor fleet

A bank or telecom that deploys kiosks across multiple regions often ends up with different printer models per deployment — whatever the hardware vendor shipped with the chassis. Without a shared print API, each model requires its own integration code, its own command set, its own paper-jam recovery logic.

The Azimut Thermal Printing API eliminates that per-model work. The application team integrates once. When a new printer model enters the fleet, the SDK team adds a driver, and every existing application starts printing on it without code changes. This is the same hardware-agnostic pattern the SDK applies to cash devices and biometric scanners — applied to thermal receipt printing.

What to look for in a kiosk printing API

When evaluating a printing API for self-service kiosks, three things matter: device abstraction (the application should not know the printer model), fault transparency (paper-low and jam states should surface through a standard device-health model, not a cryptic error code), and transactional logging (every print job should be traceable to a transaction, so operations can diagnose fleet-wide issues without walking kiosk to kiosk).

The Azimut Thermal Printing API delivers all three because it is part of the same SDK that manages the rest of the kiosk hardware. Receipt printing is not a separate system — it is one API method in a unified runtime that also handles cash, KYC, and card transactions.

---

See how the printing API fits into a full kiosk workflow on the Document & Card Printing use case. For a broader view of self-service kiosk architecture, start with the platform overview.