Genies Pay / SDK

You start a payment. You get a result. You never see a PAN.

Written for whoever has to put this in an app: what you call, what comes back, and what deliberately stays outside your scope.

Shape

Three calls and a stream.

PaymentActivity.kt · your app
// 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 surface, the full state model and the integration guide ship as companion volumes with the API reference and Postman collections.

What you get, and what you do not

The scope boundary is the point.

Yours

  • The trigger — you decide when a payment starts, and for how much
  • The result — an outcome and a reference you can store against your own order
  • The state model — enough to render progress honestly in your own UI
  • Configuration and validation against the terminal profile, at start-up

Not yours

  • The PAN — card data is captured and handled by the payment application, not your app
  • The PIN — entered on the certified pad, blocked under DUKPT, translated in the HSM
  • The EMV conversation — kernel, APDU, TLV and cryptogram all sit behind the deep link
  • The certification — EMV Level 3 runs against the terminal and kernel, not your build
QR SDK

Offline dynamic codes, bound to the device.

A separate SDK for a bank or wallet application, generating EMVCo customer-presented codes without connectivity and binding each one to the device that produced it.

seconds until it refreshes · bound to this device

  • Dynamic codes generated on the device, refreshing every twenty seconds
  • Generated offline — no connectivity required to produce the code
  • Every code bound to the registered device at generation
  • Verified by Secure Point against the binding and the validity window
  • Merchant-presented static and dynamic codes supported on the same path

The pattern shown is decorative and encodes nothing.

Security in the build

Three things that ship with the application.

BUILD

Obfuscation

Code obfuscation in the release build.

TRANSPORT

Certificate pinning

The application pins the certificates it will talk to.

RUNTIME

Tamper & attestation

Checks against Tantra AM before the terminal is allowed to transact.

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.