Clover POS Plugin Development for Digital Change and Receipt Workflows

Summary

We build digital change plugins for cash-handling point of sale. Cash sales end with coins and low-denomination bills that few people want to carry and that merchants have to count, store, and reorder. A plugin of this kind replaces the physical handoff: at the end of a sale the terminal offers an electronic option and prints a receipt carrying a QR code that encodes a single-use claim reference, and the payer redeems the value from a phone into a bank account, a stored balance, or a donation.

The Challenge

The terminal work is only half of it. The other half is a ledger that knows what was promised and what has been settled, because value is owed from the moment the receipt prints. Every hop needs an idempotency key, since a terminal that loses connectivity mid-request will retry and must not create a second claim.

Money movement also carries obligations that the design has to absorb rather than defer. Claim references must be unguessable and short lived, with expiry and reissue rules written down before launch. Value that is never redeemed does not simply disappear; unclaimed property rules vary by jurisdiction and the ledger has to report on aged balances. Redemption into a bank account brings identity verification and consumer protection duties around error resolution and disclosures. Offline behaviour needs a decision, not a default: either queue the claim locally, print anyway, and reconcile when connectivity returns, or refuse the electronic option and fall back to coins. And reversals are the common failure mode, since a sale voided after the receipt printed leaves an outstanding claim that must be cancelled atomically.

The Solution

Four moving parts

• A Clover application running on the terminal that detects the tender and change amount and drives the print
• A claim service that issues references, holds their state, and enforces single use
• A ledger that records the liability created at the counter and its later discharge
• A redemption experience, usually a mobile web page, that authenticates the holder and moves funds out

Working inside the Clover SDK

Clover devices run Android with a controlled application surface. The Clover SDK for Android exposes bound service connectors rather than raw database access: an order connector for line items and totals, a payment connector for tender activity, a receipt registration connector for adding a section to the printed or emailed receipt, and a profile connector for stored shopper details. Permissions are declared in the manifest and reviewed at market submission, so the data an application can read is settled before development. On a dual-screen unit such as Clover Station Duo, the merchant-facing and shopper-facing displays are distinct surfaces, and the prompt offering electronic change belongs on the shopper side while confirmation stays with the operator.

Language, interop, and the secure path

Java is the platform language of the SDK and Kotlin layers on top of it cleanly, but the boundary needs care: SDK types arrive as platform types with no nullability information, so annotate or wrap them rather than trusting the compiler at the interop line. The secure payment path stays inside the platform. The application never touches the primary account number; it receives references, masked values, and tokens, which is what keeps the integration outside the sensitive data environment.

How we build it

We start with the receipt and the ledger, because those two artifacts define the contract everything else implements. The terminal application is then developed against a developer device carrying the same connector permissions as production, since emulator behaviour and real print and tender timing diverge. Integration tests drive full tender scenarios including partial payments, voids, and refunds after a claim has been issued, on the specific hardware model being targeted, because peripheral behaviour differs across the device family.

What This Delivers

A merchant stops counting, storing, and reordering coin, and the person paying gets a choice about where small value goes instead of a handful of change. Because the ledger is authoritative, outstanding and settled value can be reported on at any time, aged balances are visible, and reconciliation between terminal batches and the ledger becomes routine rather than an investigation.

Technologies and Tools

Android on Clover payment hardware including Clover Station Duo, the Clover SDK for Android with its order, payment, receipt registration, and profile connectors, Java and Kotlin, thermal receipt printing with QR encoding, a claim and ledger service, and a mobile web redemption page.