A cheque image arrives on a ticket. OCR can extract a payee, amount and cheque number. The operator still needs to compare the extraction with the image and decide whether a connected action may proceed.
That makes cheque OCR a useful plugin design example: reading evidence, proposing values and executing an approved operation are separate responsibilities.
Updated 3 October 2026: The original May article described a typed-issue enrichment and field-write example. That walkthrough is historical. Its executable setup and field-write snippets have been removed; this article is an architecture review, not a current copy-and-run cheque-processing integration. Confirm the supported extension contract for your release before implementing enrichment or writing extracted fields.
What the original example demonstrated
The original design selected an attached image, sent it to an OCR service and mapped the response into cheque fields. Discovery then used the presence of a cheque number to decide whether Credit and Reject actions were available.
This illustrated a useful dependency: an action should explain why it is unavailable when required context is missing. It did not establish that a present cheque number was correct or that the proposed payment was authorized.
The example's Credit and Reject handlers returned demonstration results and ticket effects. A message saying “credited” was not evidence that a clearing or payment system had performed a real operation. A production integration needs an authoritative downstream result and a reconciliation path.
Start from the current action contract
For custom ticket actions, the TypeScript SDK separates discovery from execution:
discover(ctx)returns action definitions and their current availability. An action can reference a JSON Schema for its submitted form.execute(actionId, ctx, formData?)receives the selected action, ticket/user context and submitted form values.- The execution response includes a success flag and message, with optional error code, returned data and supported ticket effects.
Supported comment and status effects let the application apply a result to the ticket through its own write path. Status changes must satisfy the configured workflow. A returned data object is result evidence; it should not be assumed to populate arbitrary ticket fields automatically.
The developer overview explains the SDK and API surface. Match its versioned contract to your installation, including authentication and supported endpoint behavior. Legacy type names or a copied example do not establish a supported field-write path.
Keep OCR extraction and operator verification distinct
For a new design, name the image that was processed and the extraction result's provenance. Record the OCR service/version where available, the time of the request and any validation flags it actually returned. Keep the original image accessible to the authorized operator.
The operator needs a place to compare proposed values with the source and correct them. Decide how that review result is stored using the release's supported configuration or API. Do not recreate the old typed-issue write example without validating its current support.
A cheque number can be present and wrong. Image selection can also choose the wrong attachment. Test a missing image, two candidate images, an unreadable amount and a conflicting operator correction before deciding that action availability is sufficient.
These are design acceptance tasks, not a claim that the historical demo passed them.
Put sensitive execution behind the configured gate
A real credit or rejection operation needs business validation and the downstream service's authority. A confirmation dialog alone is not independent approval.
Latch can apply maker-checker to a plugin action. The action requester cannot approve, reject or execute that same request. Another eligible operator reviews the saved submitted fields; approval and execution are separate steps, and the reviewer may execute if permitted.
The current gate settings provide no gate or maker-checker, plugin defaults and per-action overrides, expiry and optional ticket-change invalidation. Monetary conditions belong in the connected business logic. Several sequential approvers or a quorum require separate evaluation.
Before approved execution, Latch checks current permissions and action availability again. Saved form values are retained, while current ticket context is used. The downstream integration must also verify the operation against its authoritative state.
Return results that another operator can investigate
Use a provider result to distinguish a rejected business request, a completed operation and an unknown outcome. Include an authoritative reference only when the downstream system actually returns or confirms it. Do not manufacture a payment-success label from an OCR result.
A lost response may follow a successful external operation. Latch retains uncertain approved attempts rather than automatically replaying them. The integration owner must investigate the external outcome and any local ticket effects before separately authorizing further work.
The approval feature guide shows the interface with synthetic replay data. It helps explain review and execution states; it does not prove cheque clearing or a live financial result.
Test the deployment as well as the response shape
Trace where the image, OCR request, credentials, logs and returned data go. A service reached with your own API key still receives the data sent to it. A local model or OCR service needs a supported network connection and an operating owner.
Latch's provider policy denies loopback, Tailscale services and metadata destinations. A private integration requires a supported operator-controlled mapping. Do not reuse a localhost setup as a production connection instruction.
Agree on request size, timeouts, log redaction, credential rotation and recovery. Avoid promising that synchronous enrichment runs exactly once or that a timeout can be fixed by retrying without checking the external result.
Use the example to define the work to build
The durable lesson is the separation between source evidence, proposed values, human review and downstream execution. A usable cheque integration must specify and test all four.
Use the configuration/plugin/source decision table to choose the extension method. Then complete the deployment evaluation checklist with a synthetic image and test downstream service before making a production claim.