Clover POS Middleware and At-Register Donation Integrations

Summary

We build point of sale middleware for Clover terminals, including at-register donation prompts presented on the payment device after the sale total is known. This kind of work covers an Android application on the terminal, integration with the point of sale that owns the check and the tender, Clover Pay API orchestration, durable transaction state, and the configuration and diagnostic tooling that makes a terminal estate supportable in the field.

The Challenge

Payment integrations are state machines and must be treated as such. Every request resolves to success, failure or cancellation, and a fourth state, unknown, has to be handled explicitly: a network drop between authorisation and response leaves the terminal certain and the point of sale uncertain. Without a durable local record, a shared correlation identifier and a reconciliation path that queries payment state rather than assuming it, donations are double counted or silently lost.

The accounting treatment is equally unforgiving. An amount added to the sale total is not revenue and generally is not taxable in the same way as the goods sold, so it needs a distinct tender or item classification that flows correctly into the general ledger and into any receipting obligation. Retro-fitting that classification after a long period of trading is painful.

Then there is the counter itself. A prompt that adds taps, delays the queue, or is easy to trigger accidentally will be switched off almost immediately. And nothing may weaken the payment path: if the middleware is unavailable, the sale still has to complete normally.

The Solution

Components

• An Android application on the Clover device rendering the prompt on the payment-facing screen and capturing the selection.
• An integration to the point of sale, commonly an Oracle MICROS environment with a Symphony server, which remains the system of record for the check and the tender.
• Clover REST Pay API calls to initiate and monitor the payment, with the terminal handling card entry.
• Supporting Windows-side components, including service executables and shared libraries, where the point of sale integration is desktop based.
• Configuration and diagnostic screens for operations staff.

Field support tooling

Practical maintenance tooling matters more than it looks. A version screen showing application name, current version and last modification date makes library review possible in the field. A configuration screen allows the pay API endpoint and credentials to be inspected and updated without a redeploy. A manual pay-request action lets a technician exercise the full path on site.

Transaction state

The middleware keeps its own durable record of every request, correlated with the point of sale, and resolves outcomes by querying the payment rather than inferring them. Reconciliation runs across a full trading day so that terminal records, point of sale tenders and the ledger classification all agree before anything is reported.

Security and compliance

The middleware never handles card data. Card entry, encryption and authorisation stay inside the payment terminal and the processor, which keeps the surrounding application out of the cardholder data environment and dramatically narrows PCI scope. Any design that proposes reading or relaying card details is rejected outright. Terminal applications also survive restarts, network loss and device updates, and fail closed, so an unavailable component removes the prompt rather than the sale.

Interaction design

The prompt offers a small set of preselected amounts and a clear option to decline. The decline option is as prominent as the amounts, the screen is readable at counter distance, and the flow adds no more than a single interaction. If an amount is chosen it is added to the transaction; if not, the sale proceeds untouched.

How we build it

We map the existing tender flow before writing code, build against the payment sandbox with deliberate failure injection, and validate reconciliation across a full trading day before the first live terminal is enabled.

What This Delivers

Counters can invite a contribution at the moment of payment without new hardware, extra staff steps or a slower queue. Amounts land in the ledger under their own classification, so reporting and receipting are correct from the start. Support staff can inspect versions, repoint endpoints and test the full payment path on site, and an outage in the middleware never blocks a sale.

Technologies and Tools

Android application development on Clover terminals, the Clover REST Pay API, Oracle MICROS with a Symphony server, Windows service executables and shared libraries for desktop-based point of sale integration, durable local transaction storage, and payment sandbox testing with failure injection.