Provisioned, not assumed
The permitted set lives on the terminal record and is enforced at authorisation.
Genies Pay / Smart POS
One kernel. Every model. Both languages.
Smart POS 2.0 is the application that runs on the terminal: the EMV kernel, the PIN pad, the journeys, the receipts — and the attestation check that has to pass before any of it is allowed to run.
Cedar Grocery
IN PROGRESS
USD 12,500.00Purchase · contactless
Present card
7.4 · Functional specification
What the application does.
| Capability | Specification |
|---|---|
| EMV kernel | Level 2 contact and contactless processing: application selection, APDU exchange, TLV construction and parsing, terminal configuration and action analysis, terminal verification results and cryptogram handling. |
| PIN & key management | PIN entry on the certified PIN pad, PIN block generation under DUKPT with key serial number, remote key injection and key-profile download, hardware-backed secure storage on the terminal. |
| Transaction journeys | Sale, cashback, refund, void, pre-authorisation, capture, tip adjustment, reversal, batch close and reprint, with English and Arabic screen flows and receipt templates. |
| QR | Camera capture and decoding of customer-presented QR, merchant-presented QR display, and the offline dynamic-QR SDK for a bank or wallet application. |
| Payment SDK | Embeddable SDK for a third-party Android application: configuration and validation, deep-link invocation, transaction result stream and state model — so a bank or merchant app can start a payment and receive the outcome without handling card data itself. |
| Application security | Code obfuscation in the release build, certificate pinning, and tamper and attestation checks against Tantra AM before a terminal is allowed to transact. |
The transaction set
Everything Phase 1 covers at the counter.
| Transaction | Notes |
|---|---|
| Purchase | Chip, contactless and magnetic-stripe fallback; scheme and local cards. |
| Purchase with cashback | Splits between goods and cash, posts as a single total, and reports the cashback portion separately at settlement. |
| Refund | Partial and full, validated against the original transaction and its cumulative refunded amount. |
| Balance inquiry | Where the card product and the issuer support it. |
| Pre-authorisation | The hold; matched through the original-data elements for everything that follows. |
| Incremental authorisation | Adds to the existing hold rather than raising a second, unrelated authorisation. |
| Completion / capture | Captured at the final amount; the unused portion of the hold is released. |
| Tip adjustment | Updates the captured amount and the settlement position within the permitted window. |
| Void | Same business day, restoring the cardholder position. |
| Reversal | On switch timeout, carrying the original data elements. |
| Batch close | Terminal totals reconciled against stored transactions before the batch is accepted. |
Currency and language
One terminal, the currencies it was provisioned for.
USD (840), SAR (682) and USD (886) across the platform. Each terminal carries its permitted transaction currencies, and a transaction in a currency it is not provisioned for is declined at the gateway, before it reaches the switch.
English and Arabic
On screens and receipts, with right-to-left handled properly rather than mirrored.
Per currency
Settlement currency is configured per merchant; positions are calculated per currency and netted per institution.
Next step
Put one in your hand.
Tell us your terminal models, your channels and whether the SDK is going into your own app. We come back with a rollout shape, a key-injection procedure and an EMV Level 3 certification schedule.