Itaú Pagos keeps every QR, contactless and bill payment a Uruguayan customer makes — here is the authorized way to read it

Every bill a person settles through Itaú Pagos lands in a receipt history they can filter by date and payment type, and that ledger sits next to the QR and contactless flows that produced it. That history — not the card sitting on file — is what an integrator usually needs. The app belongs to Banco Itaú Uruguay and runs on top of the customer's Itaú relationship, so the records behind it are real per-user financial events: utility and service invoices paid by barcode, QR purchases at affiliated stores, contactless POS charges, and mobile recharges, each with an amount, a channel and a stored receipt.

The bottom line: the valuable surface here is the payment ledger, reached today through authorized interface integration of the app's own traffic. If it were our call, we would build that route first and treat the BCU's Finanzas Abiertas scheme as the migration target once it is actually in force, because the roadmap is public but not yet a live mandate.

What sits behind the Itaú Pagos login

Access requires being an Itaú Uruguay customer with a Visa card; the app authenticates on document type, document number and password, as the Itaú Pagos institutional page describes. From there the structured records break down like this.

Getting to that ledger: the routes that apply

Authorized interface integration / protocol analysis

This is the route that works today. We document the app's login, the iToken step-up and the calls that return the receipt list, then implement a client that reads those records under the account holder's authorization. Reachable: the full payment history, invoice/service records, QR and contactless charges, card references. Effort: moderate — the auth chain is the real work, the listing endpoints are straightforward once mapped. Durability: good, with the proviso that app releases reshape payloads periodically. Access is arranged with you during onboarding, against a consenting account.

User-consented credential access

A thinner variant of the same idea where the end user explicitly consents and the integration runs in their session. Reachable surface is identical; durability is the same. We set up the consent capture and the session handling so the user authorizes once and the sync continues without storing raw credentials longer than the flow needs.

BCU Finanzas Abiertas (forward path)

Uruguay's Open Finance scheme is on a published roadmap, payments and transfers first. It is not yet a live consent-API regime, so it is not the route we ship now — but we shape the data model so the same integration moves onto it when the BCU mandate is in force. Native receipt export from the app is not a documented feature, so we do not lean on it.

A look at the receipt call

Illustrative shape only — field names are confirmed during the build against real responses, not copied from a published spec. It shows the auth chain this app actually uses and the receipt query an integrator cares about.

POST /pagos/auth/login
  body: { docType: "CI", docNumber: "<id>", password: "<secret>" }
  -> 200 { sessionToken, requiresStepUp: true }

# iToken second factor — device-bound, one phone + one document
POST /pagos/auth/itoken
  body: { sessionToken, otp: "<6-digit from the Itaú app>" }
  -> 200 { accessToken, expiresIn: 600 }

GET /pagos/receipts?from=2026-01-01&to=2026-04-30&type=invoice
  headers: { Authorization: "Bearer <accessToken>" }
  -> 200 {
       items: [
         { id, paidAt, channel: "QR"|"NFC"|"barcode",
           merchant, billerCode, amount, currency: "UYU",
           cardLast4, receiptUrl }
       ],
       nextCursor
     }

# 401 -> access token expired (~10 min); re-run the login + iToken pair.
# Page with nextCursor; do not assume a fixed page size across releases.
      

The package you receive

Everything is built around the surfaces above, not a generic template.

• An OpenAPI/Swagger specification covering the login, iToken step-up and the receipt/invoice listing calls.
• A protocol and auth-flow report: the document-number login, the device-bound iToken token, session lifetime and refresh behaviour.
• Runnable source for the key endpoints in Python and Node.js — authenticate, page the receipt history, pull invoice and QR/contactless records.
• Automated tests against recorded responses, including the channel split and the date/type filters.
• Interface documentation an engineer can hand to a teammate.
• Compliance and data-retention guidance written for Uruguay's Ley 18.331 and the BCU's Open Finance direction.

Consent and Uruguayan law

Itaú Pagos is a Uruguayan banking app, so two things govern this work. First, payment-data sharing: the Banco Central del Uruguay presented its Finanzas Abiertas (Open Finance) roadmap publicly on 1 October 2024, with a draft bill routed to the Ministry of Economy and a horizon around 2030, payments and transfers as the opening phase. Because that regime is still being legislated rather than operating, we do not assert its eventual obligations as settled rules; today's integration runs on the account holder's documented authorization, with consent records and access logs kept. Second, personal data: Uruguay's Ley N° 18.331 on personal-data protection, overseen by the URCDP, governs how the extracted records may be processed and transferred — financial transfers are a recognized basis but database registration and the data subject's rights still apply. We operate authorized, logged and data-minimized, under NDA where the engagement needs one.

Things we account for on this build

• iToken is device-bound — Itaú's own documentation states it enables on one cell phone with one document and validates operations. We design the session handling around that step-up so the integration's token lifecycle matches what the app actually enforces, rather than assuming a plain password session.
• The contactless path is Android-only as the listing describes it, so iOS accounts never produce NFC events. We tag channel by device and keep the data model identical across platforms so reconciliation logic does not silently assume iOS parity.
• App releases periodically reshape the receipt list's payload. We keep a small fixture set captured from real responses and refresh the mappers when a release shifts field names or pagination, so a store update does not quietly break the sync.
• Amounts are UYU and some flows touch benefit/food cards with their own rules; we normalize currency and card type up front so a benefit-card receipt is not misclassified as ordinary spend.

Where teams put this to work

• A merchant reconciling QR settlements against the payer-side receipt ledger to close gaps between acquirer reports and what customers actually paid.
• A personal-finance app in Uruguay ingesting a consenting user's categorized invoice and service payments to show monthly utility spend.
• An accounting tool pulling stored receipts for service and utility invoices so businesses do not re-key them from paper.
• A treasury view tracking recurring service payments and their due-date notifications across a household or small company.

Interface evidence

The store screenshots of the live app, for the surfaces named above. Click to enlarge.

Sources and how this was checked

Checked in May 2026 against the app's Play Store listing, Itaú Uruguay's own institutional pages for Itaú Pagos and iToken, and the Banco Central del Uruguay communication on the Finanzas Abiertas roadmap, plus the text of Ley 18.331. Citations:

• Itaú Pagos Uruguay — Google Play listing
• Itaú Uruguay — Itaú Pagos features
• BCU — Hoja de Ruta de Finanzas Abiertas
• Ley N° 18.331 — Protección de Datos Personales

Field notes from the OpenBanking Studio integration desk, reviewed 2026-05-16.

The Uruguayan payments neighbourhood

Same-category Uruguayan apps an integrator often unifies alongside Itaú Pagos. Plain ecosystem context, no ranking.

• Prex Uruguay — prepaid account and international card with QR and Pix payments; holds balances and transaction history.
• Midinero — virtual wallet that can link a BROU account and pay or receive by QR; holds wallet movements.
• BROU (Banco República) app — the state bank's accounts, transfers and electronic-wallet records.
• Itaú UY — Itaú Uruguay's main banking app with accounts, transfers and the iToken validation shared with Itaú Pagos.
• OCA — card issuer's digital wallet around the OCA Mastercard, holding card movements.
• RedPagos (Miredpagos) — bill payment, transfers and recharges across a wide collection network.
• Anda — cooperative card and wallet with member transaction records.
• Toke — QR wallet that pays straight from a bank or e-money account; holds payment history.
• Plexo — payment platform behind many Uruguayan merchant flows; transaction-level data.

Questions integrators ask about this app

Can you reach the bill and service payments a user made, not just the card sitting on file?

Yes. The receipt history is the richer surface — each paid invoice, QR purchase and contactless charge with its date, channel, biller or merchant, amount and stored receipt. The digitized Visa card list is reachable too, but the payment ledger is what most integrations are after.

Does Uruguay's Open Finance program change how you would build this today?

Not yet in practice. The BCU presented its Finanzas Abiertas roadmap publicly on 1 October 2024 with a bill routed to the Ministry of Economy and a 2030 horizon, so a consent-API mandate is not live. We build the authorized interface-integration route now and design it so the same data model migrates onto the BCU scheme once it is in force.

Contactless behaves differently on iPhone — does that affect the integration?

It affects reconciliation, not the data shape. The app's NFC contactless path is Android-only as the listing describes it, so iOS users will not generate contactless events. We model the events the same on both platforms and flag channel by device so downstream logic does not assume iOS parity.

We already run an Itaú Pagos business relationship in Uruguay — does that shorten anything?

It can. A consenting account and your authorization let the build run against real responses sooner; we arrange that access with you during onboarding rather than asking you to clear it first. Tell us the app and what you want from its data at /contact.html.

Source delivery starts at USD 300, billed only after you have checked the working code and are satisfied; the alternative is our hosted endpoints, where you pay per call with nothing upfront. Either way the build runs in one to two weeks. Tell us the target app and what you need from its data and we will take it from there — start at /contact.html.