Reaching Starpresta's loan and repayment records in Mexico

A Starpresta loan runs $500 to $30,000 MXN over 91 to 180 days, per its Play Store listing, and every one leaves a server-side trail behind it: the pre-approval offer, the disbursement to a Mexican bank account, an installment-by-installment repayment schedule with interest, a commission and 16% VAT, and the on-time or late status that the app says it forwards to the credit bureaus. That trail is the thing worth integrating. The borrower sees it inside an authenticated session; a lender, a collections partner, or an aggregator that wants the same numbers has to reach it through an authorized route.

Short version: the records exist and they are structured, but Mexico's regulated rail for sharing them does not run yet. So the working answer for Starpresta is to integrate against the borrower's own consented session and the traffic the app already generates, then normalize that into a clean schema you can query. The rest of this page sets out which records are reachable, how we get to them, and what ends up in your repository.

The records behind a Starpresta loan

Each row below is a surface the app actually exposes to a logged-in borrower or generates during onboarding. Granularity is what an integrator can expect to read per call.

How we get in

Three routes genuinely apply to Starpresta. They differ in what they return and how long they hold up.

1 · Borrower-consented interface integration

We work from a consenting borrower's authenticated session and the calls the app issues to its own backend, capture and document them, and rebuild the offer, disbursement, and repayment-schedule surfaces as a clean API. This returns the most — the live schedule with its VAT and commission lines, not just a contract snapshot. Effort is moderate. Durability tracks the app's front end, so a change there means a re-capture, which we cover in maintenance. Onboarding here is a step we run with you: a consenting test account and traffic capture are set up during the project.

2 · User-consented credential access for ongoing sync

For a feed that stays current, the borrower authorizes a session we drive on their behalf, scoped to the loan and repayment fields. Good for daily reconciliation. The consent record and its expiry are part of what we build around.

3 · Native contract and schedule export

Starpresta shows the borrower a loan contract and a payment plan. Where those are exportable, we parse them as a lower-fidelity cross-check — useful for reconciliation, weaker for real-time status because the document is a point-in-time copy.

A fourth path is worth naming for the future. Mexico's Fintech Law foresees standardized open-finance APIs for transactional data with the customer's consent; once the CNBV and Banxico issue those secondary rules, a regulated aggregator could pull this surface directly. That rail is not operational, so for Starpresta today the schedule comes back through route 1 against the borrower's session, with the native export kept as a reconciliation check and the credential-driven session reserved for clients who need a standing daily sync. That is the recommendation, and it is grounded in the regulatory state, not a preference.

A look at the repayment-schedule call

Illustrative shapes, confirmed against a consenting test account during the build. Field names are normalized in delivery; the figures mirror the worked example in the app's own listing.

# Auth: phone + one-time code -> short-lived session
POST /api/v1/auth/login
  { "phone": "+52...", "otp": "123456" }
  -> 200 { "access_token": "...", "expires_in": 3600 }

# Pull the amortization surface for one loan
GET /api/v1/loans/{loan_id}/schedule
  Authorization: Bearer <access_token>
  -> 200
  {
    "loan_id": "MX-...",
    "principal_mxn": 10000,
    "term_days": 120,
    "apr_band_pct": [188, 540],     # as the listing states it
    "installments": [
      { "n": 1, "due": "2026-07-15",
        "principal": 2500, "interest": 150,
        "commission": 150, "vat": 24,
        "total_mxn": 2824, "status": "due" }
      # ... remaining installments
    ]
  }

# Error handling worth wiring up
#   401  -> session expired: re-auth, do not retry blindly
#   423  -> account locked while KYC (INE/IFE + selfie) is pending
#   429  -> backoff; the schedule endpoint is read-cheap but rate-limited

The example loan in the listing resolves to a 2,824 MXN monthly payment over four payments; the snippet keeps that arithmetic intact so the per-installment lines sum to what the borrower is shown. We do not assert a single APR as fact — the listing gives a band, and the integration carries the band.

What lands in your repository

Deliverables are tied to the surfaces above, not a generic checklist.

• An OpenAPI / Swagger spec covering the offer, disbursement, schedule, KYC-status, and bureau-event endpoints as we normalize them.
• A protocol and auth-flow report: the OTP login, the bearer-token lifetime, refresh behaviour, and the cookie or header chain the session depends on.
• Runnable source for the key endpoints in Python and Node.js, including the schedule pull and a reconciliation helper that re-derives totals from principal, interest, commission and VAT.
• Automated tests against recorded fixtures, including the KYC-pending and session-expired paths.
• Interface documentation an engineer on your side can pick up without us.
• Compliance and data-retention guidance scoped to the loan and identity fields under Mexican law.

Consent and Mexico's data regime

Two frameworks bear on this app, and they sit in different states. Personal data is governed by the new Federal Law on the Protection of Personal Data Held by Private Parties (LFPDPPP), which took effect on 21 March 2025 and repealed the 2010 statute, per legal analyses of the reform. It keeps the ARCO rights — access, rectification, cancellation, opposition — and tightens consent and transparency duties; oversight moved away from the now-dissolved INAI to a federal anti-corruption authority. Starpresta's selfie and INE/IFE fields are sensitive data under that law, so consent is explicit and scoped, and we minimize what is read.

The sharing rail is the unsettled piece. The 2018 Fintech Law mandates standardized APIs for open, aggregated and transactional data, with the CNBV and Banxico to issue the API standards. As of this writing only open-data rules (covering ATMs) have been published; the transactional-data secondary rules remain unissued years on, and the delay has drawn an amparo naming the CNBV, Banxico and SHCP filed in December 2025. So the dependable legal basis for reaching a borrower's loan data is that borrower's own authorization, not a live regulated rail. We operate on consented, logged access, keep consent records, work under NDA where you need one, and retain only the fields the integration actually uses.

Engineering details we plan around

These are things we account for in the build, handled on our side.

• We reproduce the app's cost waterfall rather than recompute it — principal, the daily-interest band, a commission the listing puts at roughly 5% to 20%, and 16% VAT — so the integration returns the exact totals and installment figures the borrower sees. The listing's own worked example is internally rounded, and we match it rather than substitute our own arithmetic.
• We design the sync around the consent-session lifetime so a token expiry does not quietly stall the repayment feed; a re-auth path and an alert on consent expiry are built in from the start.
• We model the INE/IFE and selfie verification states as separate from loan state, because a loan record can exist while KYC is still pending, and treat the biometric fields as sensitive data that can be dropped entirely when a client only wants the ledger.
• When the onboarding or schedule front end changes, we re-capture and re-validate the affected calls as part of maintenance, so a UI update on Starpresta's side does not become a silent data gap on yours.

Keeping the integration current

Repayment data moves daily, so the schedule pull is built to be idempotent — re-reading a loan returns the same normalized rows whether a payment landed early, late, or partially. Bureau-reporting events lag the actual payment, so we mark them with the app's own event time, not the read time. Where the app rate-limits, the client backs off rather than hammering. Freshness is a setting you choose: a daily reconcile for collections, or an on-demand read when a borrower opens a case.

What the app screens show

The store screenshots below informed the surface map above. Open any one to inspect it.

What we checked, and when

Reviewed in June 2026. The surface map comes from Starpresta's own Play Store listing and screenshots; the regulatory picture comes from current coverage of Mexico's Fintech Law open-finance rules and the 2025 LFPDPPP reform. Primary sources we opened:

• Starpresta: Crédito Seguro — Google Play listing
• Holland & Knight — Open Banking Has Arrived in Mexico (Fintech Law APIs)
• FinTech Futures — CNBV facing legal action over open-finance rule delays
• Greenberg Traurig — Mexico's new personal data protection law (2025)

Mapped by the OpenBanking Studio integration desk · June 2026.

Other Mexican lending apps in the same picture

A client unifying loan data across providers usually has more than one of these in scope. Neutral notes, no ranking.

• Kueski — short-term consumer loans and a buy-now-pay-later product; holds repayment schedules and on-time history similar in shape to Starpresta.
• DiDi Préstamos — credit offered through the DiDi platform; loan balances and installment data tied to a rider/driver account.
• Kubo Financiero — a regulated lending and savings platform with larger loan amounts and longer terms, so its ledger carries more installments.
• Yotepresto — peer-to-peer lending; both borrower repayment records and investor positions live behind the account.
• Credilikeme — small-ticket credit with a points and referral layer over the loan record.
• Prestadero — one of the older P2P lenders, with loan, payment and bureau-reporting data per borrower.
• Crédito365 — short-cycle microloans comparable to Starpresta's 91–180 day terms.
• Kimbi — app-based microcredit holding disbursement and repayment status per user.
• Tala — alphanumeric credit scoring with loan and repayment records behind a phone-based account.
• Vivus — short-term cash loans with a fixed repayment schedule per loan.

Questions integrators ask about Starpresta

Does the repayment schedule expose the VAT and commission lines, or only a total?

Both. The amortization surface carries each installment's principal, interest, the roughly 5% to 20% commission and the 16% VAT as the app itself computes them, alongside the due date and paid or unpaid status, so the integration returns the same figures a borrower sees rather than a recomputed estimate.

Mexico's open-finance transactional APIs are not operational yet. Does that stop the work?

No. The dependable basis today is the borrower's own authorization, so we build against a consenting session and the calls the app makes to its own backend. We structure it so the same normalized loan and repayment schema could later sit on a regulated open-finance rail if the CNBV and Banxico publish the transactional rules.

How is the INE/IFE and selfie verification data handled?

As sensitive personal data under Mexico's 2025 LFPDPPP. Access is consent-bound, the fields are minimized and logged, and we work under NDA. If you only need the loan ledger we exclude the biometric and identity-document fields from the feed entirely.

Can we begin with just the repayment-schedule endpoint and add KYC status later?

Yes. Each surface is scoped on its own, so a first delivery can cover only disbursement and the repayment schedule, with identity and bureau-reporting events added in a later pass. The app name and the fields you want are enough to begin; access to a consenting account is arranged with you.

Getting started

Source delivery starts at $300, billed only after the code is in your hands and the endpoints return what we promised; or skip the build and call our hosted Starpresta endpoints instead, paying per call with nothing upfront. Either way the cycle is one to two weeks. Tell us the app and which fields you need at our contact page and we will scope it back to you.