GeniesPay App
Onboarding and identity in the first five minutes, then paying five ways — scan, be scanned, tap, send, request — with every movement recorded and receipted.
Smart POS 2.0 · QR · SDK · Tantra AM · GeniesPay App
Payment, at the edge.
The terminal, the phone, the QR code and the SDK. Everything that happens where the money actually changes hands — and everything that has to be true before it does.
EMV L2 kernel
The GeniesPay App
Attested terminals
EN · AR
Cedar Grocery
APPROVED
USD 12,500.00Purchase · contactless
Approved
The film · 00:60
Two seconds at the counter.
The whole product happens in the time it takes someone to put their card back in their pocket. The film takes those two seconds apart and puts them back together.
- 01
Tap
A card meets a terminal. Two seconds, start to finish.
- 02
Underneath
Application selection, APDUs, DUKPT, cryptogram, online.
- 03
Or a code
A dynamic QR with twenty seconds to live, bound to a device.
- 04
The gate
A terminal that cannot prove what it is does not transact.
- 05
Your app
Ten lines of Kotlin. Your code never touches a PAN.
- 06
In the hand
And the same payment from the customer's side, in the app.
Film in post-production. The beats above are locked.
Smart POS specification
The tap
What the customer sees, and what is actually happening.
Two seconds at the counter is a dozen steps underneath. Here they are side by side — the screen on the right, the mechanism on the left.
Cedar Grocery
IN PROGRESS
USD 12,500.00Purchase · contactless
Present card
At the counter
Eight things that go wrong where money changes hands.
Acceptance is not a data-centre problem. It is a queue, a stall, a Saturday afternoon — and these are the things that actually happen there.
A terminal was opened, modified, and kept taking payments.
Tamper and attestation checks run against Tantra AM before a terminal is allowed to transact. A failure blocks the terminal and raises an alert, and it only returns after re-registration and a fresh parameter download.
attested before it trades
The customer screenshotted the QR and someone else paid with it.
Dynamic codes refresh every twenty seconds and every code is bound to the registered device. Secure Point verifies the binding and the validity window, so an expired code and a code from an unbound device are both declined.
20s · device-bound · verified
There is no signal at the stall, so there is no payment.
The dynamic code is generated offline on the customer's own device. Connectivity is needed for the authorisation, not for producing the code.
generated offline
We want payments in our bank app, but not PCI scope.
The Payment SDK is invoked by deep link and returns a result stream and a state model. Your application starts a payment and receives the outcome without handling card data itself.
deep link · result stream
A new terminal model means rewriting the application.
One EMV Level 2 kernel, a capability profile per model, and versioned parameter sets and key profiles downloaded per terminal group. What changes is configuration and an EMV Level 3 certification run — not the application.
one kernel · profile per model
The tip was added after the customer had already left.
Tip adjustment is part of the transaction set: the captured amount and the merchant's settlement position both update within the permitted window, against the original transaction.
tip adjustment · in window
The third refund took the total past the original sale.
Refunds are validated against the original transaction and its cumulative refunded amount. A partial refund that would exceed the sale is declined, not reconciled later.
cumulative amount checked
A terminal has not been seen for four days and nobody noticed.
Estate monitoring reports health, last-seen, transaction and decline trends, batch state and version distribution — with threshold and event rules that route and escalate.
last-seen · alerts · escalation
The twenty-second code
A screenshot buys nothing.
Dynamic customer-presented QR refreshes every twenty seconds, is generated offline on the customer's device, and is bound to that device. Watch it regenerate, then watch the two ways it gets declined.
seconds until it refreshes · bound to this device
Three things have to hold
- The payload is inside its validity window — codes refresh every twenty seconds
- The code is presented from the device it was bound to at generation
- Secure Point verifies both before the transaction is allowed to continue
- Merchant-presented static and dynamic codes follow the same verification path
- The same merchant, terminal and fee validation runs as for a card transaction
The pattern shown is decorative and encodes nothing. Device binding and a twenty-second window make a reused code useless; they are strong controls, not a guarantee against every attack.
Attestation
A tampered terminal does not trade.
Tantra AM admits terminals onto the estate. It runs twice below: once where the evidence checks out, and once where it does not.
——
—
——
—
——
—
——
—
What Tantra AM holds
- Terminal registration — identity, serial number, model, merchant and store assignment, activation state
- Attestation — identity and integrity evidence presented before the terminal is permitted to transact
- Parameter management — parameter sets and key profiles per terminal group, versioned, downloaded on sign-on or on demand
- Estate monitoring — health, last-seen, transaction and decline trends, batch state, version distribution
- Alerts and reports — threshold and event rules with severity, routing and escalation
The SDK
Payments in your app. Card data in ours.
The Payment SDK is invoked by deep link and returns a result stream and a state model. Your application starts a payment and gets an outcome; it never touches a PAN. Watch the integration walk against the phone.
// 1 · configure once, against the terminal profile
val pay = GeniesPay.configure(context, profile)
// 2 · start a payment by deep link — no card data enters your app
pay.start(amount = "12500.00", currency = "USD")
// 3 · observe the result stream
pay.results.collect { r -> ui.render(r.state, r.reference) }
IDLE
Illustrative Kotlin. The published SDK surface, its state model and the integration guide ship as companion volumes.
In the hand
And the same payment, from the other side.
Everything above is what a merchant installs. The GeniesPay App is what the customer holds — live, on Android and iOS, in English and Arabic. It is an account, a wallet, three kinds of card and a crypto balance, and it pays at exactly the terminals described above.
Wallet
Several currency balances and several crypto balances in one list. Five ways in, four ways out, and conversion quoted with the spread and the clock on screen.
Cards
A virtual card in the same minute the account opens, a digital card tokenised into the phone, a physical card in the post — and controls that bite on the next authorisation.
Crypto
Four separate things kept separate: accept it at the counter and settle fiat, hold it custodially, spend it through a card, or settle between institutions over it.
Which of these can be offered in a territory follows the licence held there — the crypto page says so in place rather than in a footnote.
The short version
Eight things worth saying plainly.
A screenshot buys nothing.
Dynamic codes refresh every twenty seconds and are bound to the device that made them. A replay after expiry is declined.
20s window · device binding · Secure Point
No signal. Still a code.
The dynamic code is generated offline on the customer's own device. Connectivity is for the authorisation, not the code.
offline generation · EMVCo payload
A tampered terminal doesn't trade.
Attestation runs before the terminal is permitted to transact. A failure blocks it and raises an alert to operations.
attested before it trades · alert raised
Payments in your app. Card data in ours.
Deep-link invocation and a result stream. Your application starts a payment and receives the outcome without handling card data.
deep link · result stream · state model
Tap. Print. Done.
EMV Level 2 contact and contactless, PIN under DUKPT on a certified pad, receipt templates — and magnetic-stripe fallback where it is still needed.
EMV L2 · DUKPT · EN / AR receipts
The phone is the terminal.
SoftPOS accepts contactless on the merchant's own phone. Availability follows the scheme's Tap-to-Phone programme in the licensed territory.
Tap-to-Phone · optional module
Every screen speaks both.
English and Arabic on the terminal, on the receipt, in the KIOSK journey and in the merchant's notifications — not a translation layer bolted on.
EN / AR · screens and receipts
Last seen: four days ago.
Estate monitoring reports health, last-seen, decline trends and version distribution, with rules that route and escalate.
health · last-seen · escalation
The estate
One view of everything you have put in the field.
Illustrative estate view. Health, last-seen, version distribution and decline trend come from Tantra AM. One terminal here has not been seen for four days — which is the kind of thing that is invisible until something watches for it.
The suite
The edge is one layer of four.
What happens at the terminal only works because of what sits behind it — and it is all one data model, from one vendor.
Genies Pay
Smart POS 2.0, the Payment SDK, EMVCo QR with device binding, Secure Point and Tantra AM attestation and monitoring.
T-NET Acquiring Route
ISO 8583 engine, scheme and CBS connectivity, HSM services, risk and AML, clearing and settlement.
My Mercho Suite 2.0
Institution, aggregator, merchant, store and terminal masters, KYC, rate cards, maker-checker, the merchant portal.
CARD PRIME D 3.0
Card lifecycle, instant issuance, embossing, digital and virtual cards — the other side of the same platform.
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.