Extracting EBT balances and card-lock state from Propel's state portal network

Over five million SNAP recipients, per the app's own count, check their EBT balance through Propel. That data flows from state-operated EBT portals — each managed by a different payments processor. Propel connects to portals like ebtEDGE (run by FIS) and ConnectEBT (run by Conduent) with the user's permission, pulling balance, transaction history, and card-security state into a single mobile view.

The integration challenge is not reaching one portal. It is reaching dozens. Each state portal has its own authentication scheme, its own response format, and a different subset of security features. Card-locking is live in 45 states and territories according to the app's documentation; out-of-state transaction blocking covers a similar count; suspicious-transaction monitoring is available in approximately 30. Any integration that covers Propel's full footprint must map each portal family separately.

Data behind Propel's state-portal relay

WIC data is structured differently from SNAP. It is category-based — dairy, cereal, fruits and vegetables — rather than a single dollar figure. The integration surfaces these categories as distinct line items so downstream tools can work with them correctly.

Routes into state EBT portal data

1. Authorized interface integration — protocol analysis of the portal relay

Propel's mobile client talks to its own backend, which relays requests to per-state EBT portals. The integration captures and reproduces this portal-relay traffic under the user's authorization. We map the authentication handshake — credential exchange, session token lifecycle, portal-specific headers — and the structured responses for balance, transactions, and card-management endpoints. This route covers the widest data set, including card-lock and blocking controls.

2. Direct state-portal access under user consent

Instead of going through Propel's relay, the integration can hit state EBT portals directly. ebtEDGE covers roughly 35 states; ConnectEBT covers 14, per its App Store listing; a handful run their own portals. The tradeoff is that each portal family is a separate integration point, but the client gains independence from Propel's infrastructure. We handle the per-state mapping in either scenario.

3. Native export as a supplementary feed

Some state portals offer CSV or receipt-style downloads of transaction history. Useful for reconciliation against live-pull data, but they don't cover real-time balances or card-security state.

Route 1 is what we build for most engagements — broadest data coverage through a single integration point. Route 2 fits clients who need to remove Propel from the data path. Route 3 is a reconciliation add-on for either.

Protocol sketch: pulling a balance through the portal layer

# Illustrative — exact fields confirmed during the build
POST /v1/ebt/balance
Authorization: Bearer {session_token}
Content-Type: application/json

{
  "state_code": "CA",
  "card_last_four": "4821",
  "portal_session": "{portal_relay_token}"
}

# 200 OK
{
  "snap_balance": 247.63,
  "cash_balance": 0.00,
  "wic": null,
  "as_of": "2026-06-06T14:22:00Z",
  "card_locked": false,
  "out_of_state_blocked": true,
  "recent_transactions": [
    {
      "date": "2026-06-04",
      "merchant": "WALMART #3219",
      "amount": -32.47,
      "type": "snap_purchase",
      "city": "Sacramento",
      "state": "CA"
    },
    {
      "date": "2026-06-01",
      "merchant": "ALDI #4107",
      "amount": -18.90,
      "type": "snap_purchase",
      "city": "Elk Grove",
      "state": "CA"
    }
  ]
}

The portal_session token is obtained via the state portal's own auth flow — OAuth-like on some portals, credential-and-cookie on others. The deliverable wraps this in a per-state adapter so the caller always sends the same request shape regardless of which portal backs the state.

What the build produces

Every Propel integration ships with a core set, tuned to this app's multi-portal architecture:

• OpenAPI specification covering balance queries, transaction-history pulls, card-lock reads/writes, and deposit-schedule lookups, with per-state parameters documented.
• Protocol and auth-flow report documenting the session-token lifecycle for each portal family (ebtEDGE, ConnectEBT, state-specific), including token refresh windows, cookie chains, and header requirements.
• Runnable source code (Python or Node.js) — the portal-adapter layer with per-state modules, a unified client interface, and error handling for portal downtime and session expiry.
• Automated tests — integration tests against recorded portal responses, plus a live-validation suite that runs against a consenting account.
• State capability matrix — a structured map of which data domains and card-security features are available per state, generated from portal responses observed during the build.
• Interface documentation — setup guide, credential-management notes, and a runbook for handling portal changes.

Where this data goes

Multi-benefit household dashboards. Social-services platforms pull SNAP, TANF, and WIC balances into a single household view alongside non-EBT benefits. The integration normalizes balances across portal families so the dashboard sees one schema regardless of the cardholder's state.

Fraud-alert automation. Case-management systems subscribe to transaction data and card-security state. When a suspicious transaction fires or an out-of-state purchase appears on a locked-state card, the system creates a case, optionally locks the card via the integration, and notifies the cardholder.

Spend-pacing and grocery planning. Budgeting apps ingest the SNAP balance and transaction history to project when funds will run out, then suggest purchase timing around the deposit schedule. WIC category data feeds grocery-list generators that match available benefit categories to store inventory.

Benefits-eligibility verification. Verification services confirm that a user holds an active EBT card and receives SNAP benefits — for example, to qualify for reduced-rate internet under the FCC's programs or retailer discount programs for EBT cardholders.

User consent and the EBT regulatory frame

EBT account data is government-benefits data, not traditional bank-account data. The governing framework is the USDA's Food and Nutrition Administration (formerly FNS, renamed as of June 2026), which sets the rules for how state EBT systems operate, including data access and cardholder privacy. Propel itself operates on explicit user consent — its own documentation states it accesses EBT account information "with your permission via state EBT systems."

The integration follows the same consent basis. The cardholder authorizes access; the integration retrieves only the data domains the cardholder has consented to; session tokens are scoped and short-lived. State-level privacy laws apply to how data is stored and shared downstream — California's CCPA, for example, where the cardholder is a California resident. Consent-record logging and token-lifecycle management are part of every delivery.

Data minimization is the practical default. Per Propel's security page, the app does not store PINs, full card numbers, or Social Security numbers. The integration mirrors this posture: it pulls the structured data needed for the client's use case and holds no cardholder credentials at rest.

Multi-state EBT engineering: what the build accounts for

Portal heterogeneity is the central engineering problem. ebtEDGE and ConnectEBT cover the majority of states between them, but their session-management and response formats differ enough that a generic HTTP client won't work. We build a portal-adapter abstraction — one adapter per portal family, each mapping that family's auth flow and response schema to a common internal model. When a state switches processors, as happens during EBT modernization (the USDA's chip-card rollout is ongoing, per FNS documentation), only the adapter for that state changes.

Card-security features vary by state. Not every state exposes card-lock, out-of-state blocking, and online-transaction blocking through its portal. The build probes each target state's portal during development and records availability in the capability matrix. Client code checks the matrix before attempting a security operation, so it fails gracefully rather than hitting an unsupported endpoint.

Session-token lifetimes are short on some portals — as low as a few minutes of inactivity. The adapter layer manages token refresh transparently, but the architecture is built around short-lived request/response pulls rather than persistent connections. We design the sync around these refresh windows so sessions do not silently expire mid-pull.

Propel interface screenshots

These Play Store screenshots show the balance view, transaction list, card-security controls, and benefit-update screens that the integration reads from.

Sources and assessment date

This mapping draws on the following primary sources, all accessed in June 2026:

• Propel: What is the Propel app and how does it work? — describes how Propel connects to state portals with user permission and displays balance and transaction data.
• Propel EBT Security Features — state-by-state breakdown of card-lock, out-of-state blocking, online transaction blocking, and suspicious-transaction monitoring availability.
• USDA FNS: SNAP EBT Modernization — EBT chip-card standard (X9.58-2024), state implementation timelines, and mobile-payment pilot plans.
• Propel Security — data-minimization practices: no PIN storage, no full card numbers, encryption between app and portal.

Mapping reviewed June 2026 by the OpenBanking Studio integration desk.

Other EBT and benefits apps worth knowing

Propel sits alongside several apps that connect to the same underlying state EBT portal infrastructure. Integrating across this category means mapping a shared set of portal families, which makes multi-app coverage more efficient than starting from scratch each time.

ebtEDGE — operated by FIS, this is the official EBT portal app for roughly 35 states. It surfaces balance, transaction history, and PIN management through the ebtEDGE portal that Propel also reads from.

ConnectEBT — Conduent's EBT app, covering states including Alabama, Arkansas, Delaware, Georgia, and Pennsylvania. Balance and transaction data flows through Conduent's portal infrastructure, a distinct integration surface from ebtEDGE.

LifeInCheck EBT — Louisiana's state-sponsored EBT app, offering balance inquiries, deposit schedules, transaction history, and multilingual support (English, Spanish, Vietnamese). It connects to Louisiana's own portal rather than the FIS or Conduent systems.

Your Texas Benefits — the Texas Health and Human Services portal app for SNAP, Medicaid, and TANF. Texas runs its own Lone Star card system independent of the FIS/Conduent split.

ACCESS HRA — New York City's Human Resources Administration app, covering SNAP, cash assistance, and housing benefits for NYC residents specifically.

Benny — a third-party benefits tool that helps users check EBT balances and find state-specific benefit information across multiple states.

WorkMoney — a financial-tools platform that partners with Propel and helps benefits recipients find savings on groceries, bills, and services. Its data complements EBT balance data in household-finance dashboards.

Questions integrators ask about Propel EBT data

Does a single integration cover all of Propel's state EBT portals?

The delivered source handles the major portal families — ebtEDGE, ConnectEBT, and state-specific portals — with per-state configuration for auth flows and response parsing. We map each portal during the build so the client gets a unified interface across whichever states they need. Reach out to scope a specific state set.

Can the integration pull card-lock status and fraud-blocking settings?

Yes, where the underlying state portal exposes card-lock, out-of-state blocking, and online transaction blocking controls, the integration reads and — where supported — writes those settings. Availability varies by state; the deliverable includes a state-by-state capability matrix.

How do you handle portal changes when a state switches EBT processors?

Processor migrations — for example a state moving from Conduent to FIS — change the authentication flow and response format. We build the integration with a portal-adapter layer so a processor switch requires updating that adapter rather than rewriting the whole client. Maintenance retainers cover this kind of ongoing adjustment.

For a Propel EBT integration, we deliver runnable source code from $300 — paid after delivery, once you're satisfied with the build. If you'd rather not manage source yourself, our pay-per-call hosted endpoints handle the portal relay with no upfront fee. Most builds ship inside two weeks. Tell us the app and what you need.