This page documents the transaction parameter deltas for SmartPOS / Axium integrations. For the underlying startTransaction() flow, event handling, and result interpretation that applies to all integrations, see the shared Transaction Flow page.

SmartPOS supports a subset of the features available to non-SmartPOS integrations. Several parameters that are valid elsewhere will cause errors when included here, and several new parameters are specific to SmartPOS.

Required Parameters

startTransaction() requires the following parameters for a SmartPOS transaction:

Parameters That Will Cause Errors

SmartPOS currently supports a limited subset of features compared to traditional POS devices. Passing any of the following parameters into startTransaction() will return an error:

New Parameters Available for SmartPOS

The following parameters are available only on SmartPOS transactions. If not passed, the defaults documented below apply.

ParameterKeys.TransactionAuthPreference

Determines how the transaction is initially authorised.

ParameterKeys.OfflineTransactionUploadMode

Determines how queued offline transactions are uploaded once connectivity returns.

See Offline transactions for the full queue behaviour.

ParameterKeys.MagstripeDebit

Enables debit processing for magstripe SmartPOS transactions.

ParameterKeys.MagstripeSignature

Enables signature capture for magstripe SmartPOS transactions.

ParameterKeys.PartialApproval

Enables partial-approval handling on SmartPOS transactions.

ParameterKeys.TipAmount

Because on-device tipping is not supported on SmartPOS, the tip amount must be passed into the transaction by the integrating application. The value uses the same minor-unit format as ParameterKeys.Amount.

ParameterKeys.SignatureVerification

Controls how signature verification is handled when a transaction requires one. Available from SDK 5.3.1.

External signature verification flow

When SignatureVerification = External:

1. The Axium captures the signature on-device and transitions the transaction state to AWAITING_SIGNATURE_VERIFICATION.
2. The SDK invokes ISignatureVerificationListener.onSignatureVerification(Parameters). The captured signature data is available in the callback's parameters under ParameterKeys.SignatureData.
3. Your application reviews the signature (typically displays it to the cardholder or operator) and decides whether to approve or decline.
4. Your application calls ChipDnaMobile.continueSignatureVerification(parameters) with ParameterKeys.Result set to ParameterValues.TRUE (approved) or ParameterValues.FALSE (declined). The transaction then resumes on the Axium with the verification result.

override fun onSignatureVerification(params: Parameters) {
    val signatureData = params.getValue(ParameterKeys.SignatureData)

    // Show signature to cardholder / operator for review …

    val response = Parameters()
    response.add(ParameterKeys.Result, ParameterValues.TRUE)  // or FALSE
    ChipDnaMobile.getInstance().continueSignatureVerification(response)
}

Methods Requiring an Active Device Connection

The following SDK methods require an active connection to the Axium device to succeed, even though they're synchronous-looking calls. With a standard PIN pad integration these methods can return cached data; with SmartPOS the device must be reachable because the transaction state lives on the Axium.

• confirmTransaction()
• voidTransaction()
• linkedRefundTransaction()
• getTransactionInformation()
• getStatus() — for the full parameter set (a limited subset is available without a connection)

If the connection drops while one of these calls is in flight, see Device disconnection during a transaction for the behaviour.