What a BharatPe for Business merchant account holds, and how we reach it

A BharatPe merchant login sits on top of a settlement ledger. Every QR collection and every BharatSwipe card swipe lands there, then a payout — on-demand or the day-end auto settlement — carries a UTR that ties the money to a bank statement. That UTR is the thread most integrations are actually after. Match it, carry the fee deductions, and a merchant's takings reconcile cleanly against the account they bank into.

The practical picture: the transaction-level and settlement detail only exists inside the BharatPe surface, so an authorized interface integration is the source of the UTR-level record. Where a project also needs the bank-verified view of the same payout, an Account Aggregator consent for the settlement account adds it. The downloadable reports handle historical backfill before the live feed is switched on. Below is what each of those surfaces holds and how we work them.

Data behind a BharatPe merchant login

Field names differ between the app's screens and its exports; part of the build is settling on one vocabulary so a downstream system reads UPI, card and settlement rows the same way.

Getting the data out, authorized

Interface integration under the merchant's consent

The merchant app and the enterprise dashboard together expose everything the merchant sees — collections, card takings, settlements, the reconciliation report, balance and loan status. Working against them under the merchant's authorization reaches the full record, including the UTR detail that no bank-side route carries. Effort is medium. Durability tracks the front end, so the design assumes the dashboard can shift and plans a re-check for it. Access is set up with the merchant during onboarding, and we capture the auth and token chain as part of that.

RBI Account Aggregator consent

For the bank account BharatPe settles into, an Account Aggregator consent pulls statements through a regulated Financial Information Provider. This is the durable, regulated path for the money after it leaves BharatPe — high stability, but it sees the bank side, not the QR-versus-card breakdown inside the app.

Native report export

BharatPe's own settlement and reconciliation reports download as files with UTR and deduction detail. Low effort, batch rather than real-time — useful for backfilling history before the live feed goes on.

For a BharatPe merchant, we build the interface integration first because the settlement and UTR detail lives only there; the Account Aggregator consent is added when a project needs the bank-confirmed view of the same payout, and the report export seeds the historical rows. Which of those a given engagement needs depends on whether you care about the takings breakdown, the banked money, or both.

A settlement query, sketched

Illustrative shape only — the exact fields and auth are confirmed during the build against a consenting merchant account, not asserted here.

POST /merchant/settlements/query
Authorization: Bearer <session-token>    # token chain mapped during onboarding
Content-Type: application/json

{ "merchant_id": "<consented merchant>",
  "from": "2026-06-01", "to": "2026-06-30",
  "types": ["ON_DEMAND", "DAY_END_AUTO"] }

--- response (normalized by us) ---
{ "settlements": [
    { "utr": "AXISCN0XXXXXXXXX",
      "settled_at": "2026-06-14T18:42:05+05:30",
      "gross": 48250.00, "fees": 121.30, "net": 48128.70,
      "instrument_mix": { "upi": 41100.00, "card_bharatswipe": 7150.00 },
      "status": "SETTLED" } ],
  "next_cursor": null }

# reconcile: key on utr, not the collection-time ref;
# carry fees as a separate ledger line so gross/net both survive.

What lands in your repo

Every deliverable is cut against the BharatPe surfaces above:

• An OpenAPI/Swagger specification for the settlement, collection and card-takings queries, with the normalized takings schema.
• A protocol and auth-flow report: the session/token chain, refresh behaviour, and error handling as they present on the merchant surface.
• Runnable source for the key endpoints in Python or Node.js — settlement pull, transaction listing, UTR-keyed reconciliation.
• Automated tests covering the UPI/card split and the payout-to-UTR match.
• Interface documentation plus data-retention and consent-logging guidance sized to the DPDP Act.

Consent and the RBI rulebook

Two regimes touch this work. The bank-side data flows under the RBI Account Aggregator framework, the consent-based sharing system that went into commercial operation in 2021: nothing moves without the merchant's explicit, scoped, revocable consent, and the aggregator itself is a data-blind pipe. The personal-data side sits under India's Digital Personal Data Protection Act, 2023, which requires a lawful purpose, consent that can be withdrawn, and audit trails. BharatPe's own listing notes that Location and Contacts permissions feed loan and credit-profile features — data a downstream integration should not carry unless it genuinely needs it. We run authorized, documented, or merchant-consented access only, log the consent records, minimize what is stored, and work under an NDA where a project calls for it.

Where this build gets specific

The reference a merchant sees at collection time is not the UTR that lands on the bank statement — a known mismatch in Indian settlement reconciliation. We build the recon logic to key on the UTR and carry the fee deductions as their own lines, so QR and BharatSwipe totals both reconcile against the banked amount instead of drifting.

UPI collections and BharatSwipe card records also arrive on different surfaces with different field sets. We normalize them into one takings schema at ingest, so a merchant reads a single number rather than two feeds that never quite agree.

The merchant surface is session and token driven. We design the sync around token refresh so the feed does not quietly stop, and schedule a front-end re-check into maintenance for when the dashboard layout moves. Access to a consenting merchant account is arranged with you as the project starts — it is part of the setup, not something you line up first.

How fresh the feed is

QR collections and on-demand settlements move through the day, so the interface feed polls intraday. The day-end auto settlement posts once. Loan EDI installments post daily. The downloadable reports are batch. We match the polling cadence to each surface rather than hammering one interval across all of them.

The merchant-payments neighbourhood

The same integration pattern extends across India's acceptance apps, which is why a merchant often wants more than one wired into a single ledger:

• Paytm for Business — QR and POS acceptance with a transaction and settlement dashboard.
• PhonePe Business — UPI acceptance, offline payments and merchant lending records.
• Razorpay — payment gateway plus in-store acceptance and payout data.
• Google Pay for Business — UPI collections keyed to a merchant profile.
• Mswipe — card POS terminals with settlement and MDR detail.
• Pine Labs — Android POS acceptance across card and UPI.
• Cashfree — collections, payouts and settlement reporting with developer APIs.
• PayU — gateway transactions and settlement detail for online merchants.
• MobiKwik for Business — wallet and UPI acceptance for small merchants.
• Ezetap — POS acceptance and settlement records across instruments.

Each holds a slightly different slice of the same merchant story; a unified integration keys them together on the settled amount and the UTR.

App screens

Sources and checks

Written after reviewing the app's Play Store listing (feature set, merchant count, loan APR range and permissions), a third-party reconciliation write-up describing BharatPe's settlement report and UTR-level export, the Government of India's Account Aggregator framework page, and BharatPe's own press note on its merchant investment product. Checked July 2026.

• BharatPe for Business — Google Play listing
• BharatPe Instore reconciliation and settlement report detail
• Account Aggregator framework — Dept. of Financial Services
• BharatPe launches investment platform for merchants

Mapped by the OpenBanking Studio integration desk · 2026-07-04.

Questions integrators ask about BharatPe

Can you separate UPI collections from BharatSwipe card takings in the feed?

Yes. UPI collections and BharatSwipe card records originate on different surfaces inside the merchant app, with different fields. We tag each record by instrument and by network so a report can split QR from card, or roll them into one takings line.

How do you reconcile a BharatPe payout against our bank statement?

The settlement report carries the UTR for each payout along with the fees deducted. We key the reconciliation on that UTR rather than the collection-time reference, and carry each deduction as its own line, so on-demand and day-end payouts match the bank statement without manual guessing.

Does the Account Aggregator route cover BharatPe's own transaction view?

No. An RBI Account Aggregator consent reaches the bank account side of the flow, such as statements for the account BharatPe settles into. The QR, BharatSwipe and settlement detail live inside the BharatPe merchant surface and come from the authorized interface integration.

How current is the data, and can we poll intraday settlements?

QR collections and on-demand settlements move through the day, so the interface feed can poll intraday; downloadable reports are batch. The integration itself is delivered in one to two weeks.

Source-code delivery starts at $300, billed only after we hand over the runnable integration and you are satisfied with it; alternatively the same endpoints run as a hosted, pay-per-call API with nothing paid upfront. Either way the build runs one to two weeks. Tell us which BharatPe surfaces you need and what you will do with the data — start the conversation here.