Getting card balances and transactions out of My Card Wallet

Behind a My Card Wallet sign-in sits a current balance, a running transaction list, and the full card details for every prepaid reward card a person has added. The app is Blackhawk Network's cardholder front end for MyPrepaidCenter — the activation and redemption platform that turns a rebate, gift, or incentive token into a Visa, Mastercard, American Express, or Discover prepaid card, per Blackhawk's own MyPrepaidCenter description. That backend is what an integration actually talks to. The app and the myprepaidcenter.com portal are two windows onto the same records.

The bottom line for this app: there is no consumer-facing open-banking mandate in force in the US that hands you these records, so the working basis is the cardholder authorizing access to a card they hold. We map the request chain the app and portal already use, normalize the responses, and hand back something you can call. The route is the same whether you want one consumer's float or a finance team's whole book of reward cards.

Where each balance and transaction field lives

Every row below is a real surface a cardholder sees in the app or the portal. The value to an integrator is in normalizing them into one shape across the many issuing programs these cards ship under.

Authorized routes into the card data

Three routes genuinely apply here. They differ in what they reach and how long they hold up.

Authorized protocol analysis under cardholder consent

This is the one we'd build on. We observe the calls the My Card Wallet app and the cardholder portal make once a card is authorized, then reproduce the session and the per-card balance, transaction, and detail requests as a clean interface. Access is arranged with you during onboarding — the build runs against a card the holder consents to, or a sponsor-supplied test card. Reachable: everything in the table above. Durability is good for the session and request structure; the front end can change, which we plan for in maintenance.

Native transaction export from the portal

The portal's transaction-history view is the human-readable record of spend on a card. Where it offers a structured download, we use it as a validation reference and a low-touch fallback for batch reconciliation. We confirm during the build exactly what the export yields for a given program rather than assuming a format.

Standardized open-banking access (forward-looking)

A US consumer data-access right that would standardize this is not settled — see the consent section. We don't build on it today, but we structure the consent records so that if a standardized path becomes usable for prepaid accounts, the integration can adopt it without a rebuild.

What lands at handoff

Concrete artifacts, scoped to the surfaces above:

• An OpenAPI specification covering the cardholder-session call, the balance, transaction-history, card-detail, and card-list endpoints.
• A protocol and auth-flow report: the login to session-token to per-card request chain, the credential-consent step, and how authorization holds appear versus posted items.
• Runnable source in Python and Node.js for those endpoints, including the pending-versus-settled normalization.
• Automated tests run against a consenting card or a supplied test card.
• A normalized schema so balance, transaction, and card objects from different issuing programs collapse into one shape.
• Interface documentation plus consent-logging and data-retention guidance — PAN masked at rest, consent recorded per card.

How a balance-and-transaction pull looks

Illustrative shape only. Paths and field names are confirmed during the build, not published by Blackhawk; the flow runs only against a card the holder has authorized.

# 1) Cardholder-consented session. Either a registered MyPrepaidCenter login,
#    or the 16-digit PAN + expiry + CVV the cardholder supplies for their card.
POST /cardholder/session
  body: { "pan": "<consented>", "exp": "MM/YY", "cvv": "<consented>" }
  -> { "session_token": "…", "cards": [ { "card_id": "c_01", "last4": "1234",
                                          "network": "visa", "status": "active" } ] }

# 2) Live available balance for one card (net of pending holds).
GET /cardholder/cards/c_01/balance
  Authorization: Bearer <session_token>
  -> { "available": 142.18, "currency": "USD", "as_of": "2026-06-15T14:02Z" }

# 3) Transaction history, paged. auth_hold flags pending vs settled.
GET /cardholder/cards/c_01/transactions?from=2026-01-01
  -> { "items": [
         { "date": "2026-05-02", "merchant": "…", "amount": -24.99,
           "type": "purchase", "auth_hold": false },
         { "date": "2026-06-14", "merchant": "…", "amount": -8.50,
           "type": "purchase", "auth_hold": true } ],
       "next_cursor": null }

# Error handling we account for: invalid CVV / locked card -> 4xx with a
# program-specific reason; expired card -> status "expired" but history still readable.
      

Where teams put this data to work

• A company that funds reward cards reads balances and transactions across its issued cards to confirm redemption and track remaining float.
• A budgeting app folds a consumer's prepaid balance and recent spend in beside their bank accounts for a single view.
• A support team reads card status and the last few transactions to answer "where did my balance go" tickets — usually an authorization hold.
• A finance team schedules a transaction-history pull into a ledger across many reward cards at once.

Consent and the US prepaid-account rules

For a prepaid reward card the dependable basis is the cardholder authorizing access to their own card — not a federal data-access mandate. Regulation E already covers prepaid accounts: the CFPB's 2016 Prepaid Rule extended its protections to prepaid accounts including general-purpose reloadable cards, which is what defines the records a card must keep — balances, transactions, error resolution. That part is settled and shapes what data exists to integrate.

The open-banking piece is not. The CFPB rule that would standardize a consumer's right to pull their own financial data is enjoined and back in agency rulemaking, and it's unsettled whether reward and gift prepaid accounts land inside its final scope. So we treat it as where access may go, not current law. In practice we keep consent records per card, mask card numbers in everything we return, sign an NDA where the work touches a client's program data, and minimize what we store to the fields you actually use.

Engineering details we handle here

Three things about this app shape the build, and we account for each:

• Card details are gated behind the holder's own credentials, so we design the sync to run only against authorized cards and to keep PANs tokenized or masked through every layer we hand back.
• The available balance moves with authorization holds before purchases post, so we model the pending-versus-settled distinction — otherwise a downstream ledger shows a balance that appears to drift on its own.
• These cards are issued under many rebate and gift programs across four networks, each with different fee and expiry rules, so we scope the field parsing per program and add a front-end change detector to maintenance, so a portal redesign surfaces as a failed check rather than silent bad data.

App screens we mapped

Store screenshots of the cardholder surfaces, used to trace where each field is rendered.

How this brief was put together

In June 2026 we read the Google Play listing and Blackhawk Network's own MyPrepaidCenter and balance pages to fix the data surfaces and how cardholders reach them, then checked the CFPB's prepaid-card and Personal Financial Data Rights pages to settle which US rules actually apply to a prepaid reward card. Primary sources:

• My Card Wallet on Google Play
• Blackhawk Network — check balance and transactions
• CFPB — prepaid cards (Regulation E)
• CFPB — Personal Financial Data Rights (§1033) status

Researched and mapped by the OpenBanking Studio integration desk, 15 June 2026.

Other prepaid and wallet apps in the same data space

Each of these holds comparable per-cardholder records, which is why teams often want them behind one normalized integration:

• Netspend — reloadable Visa and Mastercard prepaid with an Online Account Center showing balance, deposits, and transaction history.
• PayPal Prepaid Mastercard — a prepaid account whose app handles balance, transaction history, and transfers to and from PayPal.
• Bluebird by American Express — a prepaid spending account with in-app balance and history; per American Express's closure notice these accounts are being wound down in 2026.
• Chime — a fintech account with a Visa debit card, in-app balance, and a transaction feed.
• Greenlight — a family prepaid card with per-child balances, chores and allowance, and transaction notifications to parents.
• Green Dot — prepaid and GoBank accounts with app-based balance, direct deposit, and transaction history.
• Brink's Money Prepaid — a reloadable prepaid Mastercard with app balance and spending history.
• Vanilla Gift — Visa and Mastercard gift cards with an online balance-and-transaction lookup keyed to the card number.

Questions integrators ask about My Card Wallet

Can you read a card's balance and transactions without its 16-digit number?

No. Those records sit behind the cardholder's own credentials. The available balance, recent transactions and card status become reachable once the cardholder authorizes a specific card — the 16-digit number with expiry and CVV, or a registered MyPrepaidCenter login. The integration is built to run only against cards the holder has consented to.

Why doesn't the available balance always match the posted transactions?

A prepaid card's available balance drops when a merchant places an authorization hold, before that purchase settles. So a pending hold can make the balance look lower than the posted list explains. We model the pending-versus-settled split so a downstream ledger reconciles cleanly.

These cards come from many different rebate and gift programs — does that change the work?

It changes the parsing, not the route. Cards issued through MyPrepaidCenter run on Visa, Mastercard, American Express and Discover under many issuing programs, each with its own fee and expiry rules. We scope the field mapping per program so expiry, fees and status read correctly whichever issuer a card sits under.

Should the data come from the My Card Wallet app or the MyPrepaidCenter website?

Both reach the same Blackhawk backend, so we map both and pin the integration to whichever surface is more stable for the records you need. The portal's transaction-history view is the usual reconciliation reference; the app sits closer to live balance display.

The build lands in one to two weeks. Take it as runnable source for the cardholder-session, balance, and transaction endpoints — from $300, billed only after delivery once it works against a consenting card — or skip hosting and call our endpoints on a pay-per-call basis with nothing upfront. Tell us the card program and what you need from it at /contact.html.