The card in this wallet is issued by Evolve Bank & Trust, and the rails behind it are Branch's worker-payments platform — USHG is the brand on the front. That layering is the whole reason this integration is interesting. There is a worker-side data plane (tip payouts per shift, on-demand pay advances, the program's eligibility rules) that lives on the Branch side, and a banking-side data plane (Mastercard debit authorizations, posted transactions, the account balance) that lives on the Evolve side. A useful pull reads both and joins them.
Per the Branch disclosure for this program, qualifying USHG employees can have 51% of their tip payouts automatically routed into the wallet as soon as they are available, and can advance up to 51% of earnings from non-tipped shifts, capped at $1,000 per pay period. That cap is one of the integration constants — it shapes the available-advance figure your client computes, the disclosures you have to surface, and the way reconciliation lines up against payroll.
Two data planes, two routes
The wallet is a single app to a worker, but to an integrator it is two systems with different access models. We work them separately and stitch the result.
Route A — Consumer-permissioned aggregation of the Evolve account
Card transactions, posted balance, account and routing details all sit on the bank side. Where the worker consents through an aggregator that supports Evolve, this is the cleanest path for the funds view: transactions normalize cleanly, the balance is current, and revocation is a single switch. The trade-off is that the aggregator's lens does not see anything that has not yet hit the bank — a tip payout queued on Branch for tomorrow morning is invisible until it settles.
Route B — Authorized protocol analysis of the USHG Digital Wallet app
For the surfaces a worker sees but the bank account does not — pending tip payouts, advance eligibility, the 51% rule applied to today's shift, in-app program messages — we reverse-engineer the mobile app's traffic against a consenting test account that the engagement is built around. The deliverable is the documented protocol (login, token refresh, the worker endpoints) plus runnable code. Maintenance is heavier than Route A; the wallet's front end changes from time to time and a small re-validation pass is part of how we look after the build.
Route C — Bilateral data-sharing where USHG or Branch are themselves the integrator
If USHG itself, or one of its existing technology partners, is the party paying for the integration, the cleanest path is a bilateral data agreement between the organization and the integrator under their existing contractual relationship, with us doing the engineering on top. Roster, eligibility flags and program parameters move that way; the worker-data planes still need worker consent.
For most third-party callers on this app, the build is Route A for the bank side and Route B for the worker-tip side, fronted by one unified schema. We will say so plainly in the proposal.
What sits behind a worker's wallet
| Domain | Lives on | Granularity | What a caller does with it |
|---|---|---|---|
| Tip payouts | Branch worker ledger | Per-shift line item with role and timestamp | Sync to accounting; feed daily-tip dashboards; reconcile against POS tip-out |
| On-demand pay advances | Branch worker ledger | Advance amount, source shift, repayment schedule | Reconcile against the next payroll run; surface the available-to-draw figure in budgeting tools |
| Mastercard transactions | Evolve account | Per-authorization, with merchant + MCC | Categorize spend; show in third-party PFM apps; flag duplicates |
| Account balance | Evolve account | Current and available, with pending-hold delta | Real-time display; pre-draw checks before initiating an EWA request |
| Eligibility & opt-in | Branch worker ledger | Per-employee opt-in flags, plan tier | Drive employer-side benefits dashboards; surface enrollment status |
| Program parameters | USHG plan config inside Branch | Per-employer (51% cap, $1,000 ceiling, eligible roles) | Apply correct disclosures and offline rule checks |
Worker identity, contact details and tax information also sit behind the wallet, but they are not headline integration data and we keep them out of the default schema. They come in only when a specific downstream system (a tax form generator, a payroll partner) actually needs them.
A wallet-create call and a pull
The snippets below sketch the two ends of the integration. The wallet-claim flow on the Branch side is the worker-onboarding handshake; the transactions pull is what a consented worker-side caller looks like. Field names and shapes are confirmed during the build against a sponsor sandbox or a consenting test account.
// Worker-onboarding handshake (Branch side, illustrative)
POST /v3/organizations/{org_id}/wallets
Authorization: Bearer ${BRANCH_ORG_KEY}
Content-Type: application/json
{
"external_id": "ushg-emp-2031",
"first_name": "...",
"last_name": "...",
"email": "...",
"phone": "...",
"program_code": "USHG_DIGITAL_WALLET"
}
// 201 Created
{
"wallet_id": "wlt_8f3...",
"status": "PENDING_CLAIM",
"onboarding_url": "https://my.branchapp.com/claim/...",
"expires_at": "2026-06-05T17:00:00Z"
}
// Webhook fired when the worker finishes the claim flow
POST /your-callback
X-Branch-Signature: t=...,v1=...
{
"event": "WALLET_CLAIMED",
"wallet_id": "wlt_8f3...",
"claimed_at":"2026-05-29T18:42:11Z"
}
// Worker-consented transactions pull (joined view, illustrative)
GET /v1/workers/{wallet_id}/activity?since=2026-05-01&kinds=tip,advance,card
Authorization: Bearer ${WORKER_CONSENT_TOKEN}
// 200 OK
[
{ "kind":"tip", "posted_at":"2026-05-28T03:11:00Z",
"shift_id":"sh_771", "role":"server",
"gross_cents": 5400, "share_pct": 51, "net_cents": 2754 },
{ "kind":"advance", "requested_at":"2026-05-28T16:02:00Z",
"from_shift":"sh_772", "amount_cents": 8000,
"cap_remaining_cents": 92000,
"repayment_run": "2026-06-06" },
{ "kind":"card", "authorized_at":"2026-05-29T11:14:00Z",
"amount_cents": -1875, "merchant":"GROCERY OUTLET",
"mcc": "5411", "status":"settled" }
]
// Errors are mapped to a single, app-aware envelope:
// 429 RATE_LIMITED — caller retries with backoff
// 409 CAP_EXCEEDED — request would breach the 51% / $1,000 rule
// 401 CONSENT_REVOKED — worker pulled consent; cache invalidated
// 503 SPONSOR_DEGRADED — Evolve side unavailable; tip-side still serves
What ends up in your repo
The deliverable is the integration, not a write-up. For an USHG Digital Wallet build the package is:
- An OpenAPI specification covering the joined surface (tips, advances, card activity, balance, eligibility), with the error envelope above and the field-level documentation that a downstream team will actually use.
- A protocol report describing the auth flow as it sits today on the Branch side and the wallet app side — token shape, refresh cadence, cookie or header binding where it applies, signature verification for the wallet-claimed webhook.
- Runnable source in Python and Node.js for the four endpoints most callers want first: wallet create, transactions pull, advance pre-check, and revocation. The repository builds and runs against a sandbox account or a consenting worker account out of the box.
- An automated test pack that covers the cap rule (51% / $1,000), the WALLET_CLAIMED webhook signature, transactions pagination, and the consent-revoked path.
- Interface documentation written for the engineer who will own this after you — sequence diagrams for onboarding and for an EWA draw, a state table for opt-in flags, and a short operations note covering log retention and what to rotate when.
- A compliance-and-retention note: what we cache, for how long, and what gets purged when a worker revokes consent. Designed for the auditor reading it cold.
Notes we hold ourselves to on this build
Each USHG Digital Wallet build has a handful of specific judgments we make up front, before the first line of code, so they do not surface as surprises during integration testing.
Two data planes, one façade. We always front the Branch worker layer and the Evolve bank layer behind a single schema with a clear source field on every row. That keeps a downstream report from quietly double-counting a tip that has been disbursed on Branch but not yet settled on the Evolve account.
The 51% / $1,000 rule applied client-side as a soft check, server-side as truth. We mirror the program cap in your client so the available-advance figure can be computed without a round trip, and we always re-verify against the server before initiating a draw. The rule is described in the USHG program disclosure and is treated as a USHG plan parameter, not as a constant — if USHG ever revises the plan, the integration follows.
State-of-shift tagging on every record. State EWA statutes vary across the jurisdictions USHG operates in, and the disclosure / fee model that applies to an advance depends on where the shift was worked. Every advance row carries the work-state so your application can apply the right rule without re-querying.
Re-validation built into the maintenance contract. The wallet app's front end changes on its own cadence, and Route B is the side that feels it first. We schedule a quiet re-check against a consenting test account on a monthly cadence and patch the parser in place — the integration does not silently rot.
Access onboarding is part of the engagement, not a precondition. Branch sandbox keys, a consenting USHG worker account for testing, and the data-sharing paperwork between USHG and the integrator are arranged with you during the first days of the engagement. The brief never starts with a list of things you must produce first.
EWA, state law, and consent
The regulatory frame for this app has shifted recently and the shifts matter for the integration. In December 2025 the CFPB issued an advisory opinion clarifying that employer-partnered EWA products meeting a defined set of criteria — access only to wages already earned, no underwriting, no withdrawal from the worker's personal account — are not credit under the Truth in Lending Act. That guidance applies to the on-demand pay surface of USHG Digital Wallet on its face, and it is the right anchor for the disclosures your integration produces around an advance.
State legislation is the other moving piece. Kansas, Missouri, Nevada, South Carolina and Wisconsin have already enacted EWA-specific statutes, and roughly sixteen further states had bills in motion through 2025. Because USHG is a national hospitality group, an integration that surfaces advances has to be state-aware: we tag each advance with the worker's work-state and let your downstream apply the local rule.
The dependable basis for accessing a worker's wallet data is the worker's own consent — a scoped, time-bound, revocable grant that names the specific domains being read and the retention applied. We document the grant alongside the integration, and the per-worker revocation switch is wired through so a withdrawal invalidates every cached row the integration touched. Sponsor-bank posture is not separable from this app's story: the 2024 incident at the sponsor bank is part of why our default is to cache less, scope tokens narrowly, and treat the per-worker revocation switch as a first-class API path rather than an admin chore.
Price and cycle
One to two weeks is the working cycle for an USHG Digital Wallet integration, measured from kickoff to a build that runs end-to-end against a real account. Source-code delivery starts at $300; the source, tests and the interface document come back to you and the invoice is settled after delivery, once you are satisfied with what was shipped. If you would rather not host anything, the same integration is available as a pay-per-call hosted API — you call our endpoints, you pay only for calls made, and there is no upfront fee.
The way an engagement begins is light. You send the app name, the surfaces you want covered, and a sentence on the downstream system. Access, sandbox arrangements, NDAs where they apply, and worker-consent paperwork are all handled on our side as the first sub-task of the build. Routing for a scoped quote sits at /contact.html.
Common integration shapes
Three end-to-end patterns absorb most of what callers ask for on this app.
1. Financial-wellness app pulling tips and advances
A worker connects USHG Digital Wallet from inside a third-party financial-wellness app. Our integration handles consent, fetches the joined activity feed once per session and on a webhook, applies the 51% rule client-side as a soft check, and returns a clean "available to advance" figure. Card transactions ride alongside through Route A.
2. Accounting sync for the restaurant operator
USHG itself, or a finance team inside one of its restaurants, wants tip payouts and per-shift advance data flowing into accounting. Route C runs the data plane on the strength of USHG's existing relationship with Branch; we build the connector, the per-restaurant cost-center mapping and the reconciliation against POS tip-out. No worker-side consent is required because the data is being read at the organization level under that data-sharing arrangement.
3. Switch-friendly view for the worker leaving USHG
A worker who is changing jobs wants a portable export of historical tip payouts, advances and card history. Routes A and B both run; the deliverable is a structured archive plus a short PDF the worker can hand to a credit-builder, a budgeter or a tax preparer. Consent is the worker's own and the archive is theirs to keep.
Adjacent worker-payments apps a unified pull touches
USHG Digital Wallet is one entry in a wide set of employer-issued wage apps. A unified pull on this category often has to handle several of them side by side, so the shape of the integration here usually carries over. Eight worth naming, neutrally:
- DailyPay — On-demand pay platform widely deployed in hospitality and retail; holds per-shift earnings data and advance history per employee.
- Payactiv — Earned wage access provider with a prepaid card, bill pay and financial-wellness tools layered on the same per-worker ledger.
- Tapcheck — EWA platform focused on small and mid-market employers; surfaces accrued-wages and advance-eligibility data per shift.
- EarnIn — Direct-to-consumer pay-access service; holds earnings estimates derived from time-tracking and bank-account signal.
- ZayZoon — Financial-empowerment platform aimed at small and mid-size businesses; holds wage advance history and gift-card disbursement data.
- Rain — Earned wage access provider that pairs the advance ledger with budgeting and financial-coaching surfaces.
- Clair — Embedded earned-wage-access provider that sits inside human-capital-management and workforce-management apps.
- Keeper — EWA service that ledgers accrued wages and disbursements for partner employers.
Sources read for this brief
The brief was assembled against the in-app description, the disclosures Branch publishes for USHG Digital Wallet, Branch's own product pages, the CFPB's December 2025 EWA advisory, and the public record around the 2024 Evolve cybersecurity incident. Four deep links we relied on most:
- Branch — What is USHG Digital Wallet (legal disclosure)
- Branch — USHG case study
- Federal Register — CFPB EWA / Reg Z advisory, 23 December 2025
- Evolve Bank & Trust — Cybersecurity incident page
Reviewed by the OpenBanking Studio integration desk, 29 May 2026.
Questions we have heard on this one
Where does the tip ledger actually sit — Branch's worker ledger or the Evolve account?
Tip payouts post first on Branch's worker ledger as per-shift line items, then settle into the Evolve-issued account as credits. For shift-level detail (per pay period, per role) the Branch side is the truth; for the funds view (cleared, available balance) the Evolve side is. A useful integration pulls both and joins them on shift and posting date.
Is the 51% advance cap a server-side rule, or do we have to apply it ourselves?
The cap is a USHG plan parameter Branch holds and enforces — the program is described as up to 51% of earnings per shift, capped at $1,000 per pay period, per the app's own disclosure. We mirror that rule in your client so the available-advance figure can be computed offline, and we verify against the server before any draw is requested.
Can we reach the Mastercard debit transactions without consent from each worker?
No. Card transactions live on the Evolve-issued account side and are tied to the individual worker's account. Reaching them needs that worker's consent, either through an aggregator that supports Evolve or through the consent flow we build with you. Aggregate-by-employer with no worker consent is not an authorized route and we will not deliver it.
Does the 2024 Evolve cybersecurity incident change how we should handle this data?
It changes posture, not capability. We minimize PII at rest, scope each token to the smallest data domain it actually needs, and put a per-worker revocation switch in front of every cached row. The integration runs against current Evolve infrastructure, and our reference build assumes that the next incident could happen to any sponsor bank — not just this one.
App profile — USHG Digital Wallet, at a glance
USHG Digital Wallet, powered by Branch, is a digital bank account and Mastercard debit card issued by Evolve Bank & Trust for qualifying employees of Union Square Hospitality Group. The program automatically routes 51% of tip payouts to the wallet as soon as they are available and lets qualifying employees advance up to 51% of earnings from non-tipped shifts, capped at $1,000 per pay period — per the program's own disclosure. The account carries no minimum balance, credit check or overdraft fee. The Android package identifier is com.branchapp.ushgwallet.