amwal_ecr
Drive an Amwal POS terminal from Flutter. One Dart API over the native Android and iOS ECR SDKs: sale, void, refund, inquiry and e-receipt, with typed outcomes that keep an unknown result apart from a refusal.
What this package is like to depend on
Last release 4 days ago
19 Aug 2026
Too new to tell
only 1 dated releases
Nearly every release is documented
notes for 1 of 1 stable releases
Nothing withdrawn
no release was ever pulled
0 months old
1 releases · first in 2026
1 release in the last 12 months
see the full history below
Release timeline
1 releases · Aug 2026 to Aug 2026Releases
latest 1-
0.2.019 Aug 2026Release notes
Open source →Brings the package level with
com.amwal-pay:ecr-sdk1.0.4 andAmwalECR0.2.0 — the same three features on both platforms, over the same channel contract.Breaking. The protocol renamed the field that names a transaction, so
requestIdismerchantReferenceIdeverywhere: onEcrResult,EcrInquiry,EcrReceiptand on the platform channel. Rename it at the call sites; the type is unchanged and it still arrives filled in whether or not you supply one. The channel contract changed too, so the Dart side and the native hosts must be upgraded together — an old host does not lose a field, it stops being understood.Added
- A reference the till chooses.
merchantReferenceIdonsale,voidTransaction,refund,run,inquireandreceipt— an order number, a basket id, whatever already names the sale in your system. Pass it and the same string identifies the transaction in your books, in the terminal's records and in any later lookup; leave it out and the host generates one. Either way it comes back onEcrResult.merchantReferenceId, and it is the only handle you hold if the answer never arrives. EcrTerminal.inquireByReference. The answer to an outcome you never received: looks a transaction up by the reference it was sent with, rather than by a receipt number that only arrives in the answer.EcrFailed.recovered,.recoveredTransactionand.settled. The host now follows a lost money-moving request with one inquiry and attaches what it found. Asettledfailure is a delivery that failed and an outcome that is known, sooutcomeIsUnknownis false and the till books the transaction instead of reconciling it. Turn the follow-up off withEcrConfig.autoInquireOnFailure. Nothing is ever re-sent.EcrConfig.secureHashKey. The secret this till shares with the terminal. Set it and the native SDK signs every request and checks every answer. Refused at construction if it is not an even-length hex string of at least 16 characters — on the shop floor a bad key is a decline the cashier cannot explain. Required in practice: a terminal refuses what it cannot verify. The key is never printed bytoString.EcrUnauthenticated, for an answer that cannot be shown to have come from the terminal. Leaves the outcome unknown, like a timeout — never a decline, and never to be retried.EcrNextStep, on everyEcrResult. What the terminal says to do about an outcome, rather than something a till has to infer from a response code. A decline that asks for an inquiry now reportsoutcomeIsUnknown.
Changed
- Config, arguments and results carry the new fields across the channel:
secureHashKey,autoInquireOnFailure,merchantReferenceId,originalMerchantReference,nextStep,recovered, and theunauthenticatedfailure kind. The frozen contract test lists them all. - A reference the wire format cannot carry — over 32 characters, or containing a
space,
&or=— throwsEcrArgumentErrorbefore anything is sent, on both platforms and in Dart, with the same message. - The Android host now requires
com.amwal-pay:ecr-sdk:1.0.4, and the iOS hostAmwalECR ~> 0.2.0.
- A reference the till chooses.