In-App Payments

Lib Lite is the Scan to Pay in-app payment SDK. It gives mobile-app developers a turnkey checkout experience: a single SDK call brings up the Scan to Pay payment flow, the customer pays with a card on file (or registers a new one), and the SDK returns control to your app with a transaction reference.

If you've built an e-commerce or services app and want to accept card payments without writing your own checkout UI or going through PCI scope, Lib Lite is the right choice. If you want to build your own UI against the platform, use E-commerce custom checkout or Bluebox hosted checkout instead.

This section covers both platforms — Android and iOS — and walks through the SDK from installation to handling the payment response.

What Lib Lite does

You provide:

• A transaction code (created server-side via the Codes API)
• An API key (issued in the Portal under Lib Lite Tokens)
• One SDK invocation in your activity / view controller

You get back:

• A success / failure / cancelled callback
• A transaction reference you verify server-side

Architecture at a glance

   Your app                Your backend            Scan to Pay
   ────────                ────────────            ───────────
        │                        │                      │
        │   create order          │                      │
        ├───────────────────────► │                      │
        │                        │                      │
        │                        │   /code (create)      │
        │                        ├─────────────────────► │
        │                        │ ◄─────────────────────┤
        │                        │   { code: "1234567890" }
        │                        │                      │
        │ ◄───────────────────── ┤                      │
        │   code + apiKey        │                      │
        │                        │                      │
        │ launch Lib Lite        │                      │
        │ Intent / Scan to PayKit │                      │
        │  ────────────────────────────────────────────► │
        │                        │                      │
        │  user pays inside the SDK (card + PIN/3DS)    │
        │  ◄──────────────────────────────────────────  │
        │                        │                      │
        │  result + txReference  │                      │
        │                        │                      │
        │  POST result + ref     │                      │
        ├───────────────────────► │                      │
        │                        │   webhook for ref    │
        │                        │ ◄────────────────────┤
        │                        │  or /transactionState/{id}
        │                        ├─────────────────────► │
        │                        │                      │
        │                        │  verify before fulfilling order

Critical: Never trust the SDK's success callback as authoritative. Always confirm via webhook or /transactionState on your backend before shipping goods or releasing services.

Which path is right for you?

You can use Lib Lite alongside any of the above — for example, an in-app Lib Lite primary flow with an Pay-by-App fallback to launch a banking app.

Prerequisites

Before you start the SDK integration:

1. A live or sandbox merchant account — onboarded via the Portal or the Merchant Onboarding API
2. A Lib Lite API token — generated in the Portal: log in → Email dropdown → Lib Lite Tokens → Generate
3. A backend that can create codes — typically a POST /code call. See Managing QR codes for the API.
4. Webhook or polling integration — to confirm the transaction. See Webhooks or Querying transactions.

⚠️

Codes must be fixed-amount for Lib Lite. Variable-amount codes are rejected by the SDK with CODE_NOT_VARIABLE_AMOUNT. Set the amount when you create the code on your backend.

Platform requirements

Lib Lite uses the device camera (for QR scanning at registration), location (for fraud screening), and SMS reader (Android-only, for OTP retrieval). Permissions are requested by the SDK as needed — your app doesn't have to pre-declare them all, but you should be aware they'll appear.

Section structure

What's next

• Get the SDK → SDK downloads
• Start an Android integration → Android — Overview
• Start an iOS integration → iOS — Overview
• How to create codes for the SDK → Managing QR codes
• Confirm payment server-side → Webhooks or Querying transactions