Getting prepaid balances, transactions and card details out of My Card Wallet

A single My Card Wallet profile can hold a stack of prepaid cards, and each one carries its own live balance and its own transaction list — all served from Blackhawk Network's prepaid platform, the same backend that powers myprepaidcenter.com. Most teams who come to us want that pulled in bulk. Backfill every card and every posted transaction once, then keep the balances current as cardholders spend. That single requirement shapes the build: a batch pass first, a windowed delta pull after, rather than a fragile one-off scrape.

Reaching the data behind the login

The app offers a cardholder more than one way in, and the modes return overlapping but not identical data. A card can be opened on its own with the 16-digit number, expiry and security code; or the cardholder can sign in to a registered profile with email and password and see every card they have saved. That registered session is the one worth building around for ingestion, because it enumerates the whole portfolio at once. We treat the per-card mode as a fallback for a single card that has not been added to a profile.

The routes that genuinely fit are these, and we would lead with the first:

Authorized protocol analysis of the cardholder session

We sit in the authenticated session the cardholder already has, map the calls the app and the portal make to fetch the card list, each balance, and each statement line, and turn that into a small client your code can call. Reachable: everything the cardholder can see — balances, transactions, card status, the credentials behind the checkout view. Effort is moderate; the auth chain and the per-card calls are the work. Durability is good as long as we keep a re-validation pass in maintenance, since the platform's internals can shift. Access is arranged with you during onboarding, running against a consenting cardholder's own cards.

User-consented credential access

For products where your own end users connect their cards, we wire the same client behind an explicit consent step, store the session material the way you require, and refresh it when it lapses. Reachable: the same surfaces, scoped to each consenting user. This is the route when you are aggregating many cardholders rather than reading one known account.

There is no separate file-export feature to fall back on here, so the session-based client is the spine of either route. We recommend the protocol-analysis client for a fixed set of known cards, and the consented variant once you are onboarding users at scale; the underlying code is shared between them.

What each prepaid card exposes

A backfill, end to end

Here is the shape of the bulk pass against a consenting account. The call names are illustrative; the exact session and field shapes are confirmed during the build, not guessed.

# Run only against a consenting cardholder's own cards.
# Shapes verified against the live app/portal session during the build.

session = mcw.login(email, password)          # or per-card: mcw.card_session(pan, exp, cvv)
cards   = session.list_cards()                # every prepaid card on the profile

for card in cards:
    bal  = session.balance(card.id)           # current spendable amount, server-refreshed
    txns = session.transactions(card.id,      # posted statement lines for this card
                                since="2026-01-01")

    store.upsert_balance(card.id, bal.available, bal.currency, as_of=bal.fetched_at)
    for t in txns:
        store.upsert_txn(card.id, t.id, t.merchant, t.amount, t.posted_at)

# The upsert keys on (card.id, txn.id), so re-running the pass over an
# overlapping date window lands the same rows once, not twice.

After the first full pass, the same client runs on a schedule with a short since window per card, which is the delta pull. Balances are recomputed from the new lines and checked against the server figure so the two never drift apart.

What lands in your repo

The deliverable is working code, not a slide deck. For My Card Wallet that means:

• A runnable client in Python and Node.js: login and per-card session handling, list_cards, balance, and transactions, plus a batch-backfill runner and a delta-pull scheduler.
• An automated test suite with fixtures captured from a consenting session, covering the parsed balance, transaction and card-registry shapes.
• A sync design that separates the one-time backfill from the windowed incremental pull, with idempotent upserts keyed on card and transaction id.
• The normalized schema below plus a loader that writes it into your warehouse.

Alongside the code you get an OpenAPI/Swagger description of the reverse-engineered interface, a short protocol and auth-flow report covering the login-to-session-to-statement chain, interface documentation, and data-retention guidance written around the PCI-sensitive card fields.

Normalized shape for the warehouse

Balances, statement lines and the card registry land in one consistent structure regardless of which access route fed them:

{
  "card": { "id": "…", "last4": "4821", "status": "active", "art": "visa" },
  "balance": { "available": 42.17, "currency": "USD", "as_of": "2026-06-08T14:02:00Z" },
  "transactions": [
    { "id": "…", "merchant": "…", "amount": -12.40, "currency": "USD", "posted_at": "2026-06-05" }
  ]
}

The last4 value above is a placeholder. By default the full PAN never reaches this structure.

Authorization, and the US rules in play

My Card Wallet's cards are program-managed by Blackhawk Network and issued by a sponsor bank — Pathward, N.A. appears as the issuer for a Blackhawk-managed general-purpose reloadable product in the CFPB's prepaid product-agreements database. Because these are prepaid accounts, the consumer protections sit under Regulation E's prepaid-account provisions, and the basis we build on is the cardholder authorizing access to cards that are theirs. That authorization is durable and it is what every route here assumes.

The CFPB's Personal Financial Data Rights rule (12 CFR Part 1033) might one day give prepaid accounts like these a standardized consumer-permissioned feed. It is not there yet — the rule is back in agency reconsideration and is not in force — so we treat it as where the picture may go, not as today's law. Practically: we log what was accessed and when, keep consent records, minimize what we retain, and work under an NDA where the engagement needs one.

What we account for in this build

A few specifics about this app drive real decisions in the code, and we handle each as part of the work:

• The two access modes diverge. The per-card route (number, expiry, security code) reads one card; the registered-profile route enumerates the whole saved set. We build both into the client and prefer the profile session for any multi-card backfill, falling back to the per-card mode for a single unregistered card.
• The card-details view exposes full PAN, expiry and security code. Those fields are PCI-sensitive, so the default loader stores only a token and the last four; raw card numbers stay out of the warehouse unless your use case needs card-on-file, in which case we agree storage and handling with you before any of it is written down.
• Prepaid balances change on every tap and after each load. We anchor the refresh cadence to the transaction stream rather than a fixed clock, recomputing the stored balance from new lines and reconciling it against the server-side figure so reporting does not lag the card.

Screens we mapped against

The store screenshots below are the surfaces we trace the calls against. Open one to see it full size.

Other prepaid and wallet apps in the picture

Teams integrating My Card Wallet usually have a few of these in the same project, and a unified feed has to normalize across them:

• Netspend — general-purpose reloadable account; its app holds balance, transactions, direct-deposit status and spend alerts.
• PayPal Prepaid Mastercard — a prepaid account that links to PayPal; balance, transfers and transaction history sit in the app.
• Mango Prepaid Mastercard — prepaid account managed through a mobile portal, with balance and transaction views.
• Bluebird by American Express — prepaid debit account with spend tracking and sub-accounts on its app.
• Pass2U Wallet — an Android pass and card vault that stores card art, barcodes and numbers for later use.
• Stocard — a loyalty and membership card wallet holding card numbers and barcodes rather than balances.
• Google Wallet — a provisioning target; holds tokenized card credentials and passes on the device.
• Samsung Wallet — another provisioning target for tokenized cards and passes.
• Curve — aggregates several underlying cards behind one, with its own transaction record across them.

Questions integrators ask about My Card Wallet

Prepaid balances move every time the card is tapped — how current can the stored value be?

As current as the spend stream lets it be. The first run backfills every posted transaction on the card and gives you a balance you can reconcile against the server-side figure; after that we pull on a schedule and on demand, so the stored balance tracks new transactions rather than drifting. For a card that is used heavily we tighten the polling window, and for a dormant one we widen it.

Can the client read full card numbers, or only balances and history?

Both are reachable behind the cardholder's own login, since the app itself surfaces full card details for online checkout. Those credentials are PCI-sensitive, so by default we store only a token and the last four digits and keep the raw number out of your warehouse. If a use case genuinely needs card-on-file, we agree the handling and storage with you up front and build to it.

Is there a US data-rights rule we can lean on instead of the cardholder's login?

Not a settled one today. The CFPB's Personal Financial Data Rights rule under 12 CFR Part 1033 could eventually standardize a consumer-permissioned feed for prepaid accounts, but it is back in agency reconsideration and not in force, so we do not build against it as if it were. The dependable basis is the cardholder authorizing access to their own cards, which is also what Regulation E's prepaid-account framework assumes.

How soon can we have a working backfill of one cardholder's cards?

Usually one to two weeks. That covers the login and card-session handling, enumeration of the cards on a profile, balance and transaction pulls, the normalized schema, and a test suite that runs against a consenting account's own cards.

What we read, and when

Checked on 2026-06-08 against sources we opened directly: the app's own Google Play listing for its feature set and package id, Blackhawk Network's partner disclosure for the program and issuing relationship, the CFPB prepaid product-agreements database where the program is registered, and the CFPB's reconsideration page for the Personal Financial Data Rights rule for the rule's current status. Where a detail is not published — the exact internal endpoints, the session-token format — we confirm it during the build rather than assume it.

OpenFinance Lab — interface engineering notes, checked 2026-06-08.

Starting a build

A first build usually lands inside one to two weeks: a runnable client that signs in, enumerates a cardholder's prepaid cards, and backfills balances and transactions into the schema you specify. From there you choose how to take it. The source-code route starts at $300 — you get the runnable client and the docs, and you pay only after delivery, once it does what you asked. Or skip hosting it yourself and call our endpoints instead, paying per call with nothing upfront. Tell us which cards are in scope and what you need out of them at our contact page.