Complete a physical-reader payment
Handle authorization, auto-confirmation exceptions, voids and linked refunds without treating every callback as a settled sale.
Start with a durable reference
Provide transaction type, amount/currency and a unique UserReference before startTransaction. Register transactionFinished plus required signature, application-selection and user-notification handlers first. An accepted method call starts a workflow; it is not payment approval.
Separate result from state
The shared flow distinguishes APPROVED, DECLINED and VOIDED results from Uncommitted, Committed, Void, Uncommitted void and Delayed state. Both acquirer and terminal approval matter. Partial approval returns the approved amount. Delayed processing returns an encoded request for another integration and must not be represented as an online authorization.
Complete the second stage
For ordinary manual-confirm flows, confirmTransaction identifies the attempt using the original unique reference. AutoConfirm TRUE requests completion before transactionFinished. If that stage fails and returns Uncommitted or UncommittedVoid, the app must resolve it through confirm or void as appropriate. Do not confirm a transaction already completed.
Choose the correct reversal
Operation Use terminateTransaction Cancel an interaction still in progress. voidTransaction Void a transaction before settlement; use the original reference. linkedRefundTransaction Return all or part of a previously approved and confirmed payment. getTransactionInformation Recover known state before deciding whether another action is needed.
Do not share one policy across every device
Tap to Pay is an online auto-confirmed sale, with separate restrictions. Axium executes on the terminal and can keep processing after host disconnection. Use the platform-specific guides rather than applying this physical-reader lifecycle without those exceptions.
Map the callback quick reference
onAvailablePinPads feeds selection; onConnectAndConfigureFinished establishes readiness; onTransactionUpdate reports progress; onTransactionFinished requires outcome/state handling; onSignatureVerification and onDeferredAuthorization require their matching continuation; onProcessReceiptFinished reports delivery. Apply auto-confirm and SmartPOS exceptions before following the generic Confirm/Void shorthand.