Converged Wallet App

The Converged Wallet App option is for banks and fintechs that already have a customer-facing app and want Scan to Pay's QR-payment functionality to live inside that app, rather than as a separate co-branded download.

You own the entire customer experience. Scan to Pay supplies the payment engine, surfaced through a combination of native SDKs and the Remote API.

If you want to build everything yourself from scratch, see Remote API overview instead.

How Converged differs from Remote API direct

Option	Who builds the app	Who builds the QR flow	Brand
Converged (this page)	You	EFT Corp supplies SDK; you embed it	Yours, integrated with your existing app
Remote API direct	You	You	Yours, built from scratch against the API

Converged is the middle ground: you keep your existing app's brand and navigation, you control onboarding and customer support, but the actual scan-and-pay journey uses Scan to Pay's pre-built UI components and payment logic.

What you get

Component	Detail
Native SDKs	Android (AAR) and iOS (XCFramework) packages that surface scan-and-pay screens inside your host app
PinSecLib	The PCI-compliant PIN-entry component — required for AMT transactions
3DS WebView component	Pre-built WebView that handles the ACS challenge for 3DS-secured cards
Card-vault integration	Hooks into your existing card-on-file vault, or uses Card Provisioning if you don't have one
Remote API client	Wraps `/generateTransactionId`, `/purchaseTx`, `/transactionState`, etc. — you don't have to call the raw API
Push deep-link handlers	For app-to-app QR flows from third-party merchants
Documentation and sample apps	Reference integrations in Kotlin and Swift

Typical screens you embed

The Converged flow surfaces a handful of pre-built screens inside your app's navigation:

Screen	What it does
QR scanner	Camera scan + paste-code fallback. Recognises 10-digit codes, EMV TLV, short URLs, and scheme deep-links.
Merchant confirmation	Shows merchant name, amount, tip / partial-payment inputs. The user confirms.
Card picker	Lists cards from your vault (or via Card Provisioning) that the merchant accepts.
PIN entry (PinSecLib)	PCI-compliant PIN keypad — locked-down UI, can't be screenshotted or screen-recorded.
3DS challenge	WebView for OTP / step-up authentication when the card requires it.
Transaction result	Success / failure screen with receipt details and share-receipt action.
Transaction history	The last 10 Scan to Pay transactions for this MSISDN, formatted for display.

You decide where these screens live in your app's information architecture — typically under a "Payments" or "Pay" section. The SDK exposes them as fragments / view controllers you push from your own navigation stack.

Architecture sketch

        Your bank app (host)
        ───────────────────
        │
        │   Your navigation, your brand, your other features
        │
        │   ┌─────────────────────────────────────────┐
        │   │  Scan to Pay SDK (embedded)             │
        │   │  ───────────────────────────            │
        │   │                                         │
        │   │  • Scanner   • PIN keypad   • 3DS WV    │
        │   │  • Card picker   • Result screens       │
        │   │                                         │
        │   │  Remote API client ─────────────────────┼────►  qa/live.scantopay.io
        │   └─────────────────────────────────────────┘
        │
        │   Your auth, your card vault, your push
        │   ───────────────────────────────────
        │       │
        │       └────────►  Card Provisioning API  ────►  qa/live.scantopay.io

The SDK is sandboxed within your app's process — it doesn't open separate web views or spawn its own background services beyond what's required for payment processing.

Who this is for

You are…	Is Converged right?
Major SA bank with an existing mobile app	Yes — this is what most banks adopt
Fintech with an existing app + you want to add QR payment	Yes
Bank without an existing app	No — speak to your account manager about turnkey wallet options outside this section
PSP wanting to issue wallets to your merchants' customers	No — PSPs are usually on the merchant side. Speak to your account manager.
Engineering-rich startup that wants pixel-perfect control	Maybe — consider Remote API direct if SDK constraints don't fit your design language

What you provide

To start a Converged integration, you'll need:

An existing app with a clear place where the payment journey will sit
Android and / or iOS engineering capacity to integrate the SDK (typical effort: 4-8 weeks)
Backend integration for transaction reconciliation (your ledger gets webhooks from the platform)
Customer support readiness — your tier-1 will handle "I added a card" questions
Card vault decision — use your own or use Card Provisioning; both are supported

What you do operationally

You own:

App distribution, releases, App Store / Play Store relationship
Your app's full UX outside the embedded flows
Customer authentication and biometric unlock (the SDK trusts your auth state)
Card vault (if not using Card Provisioning)
Tier-1 customer support
Your app's analytics and crash reporting

EFT Corporation owns:

SDK maintenance and OS-version compatibility
Platform uptime and monitoring
Tier-2 / tier-3 escalations for platform issues
Card-scheme compliance
New issuer / BIN onboarding
AMT and 3DS authentication flows

What's NOT customisable

The SDK keeps certain things locked for security and compliance:

Locked component	Why
PIN entry UI	PinSecLib's keypad layout, timing, and screenshot protection are PCI-mandated
3DS WebView content	Issuer-controlled. We pass it through unchanged.
Scan to Pay attribution	Required on the transaction confirmation screen for scheme compliance
Card validation logic	Luhn, BIN lookup, expiry validation — non-negotiable for fraud prevention

You have full styling control over everything else — colours, fonts, button shapes, navigation transitions, screen layouts of the non-locked screens.

Theming and styling

The SDK exposes theming hooks for:

Primary / secondary / accent colours
Font family (must support the character set; we'll catch missing glyphs in QA)
Button shape (radius, padding)
Icon set (some icons can be replaced — PIN-entry icons cannot)
Light / dark mode support
Animation speeds

For specifics on what's themeable per screen, ask your integration engineer for the latest Converged Theming Guide — it's a per-release document because the surface evolves.

Integration walk-through

The typical Converged integration runs through these phases:

Phase	Duration	Activities
Discovery	1-2 weeks	UX review, IA mapping, identifying where the SDK lives in your app
SDK delivery	1 week	EFT Corp provides SDK + sample apps + docs
Build integration	3-5 weeks	Your engineers wire up SDK, hook to your auth, theme
Sandbox testing	2-3 weeks	End-to-end tests on QA, fraud-rule tuning, edge cases
UAT	1-2 weeks	Your QA + business teams run scenarios
Production cutover	1 week	Go-live, ramped roll-out, on-call coverage

Total: 10-14 weeks, app-engineering-team dependent.

Versioning and SDK upgrades

Topic	Detail
Release cadence	New SDK minor versions every ~3 months
Backwards compatibility	Major versions every 18-24 months; we provide a migration guide and 6 months overlap
Security patches	Out-of-band as needed; we'll notify your tech lead directly
OS support	Android 9+ (API 28), iOS 14+

You're expected to be on a supported SDK version. We don't enforce upgrade deadlines for minor versions, but security patches and major versions follow the policy in your integration agreement.

What's next

Want full control with no SDK? → Remote API overview
How the underlying Remote API works → Purchase flow
Linking cards to wallet profiles → Card provisioning
Start a conversation → [email protected]