Reaching the purchase line, biweekly cuotas and lock state held inside Krece

A Krece account is a small consumer-credit file. It tracks a borrower's purchase line, the cuotas owed on a financed phone, every payment they have reported, the loyalty level they have climbed to, and whether the handset is currently switched on or remotely disabled. According to its Google Play listing, the app runs under package com.application.krece on Android, with an iOS build alongside it. The data sits behind an authenticated session, not a download. So the question for anyone wanting to sync or reconcile against it is simply which authorized route reaches that session most cleanly.

For Krece the cleanest answer is the consented session itself: instrument the calls the app already makes, run them against an account the borrower or store partner controls, and normalize the five surfaces below. Everything a borrower sees passes through that client, so nothing has to be inferred.

What an account actually holds

These are the surfaces the app exposes to its own users, named the way Krece names them. Each maps to something an integrator would reconcile, sync or act on.

Authorized ways in

Three routes fit this app. Onboarding and access are arranged with you as the first step of the build, against a consenting account or a store-partner login.

Protocol analysis of the app's traffic

We run the Krece client through an instrumented build and document the calls it makes for line, cuotas, reports and lock state. Reachable: every surface in the table, exactly as the borrower's own app sees them. Effort is moderate and front-loaded. Durability tracks the app version, so an update can shift a field or an endpoint. This is the route we'd recommend for Krece, because the borrower-facing client already carries all five domains and nothing useful lives outside it.

User-consented credential access

With the account holder's consent, the integration operates as that user: it authenticates, reads the line and schedule, and submits or polls payment reports on their behalf. Stable as long as the login flow holds. Good fit where a store partner manages many borrowers and wants programmatic visibility per account.

Reconstructed records

Krece centers on reporting payments into the app rather than handing borrowers a file of their history. Where someone needs their own statement, we rebuild the ledger from the authorized session, normalize it, and hand it back as structured data instead of screen-scraping by hand.

How the calls look

Illustrative shapes, the kind we confirm and pin down during the build. Auth on a mobile client like this is a bearer token issued at login and refreshed; field names get verified against the live traffic.

POST /v1/auth/login
{ "phone": "+58…", "pin": "******" }
-> 200 { "access_token": "ey…", "refresh_token": "…", "expires_in": 3600 }

GET /v1/account/credit-line          Authorization: Bearer ey…
-> 200 {
     "limit_usd": 220.00,
     "available_usd": 60.00,
     "level": "GOLD",
     "points": 140
   }

GET /v1/financings/active            Authorization: Bearer ey…
-> 200 {
     "device": "Xiaomi Redmi 13C",
     "initial_pct": 30,
     "installments": [
       { "n": 1, "due": "2026-06-12", "amount_usd": 31.66, "status": "PAID" },
       { "n": 2, "due": "2026-06-26", "amount_usd": 31.66, "status": "PENDING" }
     ],
     "device_lock": "ACTIVE"
   }

POST /v1/payments/report             Authorization: Bearer ey…
{ "installment": 2, "method": "PAGO_MOVIL", "reference": "0102…", "amount_usd": 31.66 }
-> 202 { "report_id": "rp_8841", "status": "PENDING_REVIEW" }
# confirmation is asynchronous; poll GET /v1/payments/report/rp_8841 until CONFIRMED

The 202-then-poll pattern matters here: the borrower reports a payment, Krece reconciles it against the actual bank movement, and only then flips it to confirmed. An integration that treats the report as settled would over-count.

What you get back

The output is a working integration for the surfaces above, not a report about one. Concretely, for Krece:

• An OpenAPI spec covering the credit-line, financing, payment-report and lock-state endpoints, with the real request and response fields.
• A protocol and auth-flow write-up: how the token is issued, refreshed and carried, and how the report-then-confirm cycle behaves.
• Runnable client source in Python and Node.js for those calls, including the submit-and-poll loop for payments.
• Automated tests around the cases that bite: a pending report that is not yet confirmed, an arrears state, a disabled handset.
• Interface docs plus data-retention guidance written against Venezuelan habeas data principles.

Consent and the data rules that apply

Venezuela has no single data-protection statute the way the EU or Brazil do. The working basis is constitutional: the habeas data right in Article 28, the privacy guarantee in Article 60, and the handling principles the Supreme Tribunal articulated from them, per the DLA Piper country guide. Those principles are practical for us: consent must come before collection and stay revocable, collection needs a stated purpose, and it must not be excessive. Venezuela also published fintech-service regulations in its Official Gazette in 2021, per the same guide. So our footing is the account holder's own authorization, recorded with consent and access logs, with data kept to what the integration needs and an NDA where the engagement calls for one.

What we account for in the build

Two things about Krece shape the engineering, and we handle both rather than hand them back as caveats.

• The device lock is a real surface, not a flag. A late cuota can leave a borrower with a switched-off phone while their ledger still reads "pending". We model the lock and reactivation signal from the pre-installed security component so a collections integration knows the difference between overdue and disabled.
• Level rules change the math. Deposit rate and line headroom differ by tier — roughly 40% at Blue versus 30% at Gold or Platinum, as the app describes its levels. We encode the per-level rules so eligibility and schedule calculations stay correct as a borrower moves up, and time the sync to the biweekly cuota cycle so a payment reported a little late is reconciled against the right installment.
• Reports settle asynchronously. Because confirmation lags submission, we build idempotency into the poll loop so a single Pago Móvil reference can't be booked twice. When Krece ships an app update, re-checking the captured calls is part of the upkeep we do.

Screens we worked from

How this was checked

Written from the app's own listing and help pages plus Venezuelan press coverage, cross-read in May 2026. The credit model, level structure and device-lock behaviour come from Krece's FAQ and the eldiario explainer; the data-protection footing from the DLA Piper country guide; the market position from Venezuelan reporting. Sources opened:

• Krece on Google Play (com.application.krece)
• Krece — Preguntas Frecuentes
• eldiario: cómo funciona Krece
• DLA Piper — Data protection laws in Venezuela

Reviewed for OpenBanking Studio by the integration desk, May 2026.

Apps in the same corner of the market

Venezuela's installment-credit space has grown fast around Cashea, and several apps now hold comparable per-user ledgers worth unifying behind one interface.

• Cashea — the category leader; holds purchase lines and interest-free installment schedules across a wide retail network.
• CrediTotal — the most-cited Krece alternative; carries credit lines and installment plans for retail purchases.
• Rapikom — store-partnered installment financing with per-user payment schedules.
• Popclik — BNPL credit with account-level balances and repayment tracking.
• Lysto — consumer installment credit holding line and cuota records.
• Chollo — phone and electronics financing with per-account payment plans.
• Tu Zona Naranja — retail installment program with borrower ledgers similar in shape to Krece's.

Questions integrators ask

Can an integration tell when Krece has disabled a borrower's phone for non-payment?

Yes. The handset ships with a pre-installed security component that lets Krece disable it when an installment is missed. We map that lock/active signal as its own surface, so a collections or asset-tracking integration reflects a phone that is currently disabled, not just an overdue line in the ledger.

Does Krece confirm payments on its own, or do borrowers report them?

Borrowers pay through Pago Móvil, bank transfer or cash and then submit the transaction reference inside the app; Krece reconciles and confirms it afterward. An integration has to model that asynchronously, so we build the submit-then-poll loop with idempotency so a still-pending report is never counted as paid twice.

Which data rules cover a Krece integration in Venezuela?

Venezuela has no single data-protection statute. The basis is the constitutional habeas data right (Articles 28 and 60) plus principles the Supreme Tribunal set out: consent given before collection and revocable, a stated purpose, and no excessive collection. We work from the account holder's authorization and keep consent and access logs accordingly.

How fresh is the purchase line and cuota data we would receive?

As current as the app itself shows, because the integration reads the same calls the Krece client makes. Line increases follow level changes, and cuotas run on a biweekly cycle, so we time syncs around that cadence rather than polling blindly.

Turnaround on the Krece endpoints is about one to two weeks. You can take it as source you own outright, from $300, billed only after delivery once it works for you; or skip the build and call our hosted version of these endpoints, paying per call with nothing upfront. Either way you give us the app name and what you need from its data, and we arrange access and compliance with you — start that at /contact.html.