@accurateitsolutionorg/zvt-client

Unified TypeScript ZVT client for both Verifone and Clover terminals.

Install

npm install @accurateitsolutionorg/zvt-client

Quick Start

import { ZvtClient } from "@accurateitsolutionorg/zvt-client";

const client = new ZvtClient(
  {
    terminal: "clover", // "verifone" | "clover"
    host: "192.168.178.132",
    port: 25690, // Clover default; Verifone usually 20007
    password: "000000", // 6 digits if terminal requires password
    orderNo: "1234", // used by Verifone legacy payload mode
  },
  (entry) => console.log("[ZVT]", entry),
);

const auth = await client.authorize(100); // 100 cents = 1.00
console.log(auth);

Constructor

new ZvtClient({
  terminal: "verifone" | "clover",
  host: string,
  port: number,
  password?: string,
  orderNo?: string | number,
}, forwardLog?)

Methods

• register(opts?)
• status(opts?)
• authorize(amountCents, opts?)
• cancel()
• raw(hex)
• reconcileLast(opts?)
• clearCooldown()
• cooldownStatus()

Notes

• password validation: exactly 6 digits when required.
• Verifone:
  • supports orderNo/reference in legacy payload mode.
• Clover:
  • uses readiness probing + cooldown guard to avoid early retries after abort/cancel.

Changelog

0.2.0

Fixes intermittent false "success" results on both Verifone and Clover paths - transactions the terminal actually rejected or aborted could be silently reported as approved when using the POS integration (direct terminal payments were unaffected, since they don't go through this classification logic):

• The byte sequence 84 A0 00 was mislabeled as "AUTH accepted, transaction started". Per the ZVT spec, any 84 <code> 00 frame is a NACK (the terminal rejecting the request) - the opposite of what the code assumed. Early socket closes following a NACK are no longer treated as evidence of success.
• 06 1E (Abort from PT) was only recognized for one hardcoded reason code (061e019b). Any other abort reason - including 0x6C ("card not admitted"/general decline, the most common one) - fell through unclassified, producing an ambiguous "unknown" outcome instead of a definitive decline/abort.
• Terminal display text is CP437-encoded, not latin1 - German umlauts (ä ö ü ß) decoded to the wrong characters, and the in-progress/declined/aborted text matchers only recognized English phrases. A German-language terminal's status messages (e.g. "vorgang abgebrochen", "kundeneingabe bitte warten") were almost entirely invisible to the classifier, which is what let aborted/rejected payments silently default to "success" after enough unrecognized status polls.

All three fixes were verified against a real failure log (byte-for-byte replay of the captured frames) before release.

Build

npm run build

Publish

npm login
npm publish --access public