QuickStart

Redcarpet Card SDK

Redcarpet Card sdk is devided in to four parts

1. Customer Onboarding SDK
2. Redcarpet Card Managemet SDK
3. Money Management SDK
4. Bill/Emi Payment SDK

Redcarpet Android Sample Application

You can refer to the Redcarpet Android Sample App to learn how the SDK has been integrated.

Redcarpet Android SDK Integration

Prerequisites

• You need redcarpet API Key to initilize redcarpet sdk. You can use the Test Keys for a sandbox experience. please user Production keys when going live with application

Integration Steps

Step 1: Install Redcarpet Android Standard SDK

• Currently We distribute our SDK to the approved partenr. Download the latest versions of the SDK from shared url by redcarpet and place the aar file inside the libs folder.
• To add the SDK to your app, add the following dependency in your app's build.gradle file:

repositories {
    mavenCentral()
}
dependencies {
    implementation "com.redcpt:sdk:0.0.1"
    implementation "com.redcpt:sdk-expensemanager:0.0.1"
    implementation "com.redcpt:sdk-otp:0.0.1"
    implementation "com.redcpt:sdk-permissions:0.0.1"
    implementation "com.redcpt:sdk-utilitiessdk:0.0.1"
    implementation "com.redcpt:sdk-verification:0.0.1"
    implementation "com.redcpt:sdk-services:0.0.1"
    implementation "com.redcpt:sdk-appwisesdk:0.0.1"
}

Step 2: Initialize Redcarpet Android SDK

• Initialize Redcarpet android SDK in app application class.

class SampleApplication : Application() {

    lateinit var sdk: RedCpt
        private set

    override fun onCreate() {
        super.onCreate()
        sdk = RedCpt.init(this, "<API KEY>")
    }
}

• Enable debug mode to see the debug logs

sdk.setDevMode(true)

• Now Redcarpet SDK initilize successfully.

Step 3: Integrate OTP services

• Integrate otp services, verify otp to signup new user and login old user.
• Check OTP verified or Not

sdk = (application as SampleApplication).sdk
var isOtpVerified = sdk.isOtpVerified() // return boolean true/false

• Send OTP

otp = sdk.getOtpInstance()
otp.signup(phoneNumber, <otp_send_retry_count>, object : Otp.SignupCallback {
    override fun onError(response: SignUpResponse?, error: Throwable?) {
        when {
                error != null -> phoneNumberErrorState(error.message)
                response != null -> phoneNumberErrorState(response.message)
             }
        }
    override fun onSuccess(response: SignUpResponse) {
        }
})

• Verify OTP

 otp.verify(phoneNumber, password, object : Otp.VerifyCallback {
    override fun onError(response: VerifyResponse?, error: Throwable?) {
            when {
                 error != null -> otpErrorState(error.message)
                    response != null -> otpErrorState(response.message)
            }
        }

    override fun onSuccess(verifyResponse: VerifyResponse) {
        loginRoot.postDelayed(1000) {
             finish()
            }
        }
    })

Step 4: Signup User

• After the successful otp verification, submit user personl info

verificationCallback.savePersonalDetails(
    "<User Name>",
    "<User Email>",
    "<User DOB>",
    "<Gender>",
    "<Referral code>",
    object :
        VerificationCallback.Callback<com.redcpt.onboardingsdk.models.GenericResponseModel> {
            override fun onFail(
                t: com.redcpt.onboardingsdk.models.GenericResponseModel?,
                    throwable: Throwable?
                ) {
                    Log.e("error response ", t.toString())
                    Log.e("error response ", throwable.toString())
                }
            override fun onSuccess(t: com.redcpt.onboardingsdk.models.GenericResponseModel) {
                if (t.result.equals("success")) {
                   Log.e("Funnel", t.message.toString())
                }
            }
        }
    )

What is a ledger?

Ledger is a fully managed loan system to get your started with your next big (or small) FinTech idea. It includes an immutable double entry ledger that takes care of all your accounting variables, payments, settlements, charges etc. Along with the support for managing multiple instruments (card, UPI, tokenization) and lenders.

Loan systems can get complex. Gateway webhooks can fail. Resulting in customer’s payments getting delayed. Resulting in wrongful late fee applications. Resulting in people outside your office willing to low-key beat you up. And even if you somehow make it through, the trouble isn’t all over. Your lender, who still functions on medieval technology, expects you to support its data APIs in an absurdly peculiar format. By API we mean an Excel sheet.

Ledger handles all of that for you. It was made after several iterations and learnings of 5 years at RedCarpet and now we are sharing it with the world.

How does it work?

Events

Everything is associated with an event in the Ledger. Primarily, an event contains the metadata related to the event, time of the event and the time at which it got processed.

The above event signifies a card transaction worth rupees 100. Metadata can be anything which can help you identify a particular event. In this case it’s an id of a table where the raw transaction data is stored.

Ledger entry

Each event can have multiple ledger entries linked to it. A ledger entry signifies the actual movement of money between accounts.

Let’s take a look at the corresponding ledger entry for the aforementioned event.

To understand what the account strings mean go to the Book account section.

The account balance of both the accounts is calculated and stored within the entry. In the above example, the balance of the card balance account which got credit became ₹9900 after a transaction of ₹100. This calculation works on the actual bookkeeping principle. Here’s a table to show whether there will be an increase or decrease depending on what type of account it is.

For the accounts to remain in balance, a change in one account must be matched with a change in another account. To make sure this constraint always holds true we have designed the process in a way so it’s mandatory to have a debit and a credit account against the same amount.

Book Account

A book account consists of 4 variables. These accounts are used in the ledger entry as debit or credit. The book accounts are represented at different hierarchy levels. There can be a loan level account, a bill level account or a card level account etc. For example, a user can have a card level limit and a user level limit. User level limit will signify the total limit a user is allowed whereas the same user can have multiple cards with their own individual limits.

Let’s dissect a book account we saw above to understand how it’s represented.

Processes

Doing a card transaction.

A card transaction process involves a couple of events which get triggered before the actual transaction event. Let’s take a look at them.

Funds received from the Lender

Lender transfers the funds to a Nodal account. This account is usually managed by the bank’s issuer processor. We use these funds to load money into cards for the transaction to happen.

create_ledger_entry_from_str{
    session,
    event_id=472,
    debit_book_str="15643/lender/pool_balance/a",
    credit_book_str="26346/loan/lender_payable/l",
    amount=100000,
}

Loading the customer’s card

Before a transaction can be processed the card needs to have some balance in it. Depending on what process of money load you follow, this step can either be JIT (Just in time) load at the time of transaction happening or beforehand. Here we are showing the beforehand load.

This event loads up the balance account in Ledger and reduces the money from the Nodal account. At this point we will also call the APIs of the bank’s issuer processor to actually move the money to the card.

create_ledger_entry_from_str{
    session,
    event_id=543,
    debit_book_str="26346/loan/card_balance/a",
    credit_book_str="15643/lender/pool_balance/a",
    amount=10000,
}

As can be seen, the prepaid card’s balance became 10,000 and the Nodal account’s balance got reduced by the same.

Card transaction

Now that we have money in the card, it can be used to do transactions on e-commerce websites, POS machines or ATMs. In this entry, we have debited the user’s loan account and reduced the card balance by the same amount.

create_ledger_entry_from_str{
    session,
    event_id=547,
    debit_book_str="56345/bill/unbilled/a",
    credit_book_str="26346/loan/card_balance/a",
    amount=100,
}

At redcarpet whenever the transaction is made by the user through his/her card a disbursement takes place in the user's CF (Card Facility) account. i.e A disbursement happens on the CF account by debiting it every time the customer uses their card to do a transaction. These transactions can happen on websites, POS machines, and ATMs.

Generating the monthly statement

Just like how in credit cards, a monthly statement gets generated showing debits and credits from the previous month, the same gets done in this step. This happens on the 1st of every month. We list all the transactions, charges, refunds, and payments from last month and show them in a statement. The statement also contains details like the minimum amount to pay, due date, and the maximum amount to pay to avoid interest (before the due date).

create_ledger_entry_from_str{
    session,
    event_id=547,
    debit_book_str="56345/bill/principal_receivable/a",
    credit_book_str="56345/bill/unbilled/a",
    amount=100,
}

create_ledger_entry_from_str{
    session,
    event_id=547,
    debit_book_str="56345/bill/min/a",
    credit_book_str="26346/bill/min/l",
    amount=11.33,
}

create_ledger_entry_from_str{
    session,
    event_id=547,
    debit_book_str="56345/bill/max/a",
    credit_book_str="56345/bill/max/a",
    amount=100,
}

Accrual of financial charges

In accounting accrued interests are generally computed and recorded at the end of a specific accounting period as adjusting journal entries used in accrual-based accounting. Interest gets accrued the next day after the due date. The due date is set to the 15th of every month for all loans.

create_ledger_entry_from_str{
    session,
    event_id=587,
    debit_book_str="56345/bill/interest_receivable/a",
    credit_book_str="56345/bill/interest_accrued/r",
    amount=3,
}

create_ledger_entry_from_str{
    session,
    event_id=587,
    debit_book_str="56345/bill/max/a",
    credit_book_str="56345/bill/max/l",
    amount=3,
}