Overview
Lib Lite — the Scan to Pay Android in-app payment SDK. What it is, what you'll need, and how the pieces fit together.
Lib Lite is the Android in-app payment SDK from EFT Corporation. It's distributed as an .aar package and embeds a complete Scan to Pay checkout experience inside your activity — your app passes a transaction code and an API key, the SDK handles the rest, and your activity gets a callback when it's done.
For the cross-platform context, see In-App Payments overview.
What the SDK gives you
| Component | Purpose |
|---|---|
LibLiteActivity | The main payment activity. Launch via Intent; receive the result via Activity Result. |
LibLiteWalletActivity | Standalone card-management — add / remove cards without making a payment. |
LibLitePreRegActivity | Optional pre-registration flow — register a card before the first payment. |
PayByCardButton | Drop-in button view that launches LibLiteActivity. |
PayByAppButton | Drop-in button view that lets the customer hand off to a supported bank app. |
LibLiteLoading | Pre-built progress dialog you can show while creating a code server-side. |
Prerequisites
Before you start integrating:
| Requirement | Why |
|---|---|
| Active merchant account | You can't accept payments without one. Get onboarded via the Portal or Merchant Onboarding API. |
| Lib Lite API token | Generated in the Portal: log in → email dropdown → Lib Lite Tokens → Generate. One token per app per environment. |
| A backend that can create codes | The SDK consumes codes; it doesn't create them. See Managing QR codes. |
| A webhook receiver or polling integration | The SDK's success callback isn't authoritative. Confirm server-side via Webhooks or Querying transactions. |
| SMS hash | For OTP retrieval. Compute as per Google's SMS Retriever guide. |
Codes must be fixed-amount. Variable-amount codes are rejected withCODE_NOT_VARIABLE_AMOUNT. Set the amount when you create the code.
How the SDK is wired
┌────────────────────────────────┐
│ Your app │
│ │
│ ┌─────────────────────────┐ │
│ │ Activity │ │
│ │ ↓ launches via Intent │ │
│ └─────────────────────────┘ │
│ ↓ │
│ ┌─────────────────────────┐ │
│ │ Lib Lite SDK │ │
│ │ • LibLiteActivity │ │
│ │ • Wallet, PreReg │ │
│ │ • Buttons + dialog │ │
│ └─────────────────────────┘ │
│ ↓ │
└────────────────│───────────────┘
│
↓ HTTPS
┌─────────────────────────────────┐
│ Scan to Pay platform │
│ (QA: qa.scantopay.io/pluto) │
│ (Live: scantopay.live/pluto) │
└─────────────────────────────────┘The SDK sandboxes itself inside your app's process — no background services, no separate processes. It opens a child activity, runs the checkout, returns a result.
A complete payment in 4 lines
The simplest possible Lib Lite integration:
Intent intent = new Intent(context, LibLiteActivity.class);
intent.putExtra(LibLiteActivity.IN_CODE, "1234567890");
intent.putExtra(LibLiteActivity.IN_API_KEY, "YOUR_API_KEY");
intent.putExtra(LibLiteActivity.IN_HASH, "YOUR_SMS_HASH");
intent.putExtra(LibLiteActivity.IN_SYSTEM, "TEST"); // or "LIVE"
libLiteActivityLauncher.launch(intent);Step-by-step in Payments.
What the SDK does NOT do
| Create codes | Your backend does this via /code |
| Verify final payment status | You confirm via webhook or /transactionState |
| Reconcile | Settlement and reconciliation are merchant-side |
| Refund | Use the Refunds and reversals API server-side |
The SDK is a checkout component, not a payment platform — keep that boundary clean.
What's next
- Install the SDK → Installation
- First payment → Payments
- Use the drop-in button → Pay-by-Card button
- App-to-app handoff → Pay-by-App button
- Card management → Manage Card
Updated 2 days ago