Integrating Tarjeta amiga, a bi-weekly credit card from Mexico

What the card app stores, screen by screen

Each row below is a surface a cardholder sees in the app, named the way Tarjeta amiga names it, with where it comes from and what an integrator does with it.

Authorized ways into the data

Two routes genuinely apply to Tarjeta amiga, and a third is a fallback for documents.

Consented interface integration of the cardholder session

A cardholder registers with their cell number, the 16 digits of the card, and a password they set. With that cardholder's authorization, we drive the same session the app uses and read every surface it renders — balance, movimientos, próximos pagos, the wallet, policies. Effort is moderate and the read is wide. Durability tracks the app's releases, so we keep a small re-validation step that flags a changed field before it reaches your data. This is the route we recommend as the backbone of the build.

Regulated Open Finance under the Ley Fintech

Mexico's Fintech Law set up standardized financial-data sharing with express consent. For transactional data it is forward-looking, not operational, and Tarjeta amiga's issuer is a commercial non-bank entity outside the banks the current pilots cover. We treat this as where the rule may go and shape the consent model so it can migrate, rather than as something you can call today.

Consented document export

The app lets a cardholder download current insurance policies and view statements. For those document-shaped domains a consented export pull is a stable, low-churn fallback that complements the session read.

A movements pull, in code

Tarjeta amiga surfaces movements to its own screens, so we ingest by polling and keep a cursor — the id of the last row stored — so each run fetches only what is new. The sketch below is illustrative, modelled on the movimientos and próximos-pagos screens rather than copied from a published spec; field names are placeholders for the real Spanish keys mapped during the build.

# Consented Tarjeta amiga session -> normalized movement feed (illustrative)
import httpx

def poll_movimientos(session, cursor=None):
    # cursor = id of the last movement we ingested; the server returns only
    # rows after it, so a re-poll never re-reads the whole ledger.
    params = {"limite": 100}
    if cursor:
        params["desde_id"] = cursor
    r = session.get("/cartera/movimientos", params=params, timeout=20)
    r.raise_for_status()
    body = r.json()
    # body["movimientos"][i] -> id, fecha, concepto, monto, tipo, saldo_despues
    rows = [normalize(m) for m in body["movimientos"]]
    return rows, body.get("ultimo_id", cursor)

def normalize(m):
    return {
        "id":        m["id"],
        "posted_at": m["fecha"],          # America/Mexico_City, preserved
        "memo":      m["concepto"],
        "amount":    m["monto"],          # MXN, sign by tipo (abono / cargo)
        "kind":      m["tipo"],
        "balance":   m.get("saldo_despues"),
    }

# 401 / session expiry -> re-establish the consented session, resume at cursor.

The próximos-pagos read is the same shape against the schedule endpoint, returning due date, amount, and the AmiRitmo term per installment. Because the term can still move inside the cutoff window, that read is reconciled rather than trusted on first pass — see the build details below.

What ships at handover

The center of the delivery is code that runs against Tarjeta amiga's real surfaces:

• Runnable client libraries in Python and Node.js covering session bootstrap, saldo / crédito disponible, the movimientos delta poll, próximos pagos, the cartera-electrónica balance, and policy listing.
• A cursor-based delta-sync job with a persisted cursor store and a tunable cadence, so movements, cash-outs, and bill payments stay current without re-reading history.
• A normalized schema mapping the Spanish fields (concepto, monto, fecha, tipo) to stable English keys, with MXN amounts and the Mexico City timezone preserved.
• Automated tests over the session bootstrap and each read, runnable in your CI against recorded response fixtures.
• An OpenAPI description of the reconstructed surface, an auth-flow report covering the celular + 16-digit + password session and token refresh, interface documentation, and short consent / data-retention guidance under Mexican rules.

Where teams plug this in

• A credit or BNPL aggregator that shows one balance and one upcoming-payment view across several cards, Tarjeta amiga among them.
• A personal-finance app that categorizes movimientos and forecasts the quincenal due dates so a user is never surprised by a payment.
• A servicing or collections tool that reconciles SPEI cash-outs and abonos against the movement ledger.

Mexican rules: consent and where Open Finance stands

The Ley para Regular las Instituciones de Tecnología Financiera (Ley Fintech), enacted in 2018, ordered financial entities to share data through standardized APIs and split that data into three layers: open, aggregate, and transactional — the last only with the user's express authorization. Supervision sits with the CNBV and Banxico. As of early 2026 the secondary rules for transactional and aggregate data are still unpublished, per Open Finance status coverage; what is live in practice traces back to Banxico's 2020 circular for credit bureaus and clearinghouses, and the CNBV's 2023–2024 consent and technical pilots.

For Tarjeta amiga that means the regulated transactional channel is not a route you can run now, and its issuer — a commercial non-bank — is not among the banks those pilots touch. The dependable basis is the cardholder's own consent, handled under the LFPDPPP data-protection law: we record consent, minimize what we read to what the use case needs, log access, and work under an NDA where the client wants one.

Build details we plan around

Two things about this card shape the integration, and we handle both on our side.

AmiRitmo terms are mutable inside a window

A cardholder can change a purchase's term until 23:30 the day after the purchase, per the app's stated cutoff. So a schedule pulled at lunchtime can legitimately differ by the next night. We treat the próximos-pagos schedule as provisional within that window and reconcile it once the cutoff passes, so the stored schedule reflects what the cardholder actually settled on.

The electronic wallet is derived, not deposited

The cartera electrónica is a discount that accrues from paying on time and in full — it is not cash sitting in an account. We model it as a computed reward ledger tied to payment events, so downstream code does not mistake it for a withdrawable balance.

SPEI cash-outs leave the card

An SPEI transfer lands in real time at an external CLABE in the cardholder's name. We capture the destination and channel (SPEI, Banorte reference, or ATM) alongside the matching movement, so a disbursement and its ledger entry reconcile cleanly. Access itself is arranged with the cardholder during onboarding — a consenting account, with consent recorded — so the build runs against real data from day one.

Screens this maps to

The public store screenshots we worked from while mapping the surfaces above.

Other Mexican cards in the same orbit

Same-category consumer cards and wallets in Mexico, each holding server-side balances and movements a unified integration would also touch. Listed for context, not ranked.

• Stori — fintech credit card aimed at first-time and thin-file borrowers; balance, movements, and payment dates behind the app.
• Klar — debit and credit with instant decisions and a deposit-backed card option; transaction history and balances per account.
• Vexi — no-annual-fee card on the American Express network; statements and interest-free months in-app.
• Nu (Nubank México) — credit card and account with detailed statements, limits, and movement feeds.
• RappiCard — card tied to the Rappi app that reports activity to the bureau; spend and repayment records.
• Plata Card — consumer card that moved to a banking license in 2026; balances and movement history per user.
• Hey Banco — digital bank with accounts, cards, and transfer history.
• Mercado Pago — wallet and credit line with balances, movements, and SPEI in and out.

What was checked, and when

Checked on 7 June 2026 against Tarjeta amiga's own app and withdrawal pages, the Google Play listing, the Ley Fintech text, and current Open Finance status coverage. Where a figure is not published — credit limits, user counts, internal endpoint names — this page says so rather than guessing. Citations:

• Tarjeta amiga — official app feature page
• Tarjeta amiga — cash withdrawal (SPEI / Banorte / ATM)
• Ley para Regular las Instituciones de Tecnología Financiera (full text)
• Open Finance in Mexico — regulatory status tracking

Compiled by OpenFinance Lab's integration team — assessment dated 2026-06-07.

Questions integrators ask

How does the movements sync stay current?

We ingest from a consented Tarjeta amiga session and poll the movimientos list with a cursor — the id of the last row we stored — so each run only fetches what is new instead of re-reading the whole ledger. The cadence is set to how often the card is actually used, and SPEI cash-outs and bill payments come through on the same poll.

If I read a payment plan today, can it change by tomorrow?

Yes. AmiRitmo lets a cardholder change a purchase's term — 6, 8, 10 or 12 bi-weekly periods — until 23:30 the day after the purchase, per the app's stated cutoff. We treat the próximos-pagos schedule as provisional inside that window and reconcile it once the cutoff passes, so the stored schedule matches what the cardholder finally chose.

Can this run on Mexico's Open Finance APIs?

Not today. The Ley Fintech ordered standardized financial-data APIs back in 2018, but the secondary rules for transactional data are still unpublished as of early 2026, and Tarjeta amiga's issuer is a commercial non-bank entity outside the banks the pilot stage covers. The dependable basis is the cardholder's own express authorization, and we build the consent model so it can move onto the regulated channel if and when that opens.

The card isn't from a bank — does that affect the integration?

It mainly affects the route, not the data. Tarjeta amiga is operated by Inversiones Accionarias Landus, S.A. de C.V., a commercial entity per its published terms, so there is no bank-style API mandate to lean on. Access is arranged with a consenting cardholder during onboarding, and handling follows Mexico's LFPDPPP data-protection rules — consent recorded, data minimized, NDA where the client needs one.

Starting a build

A first working pull of balance, movimientos, and the próximos-pagos schedule usually lands within one to two weeks. From there you can take it as source — runnable Python and Node.js clients plus docs that you own, from $300, invoiced only after delivery once you are satisfied — or skip owning code and call our hosted endpoints, paying per call with nothing upfront. Either way you give us the card and what you need from its data; we set up access and handle the compliance side with you. Tell us the specifics on our contact page and we will scope it.