Wiring OneCard transactions, statements and UPI rails into a Python or Node back-end

Behind OneCard's metal card sits a multi-bank issuer stack — South Indian Bank, Federal Bank, BOBCARD, CSB Bank, Indian Bank and SBM (State Bank of Mauritius), per the app's own Play Store listing — plus a RuPay UPI rail layered on top of the credit line so cardholders can scan QR codes against the same balance. For a fintech back-end that wants this picture in a normalized shape, the build splits cleanly. Card-side records (transactions, statements, limits, rewards, EMIs) follow one path. UPI-rail records (handle, history, payee map) follow a parallel one. We have put both into a Python or Node SDK before; what follows is the route, the surfaces and the engineering, written for a team that wants the data in code rather than on a dashboard.

The bottom line for an integrator: this is not a single ledger. It is a card ledger and a UPI ledger that happen to share an account holder and an app shell. Plan for both, name them separately downstream, and the rest of the build follows.

The data this app sits on

Rows below reflect the surfaces a cardholder sees inside OneCard and confirms during the build. Field names are normalized to a single schema the SDK exposes; the underlying issuer payload differs per partner bank and is mapped during ingestion.

Routes that carry the data

Two to three of these typically apply on one build. We pick the route during scoping and write the SDK against it; the others remain available for future widening.

1. Authorized interface integration against the cardholder's own session

The path that actually carries card-side data today. Under the cardholder's written consent and the studio's NDA, we map the authenticated portal and app surfaces that already render their transactions, statements, EMI ledger, rewards and UPI history. Access is arranged with the client during onboarding — a sponsor account or a consenting test user is set up as part of the engagement, not asked for before we start. Durability is good because the surfaces are the ones a paying customer relies on; if a screen moves, the regression rig flags the field.

2. User-consented credential access via a sandboxed worker

For teams running a PFM-style consent UX who would rather keep the cardholder's session in a vault than build a custom client. The SDK runs inside a hardened worker, refresh tokens cached, scope limited per project. Effort is lower than route 1, durability comparable, but the integrator carries the credential-handling responsibility.

3. Account Aggregator framework, for the linked bank picture

India's NBFC-AA framework is regulated by the RBI and, per the Department of Financial Services material, currently scopes deposit accounts, mutual funds, insurance and pensions on the FIP side; Sahamati lists the registered AAs. Credit card statement data is not part of that FIP scope at the time of writing, so a regulated AA pull is not the right tool for the OneCard ledger itself. The framework is the right tool, however, for the bank account that auto-debits the OneCard bill or the deposit that backs an FD-backed card — we wire that flow separately and join it to route 1 inside the SDK.

4. UPI Switch via a PSP, only where the use-case demands it

For integrators who are themselves a PSP or merchant aggregator and need the UPI side natively rather than through OneCard's ledger. Most read-only integrations do not need this, but it is named here so the boundary is clear.

For most back-ends the path that actually delivers is route 1, with route 3 grafted in where the linked bank's deposit ledger widens the picture. Route 2 fits when the integrator already has a credentials-in-vault posture; route 4 is for the narrow PSP case.

What lands in your repo when this ships

Deliverables are sequenced so the parts a back-end engineer cares about land first. Specification artefacts and the compliance memo land alongside them, not in place of them.

• Python SDK (3.11+, typed via Pydantic) and a Node.js client (18+, typed via Zod) covering statement queries, transaction list with cursor-based delta sync, EMI ledger, rewards balance and UPI history. Installable via pip and npm, with example notebooks for each surface.
• Webhook handler with an event store keyed on transaction RRN (UPI side) and authorization-id (card side) — the references your reconciliation already speaks. Runs as a small FastAPI or Express service or as a Lambda; both shapes shipped.
• Regression rig with transcript fixtures of the recorded auth flow and a mocked issuer response set, re-runnable when the upstream surfaces shift.
• Batch backfill script for the prior 24-month statement window where the consenting account retains it, so the historical ledger lands in one pass.
• Normalized schema definitions mapped against a fintech-style ledger so two cardholders on different partner banks land in the same shape.
• OpenAPI / Swagger specification for the hosted-endpoint option, ready for client generation in other languages.
• Auth-flow and protocol notes — the token chain as it sits in OneCard's flows, captured during the build, with the parts a maintainer needs called out.
• Compliance memo covering the consent-record format, the data-minimization choices, and a retention policy that fits the client's regulator.

A sample call against the statement and UPI surfaces

Illustrative — actual field names and endpoints are confirmed during the build, against the consenting account's surface. The Python shape below is what a back-end engineer typically imports on day one.

from openfinance_lab.onecard import OneCardClient, ConsentBundle
from datetime import datetime, timezone, timedelta

client = OneCardClient(
    consent=ConsentBundle.load("client_consent.json"),
    session_store="redis://internal-redis:6379/3",
)

# 1. Current billing cycle statement (issuer-mapped to a single shape)
stmt = client.statements.current()
print(stmt.cycle_start, stmt.cycle_end,
      stmt.total_due_inr, stmt.min_due_inr,
      stmt.payment_due_date, stmt.issuer_bank)

# 2. Transactions since a cursor — handles both rails in one iterator
since = (datetime.now(timezone.utc) - timedelta(days=7)).isoformat()
for txn in client.transactions.since(cursor=since):
    if txn.rail == "rupay_upi":
        # UPI-on-credit-card leg: carries VPA and RRN
        ledger.write_upi(rrn=txn.rrn, vpa=txn.payee_vpa,
                         amount_inr=txn.amount_inr, mcc=txn.mcc)
    else:
        # Card-network swipe: carries auth-id and merchant
        ledger.write_card(auth_id=txn.auth_id, merchant=txn.merchant,
                          amount_inr=txn.amount_inr, mcc=txn.mcc)

# 3. EMI ledger — open loans converted via Anytime EMI
for loan in client.emis.open():
    print(loan.source_txn_auth_id, loan.principal_inr,
          loan.rate_pa, loan.remaining_tenor_months,
          loan.foreclosure_fee_inr)

# 4. Rewards balance and recent accruals
balance = client.rewards.balance()
recent = client.rewards.accruals(cycle=stmt.cycle_label)

Errors are surfaced through typed exceptions, not opaque HTTP codes. ConsentLapsed names which scope expired so the operator can re-prompt with a specific message; IssuerSurfaceChanged points at the field that moved and is meant to be caught by the regression rig before a back-end notices.

Consent, RBI rules, and where AA fits

OneCard sits inside the RBI's credit-card licensing perimeter on the card side (the issuer is the partner bank — SIB, Federal, BOBCARD, CSB, Indian Bank or SBM, per the Play Store listing) and inside NPCI's UPI rules on the UPI side. The data we ingest is the cardholder's own data, fetched on their authorization. We log each consent grant, scope and expiry; scope is constrained to the surfaces named in the engagement, so a reward-optimization use-case does not also pull a full KYC dump.

The RBI Account Aggregator framework, operated by RBI-licensed NBFC-AAs (Sahamati maintains a public register), is the consent rail for deposit accounts, mutual funds, insurance and pensions on the FIP side. Credit card statement data is not in that FIP scope today — so we do not pretend an OneCard pull fits an AA consent artefact. Where the linked bank deposit feeds the picture, that part runs through AA on a separate consent and joins the OneCard streams in the SDK. The two are kept distinct in the audit log so the regulator-facing record reflects what was actually shared, by whom, under which framework.

Two judgments the build hangs on

These are the calls the studio makes for the integrator, written down because they shape the deliverable more than any wire detail.

Six issuers, one schema. OneCard is issued by six partner banks, and the back-end fields differ by issuer — settlement reference formats, statement PDF templates and reward postings are not uniform across SIB, Federal, BOBCARD, CSB, Indian Bank and SBM. We map each issuer variant into a single normalized record type during the build, and the SDK exposes issuer_bank as a field rather than a routing axis. A back-end that handles a mixed customer base does not have to branch by issuer downstream.

Two rails, two iterators. UPI-on-credit-card transactions arrive on a different leg of the OneCard ledger than card-network swipes — same app, same balance, different rail. We split the SDK into separate iterators (transactions versus upi_history) and tag every record with its rail, so the downstream reward, MCC and reconciliation rules can be applied per-rail rather than guessed from the merchant string. This is the call that saves the most engineering on the integrator's side; getting it wrong means a downstream rule treats a credit-card UPI payment as a swipe.

What the surfaces look like in the app

The screenshots below come from the Play Store listing. They show the surfaces the integration reads from, not internals.

What we checked, and when

Source pages read for this brief, all opened in early June 2026: OneCard's Play Store listing (issuer list, UPI-on-credit-card framing, fee structure quoted in the description); the issuer's getonecard.app FAQ (cardholder-side features and operational notes); the Government of India's Account Aggregator framework page (scope and FIP categories); and Sahamati's register of NBFC-AAs. Fees, partner-bank names and feature descriptions on this page reflect what those sources said at that time; we re-check them when a maintenance pass runs.

OpenFinance Lab · integration mapping, June 2026.

Other credit and UPI apps a unified pipeline would touch

• Slice — virtual prepaid plus UPI rails for everyday spend; the UPI side overlaps OneCard's UPI ledger and is often pulled in the same project.
• CRED — credit card bill payments and rewards, sitting on top of an aggregated card view rather than issuing its own line.
• Uni — pay-in-thirds credit experience; transaction and EMI shapes are comparable to OneCard's, and the EMI ledger normalizes the same way.
• Jupiter — neobank that bundles a deposit account, a card and UPI; useful when the unified pipeline needs the bank-side picture too.
• LazyPay — BNPL credit line and UPI; carries a similar EMI and bill-pay surface.
• Niyo — multi-currency card and bank integration; relevant when the unified pipeline includes forex or travel card data.
• BharatPe — merchant-side UPI and credit; the counterpart to OneCard's payer-side UPI on the same rails.
• Paytm — wallet, UPI and partner-bank credit cards; comparable issuer-stack model, much broader surface area.
• KreditBee — credit line app with EMI and repayment ledgers, often appearing in the same back-end alongside OneCard for personal-finance products.
• CheQ — credit health and credit card payments; consumer-side aggregator that reads several of the same surfaces.

Questions integrators have asked

Why a Python or Node SDK rather than just an OpenAPI spec we hit ourselves?

The SDK carries the session refresh logic, the consent-bundle handling, the rate-limit politeness and the field normalization across the six partner-bank variants. You still get the OpenAPI spec and the auth-flow report; the SDK is the part that turns those into something a back-end imports in one line.

How does the SDK keep up if OneCard changes a screen or a field name?

The regression rig ships with transcript fixtures of the recorded flow. When OneCard changes a screen or renames a field, the test points at the variance, so the fix lands in a typed-schema bump rather than a debugging session driven by a downstream report. We re-run the rig on a maintenance cadence agreed with the client.

Where does the Account Aggregator framework actually fit for an OneCard pipeline?

AA is the right tool for the linked bank picture — the savings account that pays the bill, the deposit account behind an FD-backed card. For the OneCard ledger itself (transactions, statements, rewards, EMIs), credit card records are not part of the NBFC-AA FIP scope today, so we route those through authorized interface integration against the cardholder's own session, and join the two streams in the SDK.

Can the build cover the UPI-on-credit-card leg without separate NPCI onboarding?

Yes for read-side ingestion — the UPI transactions land in the OneCard ledger and the SDK exposes them as a separate iterator. Native UPI Switch onboarding via a PSP is a different project; we point that out if the use-case crosses into it.

Take the next step

A typical OneCard delivery hands back the Python SDK, the Node client, the auth-flow report, the OpenAPI specification, the webhook handler and the regression rig inside one to two weeks from kick-off. Source-code delivery starts at $300 and is paid after delivery, once the client is satisfied with what landed in the repo. For teams that want to skip the upfront build, the same surfaces can be called against our hosted endpoint on a pay-per-call basis with no upfront fee. Send the slice of OneCard data your back-end needs, the issuer mix on your customer base, and the consent flow you already run; a scoped quote comes back the same week. Start a brief at /contact.html