Azimut Logo

Thermal Receipt Printing API Integration for Self-Service Kiosks

Published: 15/05/2026

A thermal receipt printing API lets a kiosk application generate receipts without writing per-device printer drivers for every model in the fleet. In a self-service kiosk, the receipt is a transaction record, not a cosmetic afterthought.

Azimut SDK provides a hardware-agnostic platform layer for receipt printing alongside the other kiosk devices. The application calls SDK methods; the SDK manages printer protocol, device health, and session lifecycle.

What a thermal receipt printing API needs to handle

Receipt printing inside a kiosk must account for the full job lifecycle:

  • Build the receipt payload from the completed transaction
  • Send the print job to the attached thermal printer
  • Confirm whether the printer accepted the job
  • Detect paper-low, paper-out, cover-open, offline, and cutter faults where supported
  • Retry or fail cleanly when the print step cannot complete
  • Log the print result against the transaction
  • Return a clean result to the business application

The application never needs to know which printer model is installed at a branch, store, or service point.

Why printer state matters

In banking, telecom, and retail kiosks, the receipt is often proof of payment, deposit, SIM issuance, or service completion. If the printer runs out of paper, the kiosk must react predictably: stop receipt-required journeys, present a recovery path, trigger an alert, or optionally offer a digital receipt.

That decision belongs in the kiosk workflow. The low-level printer fault handling belongs in the SDK. Operations teams get the alert through the management portal, often before a customer reports the problem.

Local printer control vs cloud printing

Many teams search for a cloud printing API for thermal printers. In kiosk deployments, the architecture that works is usually a cloud-orchestrated workflow with local device control. The backend can decide what to print, but the kiosk runtime still needs direct awareness of the local printer state.

ModelBest forRisk
Browser print dialogBack-office printingNo awareness of printer faults; unsuitable for unattended kiosks
Cloud-only print queueRemote documentsCannot detect paper-outs or hardware faults in real time
SDK-managed local printingSelf-service kiosk transactionsRequires a middleware runtime

Azimut SDK is built for the third model: transaction-aware local device control exposed through a hardware-agnostic API. Printer health is visible in the same real-time monitoring portal that tracks all other kiosk devices.

Developer integration shape

The SDK exposes a small set of receipt operations. The typical flow checks printer readiness, raises an alert if the printer is unavailable, and only then submits the print job.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
const printer = await sdk.devices.receiptPrinter.status();

if (!printer.ready) {
  await sdk.alerts.raise("receipt_printer_unavailable", {
    kioskId,
    reason: printer.reason,
  });
  return;
}

const result = await sdk.devices.receiptPrinter.print({
  template: "bill-payment-confirmation",
  transactionId,
  values: {
    amount,
    accountReference,
    paidAt,
  },
});

The exact implementation depends on the deployment, but the principle is consistent: your application works with a stable SDK contract while the SDK manages the physical printer.

Related pages

For kiosk developers, the goal is not simply "send text to a printer." The goal is to complete a customer transaction reliably, record what happened, and keep operations informed the moment hardware needs attention.

Thermal Receipt Printing API Integration for Self-Service Kiosks | Azimut SDK