Reaching the clients, loans and payments inside Prestamistapp 3

A PrestamistApp 3 tenant is one lender's whole book — every borrower, every active loan, every installment that comes due — kept behind a single login at app3.prestamistapp.com and mirrored to its Android and iOS clients. Most people who land here already run that book and want a copy somewhere else: a warehouse, an accounting ledger, a risk dashboard, a CRM. The quickest path is a one-time bulk backfill of the portfolio, then an incremental pull that keeps the copy current. That shape of work is what this page describes, and the code that does it is what gets handed over.

Bottom line: the data you want is the lender's own, and the dependable way to reach it is the account they already control. We treat the platform's web traffic as the interface, capture the request shapes against a tenant you authorize, and ship a client that backfills the book and then syncs it. No open-banking mandate sits between you and these records — the authorization is the lender's. That is enough to build on.

What a lender's tenant actually holds

The feature set is detailed for a niche app. Quoting the module names as the vendor's own pages write them, here is where the data originates and what an integrator tends to do with each surface.

Routes onto the loan book

Reaching this data comes down to how the lender already touches it, and there are a few honest options.

Authorized interface integration (the one we'd build)

The web client at app3.prestamistapp.com talks to a backend with predictable request shapes. Working from a tenant the lender authorizes, we capture the auth handshake and the calls behind the cartera, the receipts and the schedules, then turn them into a stable client. Reachable: everything the operator role can see. Effort is moderate. Durability tracks the app's own client — when it ships a new build we re-validate the captured shapes. This is the route that gives you the full book and keeps it current.

User-consented credential access

This is really the auth layer of the route above: the lender's own login, used with their permission, to establish the session the sync runs on. Credentials and any NDA are arranged with you during onboarding, not demanded up front.

Native export

The app can export documents — receipts, promissory notes, statements. Useful as a fallback for a static snapshot or for archiving signed pagarés, but it is point-in-time and won't give you incremental sync. We treat it as a complement, not the spine.

For a live, queryable copy of a lender's portfolio, the interface route is the one worth building; export is there for the documents it produces best.

A backfill call, sketched

Field and path names below follow the app's own Spanish vocabulary (cartera, recibos, modalidad, saldo, cuota). Shapes are illustrative and get confirmed against a live tenant during the build.

# 1) Establish a tenant session with the operator's credentials
POST https://app3.prestamistapp.com/auth/session
  { "usuario": "<operator>", "clave": "<supplied by the lender>" }
  -> 200  Set-Cookie: pa_session=...

# 2) Bulk backfill: walk the active portfolio page by page
GET /api/cartera/prestamos?estado=activo&page=1&per_page=200
  Cookie: pa_session=...
  -> { "page": 1, "pages": 7,
       "prestamos": [
         { "prestamo_id": 48213, "cliente_id": 1190,
           "modalidad": "diario", "monto": 15000, "saldo": 8400,
           "cuota": 500, "proximo_pago": "2026-06-16" } ] }

# 3) Incremental: pull only receipts written since the last cursor
GET /api/recibos?desde=2026-06-13T00:00:00
  Cookie: pa_session=...
  -> [ { "recibo_id": 90412, "prestamo_id": 48213,
         "monto": 500, "fecha": "2026-06-13T14:02:11",
         "agente_id": 7 } ]

# Errors: 401 -> re-auth and resume from the saved page/cursor
#         429 -> back off, the paging loop is restartable
      

What lands in your repository

The headline deliverable is working code, not paperwork. Tied to the surfaces above, a build typically gives you:

• A runnable client in Python and Node.js that authenticates against the tenant and pages through the cartera — the backfill worker, plus an incremental sync keyed on a receipts cursor so a re-run continues from where it stopped.
• An automated test suite that runs the auth flow and a sample portfolio pull against the consenting tenant, so a change in the app's responses shows up as a failing assertion rather than a quiet gap in your data.
• Normalized models for borrower, loan, installment and payment, with each modalidad resolved to an explicit schedule.
• An OpenAPI description of the captured surface and a short auth-flow note (the session-cookie chain and refresh) — secondary material, for your own engineers.
• Interface documentation and data-retention guidance written against Law 172-13.

A normalized shape to map onto

Pulled rows are flattened into something portable, independent of the app's internal naming:

{
  "borrower":  { "id": "1190", "name": "...", "national_id": "<minimized>",
                 "custom_fields": { ... } },
  "loan":      { "id": "48213", "borrower_id": "1190",
                 "principal": 15000, "balance": 8400,
                 "cadence": "daily", "installment": 500,
                 "schedule": "fixed", "status": "active" },
  "payment":   { "id": "90412", "loan_id": "48213",
                 "amount": 500, "at": "2026-06-13T14:02:11Z",
                 "agent_id": "7", "source": "recibo" }
}
      

Authorization and the Dominican data rules

Access here rests on the lender's own authorization over a tenant they hold — they own the account and the book inside it. The records of their borrowers, though, are personal data, and the governing instrument is the Dominican Republic's Law No. 172-13 on the Protection of Personal Data (enacted 2013, GDPR-inspired, per the DLA Piper country summary). It grants borrowers access, rectification and deletion rights and, per that summary, ties penalties to multiples of the national minimum wage. The promissory-note module, the solicitud form and Mapa en Vivo all carry sensitive fields — national IDs, addresses, live geolocation — so we minimize what the feed pulls and keep consent and processing logged. Dominican regulators have an agreement with the World Bank to develop Open Finance APIs, but that is forward-looking; nothing in it is a usable route today, which is why the build leans on the account holder's authorization rather than a scheme that does not yet exist.

What we plan around on a build

A few app-specific details shape the work, and we handle each as part of the engagement.

• Modality and amortization variants. Loans run daily, weekly, biweekly or monthly with fixed or variable installments. We resolve every modalidad to an explicit schedule and reconcile the running saldo against it, so a balance read mid-cycle matches what the lender sees rather than drifting.
• Borrower-PII minimization. The pagaré notarial and the solicitud form hold national IDs and addresses, and Mapa en Vivo holds location points. We scope the pull to the fields you actually use and drop the rest at the edge, keeping the feed within Law 172-13's data-minimization expectation.
• Roles and visibility. Accesos means an agent sees only part of the book. We run the backfill against an operator role with full visibility and record which role produced each pull, so the copy is complete and auditable.

What the screens tell us

The published screenshots show the cartera, payment entry and reporting surfaces the integration reads. They are linked here as evidence of the modules named above; open any to enlarge.

How this read was put together

This was assembled on 2026-06-14 from the app's own Play listing and the vendor's feature pages, alongside the Dominican data-protection sources below. Module names are quoted from those feature pages; the endpoint shapes are illustrative until confirmed against a live tenant during a build. Where a detail is not public — exact user counts, the internal schema — it is left open rather than guessed.

• Prestamistapp 3 on Google Play — listing, developer, ratings
• prestamistapp.com — module and feature names, platform coverage
• DLA Piper — Data protection in the Dominican Republic — Law 172-13 scope and rights
• Tracxn company profile — DSegura App background

OpenFinance Lab · interface engineering notes, 2026-06-14.

Other prestamista tools in the same orbit

PrestamistApp 3 sits in a busy Latin-American niche. A group consolidating several lenders' books often touches more than one of these, which is why a single normalized feed is worth the build.

• Prestamista Manager (Cobros) — keeps loans, interest and collections entirely on-device with no external server, which makes it an export-only counterpart when a lender moves to a connected setup.
• Prestapp (Gestor de cobranza) — a field-collections tool with a portfolio module, holding loans and route data much like the cartera here.
• CrediManager — manages credits and credit sales with PayPal and Mercado Pago payment links, so its records include settled online collections.
• PrestaBIT — tracks clients, loans, collections and receipts for independent lenders.
• Kashin — a Peru-based, SBS-registered lender app pairing a wallet with socially-endorsed credit, holding wallet and loan ledgers.
• Prestamista (Melosoft) — a free loan-management app for small lenders with client and payment records.
• TurnKey Lender — an enterprise origination-and-servicing platform whose loan and decisioning data a larger group might unify alongside the smaller tools.
• LoanPro — a cloud loan-servicing core, often the warehouse side of a consolidation.

Questions integrators ask about PrestamistApp 3

Can you pull a whole loan book at once and then keep it fresh?

Yes. The first pass is a bulk backfill that walks the cartera page by page — borrowers, active loans and their schedules. After that, a cursor over the receipts and payment history pulls only what changed, so you can run it as a nightly batch or poll it through the day. You set the cadence; the client handles paging and resumes where it left off.

How do you deal with the daily, weekly, biweekly and monthly modalities?

Each loan carries its modalidad and either fixed or variable installments. We resolve every modalidad to an explicit schedule and reconcile the running balance against it, so a saldo read mid-cycle lines up with what the app shows the lender.

This is a Dominican app — where does the borrower data stand legally?

The borrower records sit under Dominican Republic Law 172-13 on personal data, which grants access, rectification and deletion rights much like GDPR. The lender authorizes access to their own tenant, and we minimize what the feed carries — national IDs, addresses on promissory notes and live-location points are pulled only when you actually need them.

Our portfolio is split across agents with different permissions — does that change anything?

The Accesos roles mean an agent sees only part of the book. We run the backfill against an operator role with full visibility and record which role produced each pull, so the copy is complete and you can trace where every row came from.

A typical PrestamistApp 3 build runs one to two weeks once we have a tenant to point at. Take it as source and you own the client outright — from $300, invoiced only after the code is delivered and you've confirmed it pulls what you expected. Prefer not to host it? Call our endpoints instead and pay per call, with nothing up front. Either way the starting point is the same: tell us the app and what you want out of its data on the contact page, and we arrange tenant access and any NDA with you from there.