Integrate the Fujitsu F53 from C# and .NET

Published: 18/09/2026

Many self-service platforms in banking and retail are built on .NET. When such a platform adds a cash dispenser like the Fujitsu F53, the usual assumption is that integration means a vendor DLL, a serial port, and a wrapper library that has to be kept in step with the hardware.

The F53 does connect over RS232C, but the kiosk application does not have to speak that protocol. The Azimut SDK drives the dispenser on the kiosk and exposes it as a JSON API. A .NET application calls it with HttpClient and System.Text.Json — both already part of the platform — and the vendor protocol stays underneath.

What the integration actually looks like

A cash step in a kiosk session needs two operations. Before the session reaches the point where money is expected, the application checks that the dispenser is ready. When the customer confirms, the application requests the amount and reads the result.

Both operations return the same envelope: a status code, a message, optional data, and any errors. A code of 0000 means the operation completed. Anything else is a device or workflow state the application can handle in normal code.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
using System.Net.Http.Json;
using System.Text.Json;
using System.Text.Json.Serialization;

record ApiEnvelope(
    [property: JsonPropertyName("code")] string Code,
    [property: JsonPropertyName("message")] string? Message,
    [property: JsonPropertyName("data")] JsonElement? Data);

var api = new HttpClient { BaseAddress = new Uri("http://localhost:8080") };

// Confirm the F53 is ready before the cash step starts.
var status = await api.GetFromJsonAsync<ApiEnvelope>(
    "api/hardware/cash-dispenser/check-dispenser");

if (status?.Code != "0000")
    throw new InvalidOperationException($"F53 not ready: {status?.Message}");

// Dispense the requested amount.
var response = await api.PostAsJsonAsync(
    "api/hardware/cash-dispenser/dispense-amount",
    new { amount = "5000" });

var result = await response.Content.ReadFromJsonAsync<ApiEnvelope>();

if (result?.Code != "0000")
    throw new InvalidOperationException($"Dispense failed: {result?.Message}");

The base address points at the kiosk itself. The SDK runs locally, so the call does not leave the machine and does not depend on the network between the kiosk and a back-office service.

Device state belongs in the application flow

A dispenser that reports a fault mid-session is not an exception the application should discover halfway through a withdrawal. The API is designed so state is visible before the customer reaches the cash step, and so a failed operation returns a code and message instead of throwing a protocol error.

The operations around the dispense call matter as much as the call itself. Purge and reset are available for recovery, and the readiness check covers cases such as a cassette that is low or a device that needs attention. In a .NET application, this becomes an ordinary async method with a try/catch boundary, which is easier to test and log than interop against a native library.

Why the JSON API fits .NET better than a vendor library

Native libraries bring architecture constraints. A 32-bit vendor DLL forces a 32-bit process, COM interop adds release and threading rules, and every model update risks an interface change. An HTTP contract avoids that class of problem: HttpClient handles connection pooling and async work, dependency injection passes a client or a typed wrapper into the flow layer, and a test double can stand in for the kiosk during development.

The SDK absorbs the hardware differences. The F53, F56, and F510 are addressed through the same dispenser operations, so moving between models is a driver change on the kiosk rather than a change to the .NET code that calls the API.

What to confirm before you start

The base URL and port are set per deployment, and the enabled device families follow the kiosk's configuration. Talk to the deployment team about the operations available on a specific machine, how the amount is interpreted for that kiosk, and whether a test environment or emulator is available before the hardware arrives.

Try it yourself

Book a demo

See how Azimut SDK works in your self-service environment. We'll walk through your use case, hardware setup, and integration options.

Book a demo→

Developer Guides