Account, card, loan and Tpago data inside Mercantil Móvil Personas

Since early February 2025, when Mercantil folded the Tpago service into this app, one personal login reaches both the ordinary bank ledger and the country's instant-payment rails at the same time. That is what makes it worth integrating, and also what makes it more than a balance read. A single authenticated session covers account and card movements, loan positions, transfers across national banks, mobile top-ups, foreign-currency trading, and the full Tpago payment surface including C2P codes. The Tpago consolidation date is reported by Venezuelan trade press; the feature list comes from the app's own Play Store description.

This brief maps what a third party can read or drive from that login, names the authorized route to it, and says plainly what we hand over. The publisher is Mercantil, C.A., Banco Universal, and the package is com.mercantilbanco.mercantilmovil per its Google Play listing, with Android 9 or higher required.

The honest bottom line: this is a rich authenticated portal, and the cleanest way in is consented protocol analysis of the app's own traffic against an account the holder controls. An AIS-style consent layer fits where a participant can grant it, and the app's own share and copy-reference features cover one-off exports. Most projects ride on the first.

What one Mercantil login actually exposes

Each row below is a surface the app names itself. Granularity reflects how the data is presented to the account holder, which is the level an integrator gets to work with.

Where it gets used

Three patterns come up most often when someone asks to reach this app's data.

• A merchant platform that already collects via Tpago C2P wants a programmatic way to request a payment code, watch for the confirmation, and write the reference back into its own ledger — without a human reading a screenshot.
• An accounting or treasury tool serving Venezuelan SMEs needs a nightly movements pull across the customer's Mercantil accounts and cards, normalised so bolívar and foreign-currency lines reconcile.
• A wallet or remittance product wants to drive interbank transfers and mobile top-ups through one consented session instead of asking users to leave the flow.

Authorized routes into the account data

Consented protocol analysis of the app session

We study the app's own authenticated traffic against an account the holder consents to, document the login, token and request chain, and build a client that speaks the same protocol. This reaches everything the surfaces table lists, because it is the same path the app uses. Effort is moderate; durability depends on app releases, which we account for in maintenance. We arrange the test account and authorization with you during onboarding.

AIS-style consent layer

Where a participant can grant account-information consent, we wrap the read in a consent flow with scope and expiry. This is the tidiest basis for ongoing statement access and the easiest to audit. Coverage is read-centric — balances and movements — rather than driving payments.

Native share and copy-reference export

The app already lets a user share a transaction result and copy the last four, six or all digits of a reference. For low-volume or one-off needs this is a legitimate, zero-integration fallback we can script around. It does not scale to continuous sync.

For most of the work described here, consented protocol analysis is the route we would actually take. It is the only one that reaches both the ledger and the live Tpago and C2P actions a merchant or treasury integration needs. We add the AIS consent layer when a participant grant is available and the job is read-only statements, and we script the native share-and-copy export only when the need is genuinely one-off.

What lands in your repo

Every engagement ends with code you can run, not a report about feasibility. For this app that means:

• An OpenAPI 3 specification covering the movements read, transfer instruction, and the Tpago payment and C2P endpoints, with the bolívar / foreign-currency split modelled in the schema.
• A protocol and auth-flow report: how login, biometric 2FA, the session token and any cookie chain fit together, with the C2P key lifecycle documented as a short-lived token.
• Runnable source for the key endpoints in Python and Node.js — a movements client, a transfer call, and a Tpago/C2P client.
• Automated tests against recorded fixtures so the suite runs without hitting a live account, plus a smoke path for a consenting account.
• Interface documentation and compliance notes: consent capture, access logging, data-minimisation defaults, and a retention stance suited to banking-secrecy expectations.

A pull, sketched

Illustrative only; exact field names and the token chain are confirmed during the build against a consenting account.

# 1. Authenticate — credential + biometric 2FA assertion -> session token
session = mercantil.login(
    user=USER, secret=SECRET,
    factor="biometric_2fa")          # second factor on login and key actions

# 2. Movements for one account (bolívar + FX accounts kept distinct)
movs = session.get_movements(
    account=ACCT_ID,
    since="2026-05-01")
# -> [{date, amount, currency, reference, counterparty, type}, ...]

# 3. Tpago C2P — request a single-use code, then confirm
c2p = session.tpago.request_c2p(
    payer_id=PAYER_RIF,
    amount=AMOUNT_BS)
# code is single-use, ~6h validity per bank docs -> never cached past expiry
assert c2p.expires_in <= 6 * 3600

try:
    result = session.tpago.confirm(c2p.code, AMOUNT_BS)
except StaleCodeError:
    c2p = session.tpago.request_c2p(payer_id=PAYER_RIF, amount=AMOUNT_BS)
    result = session.tpago.confirm(c2p.code, AMOUNT_BS)

write_ledger(result.reference)        # last-4/6/full reference, as the app exposes it

SUDEBAN, banking secrecy and consent

Venezuelan banks answer to SUDEBAN, and Pago Móvil clearing sits under the Banco Central de Venezuela. There is no omnibus data-protection statute here; instead, banking secrecy and SUDEBAN's user-protection norms (Resolution 063.15, as cited in legal commentary) place the duty to safeguard customer data on the institution. SUDEBAN's 2021 fintech rules (Resolution 001.21) define how technology providers connect to banks, which frames any participant-side consent layer. Because there is no statutory data-subject regime to lean on, the dependable basis for reaching a customer's data is that customer's own documented authorization. We capture and store that consent with scope and revocation, log every access, minimise what we read to the surfaces in the brief, and work under an NDA where the engagement calls for one.

Build details this app forces

Two specifics shape the work and we handle both rather than hand them back as conditions.

• Currency duality. Accounts run in bolívares and in foreign currency, and the app pays bolívares from a foreign-currency account through automatic exchange. We model currency on every amount and keep the FX rate with the record, so a sync does not silently flatten two currencies into one total.
• The C2P code is ephemeral. A C2P authorization key is single-use with roughly a six-hour life per the Venezuelan bank documentation. We design the client to request it on demand, track its expiry, and treat cancellation as a normal call, so codes are never replayed or cached past their window.
• Moving front end. Mercantil consolidated Tpago into this app in early 2025 and ships releases regularly. We pin the integration to the surfaces confirmed during the build and run a re-validation pass in maintenance, so a release that renames a field is caught instead of returning quietly wrong data.

Access to a sandbox or a consenting account is arranged with you during onboarding; it is part of how we run the project, not something to clear before we begin.

Screens we mapped

Store screenshots used while tracing the surfaces above. Tap to enlarge.

What we checked, and where

The surface list was read from the app's own store description; the Tpago consolidation and the current feature set were cross-checked against Venezuelan trade press; the regulatory picture comes from legal commentary on SUDEBAN's rules. Reviewed 15 June 2026 by the OpenBanking Studio integration desk.

• Mercantil Móvil Personas on Google Play — publisher, package, feature list, Android 9+ requirement.
• Banca y Negocios — Tpago consolidated into the app, February 2025.
• Holland & Knight — SUDEBAN Resolution 001.21 fintech framework.
• Banco del Tesoro — how C2P commerce-to-person codes work.

Similar apps in the Venezuelan payments space

Named for context and keyword reach; a unified integration usually spans several of these. No ranking is implied.

• BDV (Banco de Venezuela) — the state bank's app, with PagomóvilBDV and broad account and card movements behind a login.
• Banesco Móvil — private-bank balances, transfers and pago móvil for one of the largest customer bases in the country.
• BBVA Provincial (Provinet Móvil / Dinero Rápido) — accounts, cards and instant mobile transfers from a major commercial bank.
• Bancamiga Suite — accounts, cards and pago móvil with a strong merchant-collections focus.
• Ubii Pagos — a payments app centred on QR and C2P merchant collections rather than full retail banking.
• Banco del Tesoro — public-bank accounts plus the Tesoro Comercio Móvil C2P service for merchants.
• Bancaribe — commercial-bank accounts with pago móvil a comercio for business collection.
• Cashea — a buy-now-pay-later app holding instalment plans and repayment schedules rather than deposit accounts.

Questions integrators ask about Mercantil

Is the Tpago C2P flow a separate integration from the account-movements pull?

They are two different surfaces behind one login. The movements pull reads balances and transaction history per account, card and loan; the Tpago side speaks to the mobile-payment network for sending payments, requesting and cancelling C2P codes, and managing contacts. We model them as separate clients sharing one authenticated session, because their request shapes and their freshness expectations differ.

How do you handle the six-hour C2P code window in a synced client?

A C2P authorization key is single-use and expires after about six hours, as the Venezuelan bank documentation describes it. We treat the code as a short-lived token: the client requests it on demand, stamps its issue time, and never caches it past expiry, so a stale code is re-requested rather than replayed. Cancellation is wired in as a first-class call, not an afterthought.

Which regulator and consent basis applies to reaching a Mercantil customer's data in Venezuela?

Banks are supervised by SUDEBAN, and Pago Móvil clearing runs under the Banco Central de Venezuela. Venezuela has no general data-protection statute, so the dependable basis is the account holder's own documented authorization, against the backdrop of banking secrecy and SUDEBAN's user-protection norms. We build to that consent and keep consent records and access logs.

Can the foreign-currency buy and sell and the automatic-exchange data be read as well?

Yes. The app exposes electronic purchase and sale of foreign currency, a foreign-currency account, and payment in bolívars through automatic exchange linked to Tpago. Those rates, the currency-account balance and the exchange records are mapped as their own domain, because amounts straddle two currencies and a sync that ignores that mismatches totals.

If Mercantil ships a new app release, does the integration break?

A front-end refresh can shift field names or the request chain. We pin the integration to the surfaces we confirmed during the build and add a re-validation pass to maintenance, so a new release is caught and patched rather than silently returning wrong data. Mercantil folded Tpago into this app in early 2025, so the surface does move.

Putting a movements pull, a Tpago/C2P client and an OpenAPI spec in your hands runs to one or two weeks for this kind of surface. You bring the app name and what you want from its data; we handle the access, the protocol work and the consent setup with you. Take the source-code delivery from $300 and settle only once the code is in your hands and you are satisfied, or skip any upfront cost and call our hosted endpoints, paying per call as you use them. Tell us which fits at /contact.html and we will scope it.