Syncing the Uber Pro Card's driver-pay ledger in Canada

Every completed trip or delivery pushes a driver's Uber earnings onto the card automatically, so the account behind it carries a running, per-event record of payouts rather than a single end-of-week deposit. That cadence is the whole reason an integrator looks at this card: the data is fresh by the minute, it ties an identifiable person to a Mastercard ledger, and it mixes income with spend. The card is program-managed by Payfare and issued by Peoples Trust Company, a CDIC member institution, per the Peoples Group announcement. What follows maps what that account holds, the authorized way to reach it for a third party, and what we hand over at the end.

What sits behind a driver's Uber Pro Card account

These are the surfaces the app exposes to its own user. Each maps to a structured record on the backend that a consented integration can read.

Authorized routes into the cardholder ledger

Three routes genuinely apply to this card. We set up access with the client during onboarding — a consenting cardholder session, the app credentials they authorize us to use, and an NDA where the work touches anything sensitive.

1 · Consent-based interface integration

We analyze the Payfare-built app's own traffic under the cardholder's authorization and rebuild the calls it makes — token acquisition, balance, transaction pages, the rewards ledger. This reaches everything the driver can see in the app. It is the most complete route and the one available today. Durability is moderate: app updates and the Fiserv platform move things, so the client is written to absorb that.

2 · Consumer-driven banking consent (forward-looking)

Canada's Consumer-Driven Banking Act sets up a statutory, consent-based data-sharing channel overseen by the Bank of Canada. Once the read-access phase is operational, an accredited participant could pull account and transaction data through it with the cardholder's permission and a cleaner revocation model. It is not live yet, so we treat it as the path the integration grows into, not the one it ships on.

3 · Native statement export

The app surfaces transaction history a cardholder can export. Lower effort, lower fidelity — good for seeding history and for periodic reconciliation, weak for real-time payout events. We wire it as a backfill alongside route 1.

For this card the recommendation is concrete: build on route 1 now, because the per-trip payout stream is the asset and the statutory channel is not yet switched on, and fold route 3 in to recover the months of history a live session alone will not show. Route 2 is the upgrade we design toward once the framework opens.

A transaction-pull sketch

Illustrative shapes for the cardholder endpoints, confirmed against a consenting session during the build rather than guessed at. Payouts arrive as credit events distinct from purchase debits, which is what lets the income and spend views stay separate.

# Run against a consented cardholder session; tokens are never hardcoded.

POST /auth/token                 # device-bound session, OAuth2 refresh grant
  -> { access_token, refresh_token, expires_in }

GET /v1/account/balance
  Authorization: Bearer <access_token>
  -> { available, backup_balance, currency: "CAD", as_of }

GET /v1/transactions?since=2026-05-01&cursor=...
  -> { items: [ { id, posted_at, amount, currency,
                  merchant, mcc,
                  type,          # cashout | purchase | atm
                  status } ],    # pending | settled
       next_cursor }

GET /v1/rewards/cashback
  -> { tier, period, accrued, monthly_cap, redeemable }

# Error handling we build in: 401 -> silent refresh then one retry;
# cursor gaps -> re-page from last settled id; pending rows are
# reconciled on the next sync when they settle.
      

What lands in your repo

The deliverable is a working integration for this specific card, not a report about one. A typical handover includes:

• An OpenAPI/Swagger spec covering the balance, transactions, payouts and rewards endpoints as they behave for a real account.
• A protocol and auth-flow write-up: the token grant, refresh chain and any session-cookie handling for the Payfare backend.
• Runnable source — Python or Node.js — for the key reads, with pagination and token refresh handled, not stubbed.
• Automated tests that exercise pending-to-settled transitions, cursor gaps, and the monthly cash-back cap.
• Interface documentation a new engineer can follow, plus data-retention and minimization guidance pitched at PIPEDA.

If you take the hosted option instead, the same surfaces come back as normalized JSON from our endpoint and you skip the build entirely.

Where integrators put this data to work

• Income verification for a lender or rental check, reading verified per-trip cashouts straight from the card.
• Bookkeeping and tax tools that auto-split Uber income from gas, EV charging and other spend by MCC.
• A fleet or driver dashboard that watches balance and Backup Balance and nudges before a shortfall.
• Rewards tracking that models the tier rate and the $100 monthly cap so a driver knows what is still redeemable.

Consent and the Canadian data-rights picture

This is a Canadian financial account, so two regimes matter. Personal data is governed by PIPEDA, which sets the consent and access expectations we work within. The forward piece is the Consumer-Driven Banking Act: oversight has been assigned to the Bank of Canada rather than the FCAC, and the Department of Finance's framework describes a read-access first phase with write-access targeted later. That statutory channel is not operational yet, so we do not lean on it as today's basis — the dependable footing is the cardholder's own authorization to access their account.

In practice that means scoped consent recorded in writing, an access window the cardholder can revoke, data pulled down to only the fields a use case needs, and a logged trail of every read. Funds on the card sit with Peoples Trust under CDIC coverage, which matters for anyone storing balance data: it is deposit information, and we treat it as such.

Engineering realities we plan around

A few things about this card shape the build, and we account for each rather than handing them back as conditions:

• Platform in motion. Payfare's program is moving under Fiserv after the 2025 acquisition. We build the client to tolerate host and endpoint changes and re-verify the captured traffic when the app updates, so a migration does not quietly break the feed.
• Tier-dependent reward math. Gas and EV cash-back rates change with the driver's Uber Pro status and cap at $100 a month. We model the tier-to-rate mapping and the cap so two drivers on different tiers reconcile correctly against the same logic.
• Pending versus settled. Rewards become redeemable as purchases settle, and a payout can show before it clears. We design the sync to carry pending rows and reconcile them on the next pass instead of double-counting.

Pricing and how an engagement runs

A runnable Uber Pro Card client — auth flow documented, tests green, history backfilled — is what the first engagement produces. Take it as source-code delivery from $300: you receive the runnable source and the docs, and you pay after delivery once it works for you. Or take the pay-per-call hosted API: we host the endpoints, you call them and pay only for the calls you make, with no upfront fee. Either way the cycle is one to two weeks. Tell us the card and what you want out of its data, and we arrange the access and compliance pieces with you — start at /contact.html.

App screens

Screens from the published listing, for surface reference. Select one to enlarge.

Neighbouring gig-pay and Canadian neobank apps

Cards and wallets that sit near this one, useful when a project wants one normalized view across several driver or spending accounts:

• DasherDirect — DoorDash's driver debit card, also built on Payfare, holding instant deposits and gas cash back.
• Lyft Direct — Lyft's instant-pay debit account, another Payfare-managed gig ledger of earnings and spend.
• Branch — a gig-worker wallet and instant-pay account that now powers the US Uber Pro Card.
• Moves Financial — a banking app aimed at gig workers, tracking earnings across platforms with cash-advance features.
• KOHO — a Canadian prepaid spending account with transaction history and round-up savings.
• Neo Financial — a Canadian neobank issuing a prepaid Mastercard with spend and rewards records.
• Wealthsimple Cash — a Canadian spending and peer-transfer account with its own transaction ledger.
• EQ Bank — a Canadian digital bank holding deposit, savings and payment data behind a login.

Questions integrators ask about this card

Does Canada's consumer-driven banking framework already cover the Uber Pro Card?

Not yet in an operational sense. The Consumer-Driven Banking Act has moved through Parliament with oversight assigned to the Bank of Canada rather than the FCAC, and a read-access first phase is the near-term step while broader write-access is targeted later. Until that is live, the dependable basis we build on is the cardholder's own authorization, not the statutory data-sharing channel.

Can you separate Uber earnings cashouts from card spending in the same feed?

Yes. Automatic cashouts after each trip arrive as credit events on the card ledger, while purchases at the pump, at merchants or at ATMs are debit authorizations on the Mastercard rail. We tag the two as distinct transaction types so income reconciliation and spend analytics do not bleed into each other.

How is the gas and EV cash-back math handled when the rate depends on Uber Pro status?

Cash-back rates scale with the driver's Uber Pro tier and, per Mastercard's launch newsroom, refuelling rewards cap at $100 per month. We model the tier-to-rate mapping and the monthly cap, and we treat accruals as pending until the underlying purchase settles, which is when the reward becomes redeemable.

Does Fiserv's purchase of Payfare change how the integration is built?

Payfare runs the card program and, per Payments Dive, Fiserv completed its acquisition of Payfare in 2025. That can move hosts and endpoints over time, so we build the client to tolerate those shifts and re-check the captured traffic whenever the app ships an update.

How this mapping was put together

Checked in June 2026 against the app's own Play description and the public record around the program: the launch announcement and its reward terms, the Canadian consumer-driven-banking framework materials, the issuer's CDIC status, and the news of Payfare's move under Fiserv. Primary sources opened:

• Mastercard newsroom — Uber Pro Card Canada launch and reward terms
• Department of Finance — Canada's framework for consumer-driven banking
• Peoples Group — CDIC eligibility for reloadable prepaid cards
• Payments Dive — Fiserv's acquisition of Payfare

Mapped by the OpenBanking Studio integration desk · June 2026.