Bringing a Paytient member's HPA ledger into your own stack

A Paytient member opens the app to a Health Payment Account — an available-to-spend credit line that an employer or health insurer funds, repaid over time without interest or fees, as the app describes it. Behind that single screen sits a per-member ledger: a balance, a virtual Visa card, a running list of card swipes tagged by what they paid for, and a repayment plan attached to each one. That is the material worth integrating. None of it is a static document; it changes every time the member taps the card or shifts a payment date.

Our way in is a consenting member, not a vendor key. With the member's authorization we drive an authenticated session and read what they read, then hand you a language client that does the same on a schedule you control. The brief below names the surfaces, the route we would actually take, and what we deliver. The lead deliverable here is a Python or Node.js client you can drop into an ingestion job.

The data behind a member login

Each row below is a surface a member actually sees in the app, mapped to where it comes from and what an integrator does with it. The category tags on transactions are the useful part — Paytient already separates a copay from a coinsurance charge from a bill that lands after the visit.

Reaching the account, and which path holds up

Three routes apply to Paytient. They are not equal; pick by how durable you need the feed and how much the member is in the loop.

1. User-consented session client

A member authorizes access; we drive an authenticated session and read every surface they can see. Reachable: all of the domains above. Effort is moderate. Durability tracks the app's own session handling, so we build in a re-validation step and keep the client thin enough to patch fast. Access is arranged with the consenting member during onboarding — that is our step, handled with you, not a form you fill first.

2. Authorized interface integration and protocol analysis

Under your authorization we map the app's own traffic to model its endpoints, its token and cookie chain, and the exact response shapes. Reachable: the same surfaces, written up as a stable contract you can code against. The work costs more up front and earns it back in durability — once the interface is documented, maintenance is a small patch when the app shifts.

3. Member-driven export and emerging data rights

As a fallback the member can pull their own monthly e-statements, and where they link Paytient-adjacent bank or HSA flows, a consumer-authorized aggregation path opens up. This is the slowest to refresh and the most forward-looking, since the US rule that would formalize consumer data access is still being rewritten.

If you only build one path, build the consented-session client first — it reaches everything, refreshes on your schedule, and the source ships as code you own. Route 2 is the upgrade when you need the interface pinned down as a contract that survives app updates.

What lands in your repo

The headline is runnable source, not paperwork. For Paytient that means:

• A Python and Node.js client for the HPA surfaces — account summary, transactions with their category tags, repayment plans, funding sources, e-statement retrieval — ready to call from an ingestion job.
• Webhook-style handlers for your side, so a sync run can push new swipes and plan changes into your own queue or warehouse as it reads them.
• An automated test suite that exercises each call against recorded fixtures, so a change in the upstream response shape shows up the next time you run it.
• A batch-versus-incremental sync design: a full backfill for the first load and a since cursor for everything after, with the funding-source normalization baked in.
• An OpenAPI / Swagger specification describing the modeled endpoints, plus a protocol and auth-flow report covering the session and token chain as it actually behaves here.
• Interface documentation and a short compliance and data-retention note tuned to health-spend data.

The spec and the auth-flow report matter, but they ride behind the code — you get something that runs first, then the documents that explain it.

A session pull, in code

This is the shape of the consented-session client, illustrative and confirmed against the member portal during the build. The auth object is a member-authorized session, never a vendor credential.

from paytient_hpa import HpaClient   # the package we hand you

client = HpaClient(session=consented_member_session)

# Available-to-spend and outstanding balance for one member
acct = client.account_summary()
# -> { "available_credit": "420.00", "outstanding": "180.00",
#      "card": { "last4": "1234", "network": "visa", "virtual": true } }

# Incremental read: only swipes posted since the last cursor
for txn in client.transactions(since="2026-01-01"):
    # txn.category in ("copay", "coinsurance", "post_visit_bill", "uncovered")
    # txn.merchant, txn.amount, txn.posted_at, txn.plan_id
    sink.write(normalize(txn))

# The repayment plan attached to a given transaction
plan = client.repayment_plan(txn.plan_id)
# -> installments[], cadence in ("monthly", "per_paycheck"),
#    funding_source in ("bank", "payroll", "hsa", "fsa"),
#    next_draw_on, payoff_state

# Errors surface as typed exceptions, not silent empty reads
try:
    acct = client.account_summary()
except ConsentExpired:
    reauthorize(member)   # re-prompt inside the consent window

The funding-source values map one-to-one onto the repayment options the app offers — a bank account, payroll deduction, or a tax-advantaged HSA or FSA — which is why we normalize them once at the client edge rather than in every downstream consumer.

Where this gets used

A few shapes we see for Paytient data once it is reachable:

• A benefits portal that shows a member their available HPA credit and outstanding balance next to their HSA and FSA balances, in one place.
• A point-of-care affordability check, where a provider's intake system reads available credit before quoting a copay.
• Reconciliation for a plan administrator, matching Paytient card swipes against claims and explanation-of-benefits records.
• A cashflow forecast that pulls each repayment plan's installments to project upcoming payroll deductions across a workforce.

Consent, data rights and the US picture

The dependable basis for reading a member's Paytient data is the member's own authorization. Paytient is issued only through an employer or health plan, the card runs on Visa through a Commerce Bank collaboration (per Commerce Bank's 2022 announcement), and a consenting member can authorize access to what their account already shows them. We keep consent records, log every read, minimize what we retain, and work under an NDA where the data touches identified health spending.

The federal rule that might one day standardize consumer access here — the CFPB's Section 1033 Personal Financial Data Rights rule — is not the framework this integration rides today. A court enjoined its enforcement and the agency reopened it for reconsideration in 2025 (per the CFPB's own reconsideration docket), so its specific obligations are unsettled. We treat it as where the rule may go, not current law, and anchor the work on member consent in the meantime. Because the data describes health spending, GLBA-style privacy handling and PCI-grade care for card references are the operating posture, not an afterthought.

What the build has to get right for Paytient

Two things about Paytient specifically shape how we build, and we handle both as part of the work:

• Per-sponsor eligibility. Because spend categories are "approved by your employer or health plan," the same data shape carries a different allow-list for each sponsor. We model eligibility per sponsor and plan, so two members on different plans resolve correctly rather than getting flattened into one ruleset.
• Mixed funding with tax strings attached. A repayment can draw from a bank account, payroll, an HSA or an FSA, and the last two carry eligible-expense substantiation rules. We normalize all four into one field and flag the HSA and FSA cases so your downstream system applies the right substantiation logic.
• One account, two cards. The virtual Visa is live at signup and a physical card follows; both point at the same member ledger. We reconcile so a swipe on either card resolves to a single account, and the transaction stream does not double-count.
• Consent that has a lifetime. The session is member-authorized, so we schedule the re-authorization inside the member's consent window to keep the sync's standing. Access for the build is arranged with you during onboarding — the work runs against a consenting member account or a sponsor sandbox.

Screens we mapped

The member-facing screens used to confirm the surfaces above. Tap to enlarge.

How this brief was built

The surfaces here come from the app's own Play Store listing and Paytient's member-facing explanation of the Health Payment Account, checked in June 2026. The issuer relationship is drawn from Commerce Bank's 2022 announcement, and the regulatory status from the CFPB's published reconsideration of the Section 1033 rule. Sources opened during the work:

• Paytient on Google Play
• Paytient — What is a Health Payment Account
• Commerce Bank — Paytient collaboration announcement (2022)
• CFPB — Personal Financial Data Rights Reconsideration

OpenFinance Lab · engineering notes, June 2026.

Apps in the same lane

Other medical-payment and patient-financing products hold structurally similar data — balances, installment contracts, provider routing — which is why a single integration layer across them tends to pay off. Named here for context, not ranked.

• CareCredit — Synchrony's medical credit card; holds revolving healthcare-credit balances and promotional-financing terms per cardholder.
• Cherry — point-of-sale patient financing; approval amounts, installment contracts and provider-linked plans behind a member login.
• Sunbit — buy-now-pay-later for dental, optical and everyday care; per-transaction installment plans per account.
• Affirm — general installment financing that reaches healthcare merchants; loan schedules, balances and autopay records per user.
• MedZero — employer-sponsored, interest-free medical purchasing accounts; the closest structural cousin to Paytient's sponsored line.
• Scratchpay — veterinary and medical-practice financing; payment-plan records and provider routing.
• PayMedix — a provider-network payment platform (Health Payment Systems) with interest-free patient balances and statements.
• Walnut — point-of-care installment financing that splits a medical bill into smaller payments over time.

Questions integrators ask about Paytient

Can the delivered client keep a member's HPA ledger in sync, or is it a one-time pull?

It is built to repeat. The client we hand you exposes a full account_summary call plus a transactions(since=...) cursor, so a scheduled or on-demand job only carries new swipes and changed repayment plans rather than re-reading the whole history every run.

Does the transaction data separate copays, coinsurance and uncovered bills?

Yes. Each card transaction carries the category the app itself shows — a copay or coinsurance at the time of care, or a bill that arrived after the visit — so you can route or report on them without re-deriving the type.

How do HSA and FSA funding sources appear, and who handles substantiation?

Repayment can draw from a bank account, payroll deduction, an HSA or an FSA. We normalize all four into one funding_source field and flag the HSA and FSA cases, since those carry eligible-expense substantiation rules that your downstream system has to respect.

What is the legal basis for reading a member's Paytient data in the United States today?

The member's own authorization. Paytient accounts are issued through an employer or health plan, and a consenting member can authorize access to what they see. The CFPB's Section 1033 personal financial data-rights rule, which may later formalize this, is currently enjoined and back under agency reconsideration, so it is treated here as a forward-looking development rather than current law.

Getting it built

Source code lands in your repository once we deliver — the runnable Python and Node.js client, the test suite, and the interface docs — and you pay from $300 only after it is in your hands and working. If you would rather not host anything, the same calls run on our side and you pay per request, with nothing upfront. Most Paytient builds run a one-to-two-week cycle. Tell us the app and what you want out of its data at /contact.html and we will scope it; access and the compliance paperwork are arranged with you as part of that.