What an integrator can reach inside MyTime Wallet

Unified Signal's MyTime Wallet stitches a prepaid Mastercard, a worldwide person-to-person money rail, a crypto and precious-metals desk, and a cash-back marketplace into a single consumer login. That breadth is the point for anyone integrating it: one authenticated session sits in front of several distinct ledgers, and a team that wants any one of them — say outbound transfers for reconciliation, or crypto holdings for a net-worth view — has to read the same session the app's own client uses. The route we take is authorized, consent-based integration: we work with the account holder's permission, watch how the app talks to its backend, and turn the parts you need into something you can call.

What MyTime keeps behind a login

The surfaces below come from the app's own description and store listings. Each is a place a value lives inside the product, named the way MyTime presents it where we could.

Two of those rows do most of the work in practice. The wallet balance and the linked-card balance look like one pot of money to the user but are separate ledgers underneath, and the marketplace records a 15% to 40% cash-back accrual the app advertises — a number worth capturing as its own field rather than folding into an order total.

Getting at it: the routes that apply

Three routes fit a wallet shaped like this. We pick based on what you need and how durable it has to be.

Consented session integration with protocol analysis

With the account holder's authorization, we observe the app's own traffic — login, token issuance, the balance and history calls — and rebuild the ones you need as clean endpoints. This reaches everything the user can see in the app, which here means all seven domains above. Effort is moderate; durability depends on how often MyTime reshapes its front end, which we account for in maintenance. This is the route we'd lead with, because it's the only one that reaches the crypto desk and marketplace records together rather than just the card.

User-consented credential access

Where a hosted, always-on connection is wanted, the account holder grants access and we run the session on their behalf, refreshing tokens and normalizing the output. Same reach as above; the difference is we operate it continuously instead of handing you the client.

Native handoff as a fallback

Anything the app or its statements let a user export goes in as a fallback for the card-transaction side. It's the most durable but the narrowest — it won't carry the live wallet balance or crypto positions — so we treat it as a backstop, not the main feed.

The build you receive

You give us the app name and the data you're after. We hand back a working integration scoped to MyTime's actual surfaces:

• An OpenAPI/Swagger specification for the endpoints we expose — wallet balance, card transactions, transfer history, crypto holdings, whichever you need.
• A protocol and auth-flow report covering the login, OTP step, and bearer-token refresh chain as it behaves in this app.
• Runnable source for the key calls in Python or Node.js, not pseudocode — the same requests the client makes, cleaned up and documented.
• An automated test suite that exercises the live surfaces and flags when a response shape shifts.
• Interface documentation a back-end engineer can read without us in the room.
• Compliance and data-retention notes: what's logged, what's minimized, how consent is recorded and revoked.

A look at the token-and-balance call

The shapes below are illustrative — field names and the auth chain get confirmed during the build, not lifted from any vendor document. They show the pattern we'd wrap: a short-lived session token, then a balance read keyed by wallet id.

POST /m/session/login
  { "username": "...", "device_id": "...", "otp": "123456" }
  -> 200 { "access_token": "...", "wallet_id": "w_88f2", "expires_in": 1800 }

GET /m/wallet/{wallet_id}/balance
  Authorization: Bearer <access_token>
  -> 200 {
       "available": "182.40",
       "currency": "USD",
       "card_linked": true,
       "card_balance": "20.00",
       "pending": "0.00"
     }

# Token TTL is short. The client refreshes before expiry instead of
# re-prompting for a one-time code on every poll. The wallet and the
# linked card report as separate figures, so we keep them as two fields.

Where teams plug this in

A few shapes we see for a wallet like this:

• An aggregator surfacing a MyTime balance next to a user's other accounts in one dashboard.
• A remittance-compliance tool reconciling outbound P2P transfers against its own records.
• A personal-finance app folding the crypto and metals holdings into a net-worth total.
• An accounting export that pulls marketplace orders and the cash-back accrual for bookkeeping.

Authorization and the US data-rights footing

Because MyTime is a US consumer wallet run by Unified Signal, the dependable basis for reaching it is the account holder's own authorization to access and share their data — granted explicitly, logged, and revocable. We hold consent records, sign an NDA where the engagement needs one, and minimize what we pull to the fields you actually use.

The CFPB's Personal Financial Data Rights rule under Section 1033 is the forward-looking piece here, not today's law. As originally drafted it phased obligations in by institution size, but it's currently enjoined and back in agency reconsideration, so a small program like this one isn't something we build against as a live requirement. Where the rule lands may eventually shape how a wallet like MyTime exposes data; until then, consent is what the integration rides on.

Engineering details we handle

Two things about this app change how we build, and we take care of both rather than passing them to you:

• The wallet-to-card instant move means money shifts between two ledgers in real time. We model them as distinct accounts and capture the move as its own event, so a balance read taken mid-transfer doesn't count the same dollars twice.
• The crypto and metals desk prices in real time. We separate a trade event and its execution quote from the cash balance, so a fluctuating spot price never leaks into the available-funds figure your app shows.
• Field mappings get a re-validation pass in maintenance, since the app's front end can shift between releases and a renamed response key shouldn't quietly break a sync.

Access to a consenting account or a test environment is arranged with you during onboarding — it's part of how the project runs, handled together, not something to sort out before we'll start.

Working with us, and what it costs

A runnable build of the MyTime endpoints you need lands in one to two weeks. From there you have a choice. Take it as source code you own and host — from $300, invoiced only after delivery once it's working the way you wanted — or skip hosting entirely and call our endpoints, paying per call with nothing up front. Either way the spec, tests, and docs come with it. If you want to talk through which fits, tell us the app and what you need from its data and we'll scope it back to you.

Screens from the app

Sources and check date

This brief draws on MyTime's own marketing site and store listings plus Unified Signal's mobile-wallet material, with the US data-rights status taken from the CFPB's own reconsideration page. Surfaces named here come from those public descriptions; endpoint shapes are confirmed only during a build. Sources opened: mytimeservices.com, the App Store listing, Unified Signal's mobile-wallet page, and the CFPB Section 1033 reconsideration notice.

Mapped by the OpenBanking Studio integration desk, June 2026.

Other apps in the same wallet space

Same neighbourhood — US neobanks, prepaid wallets, and hybrid fiat-plus-crypto apps. A unified integration usually wants several of these read the same way.

• Chime — fee-light spending and savings accounts with a debit card and direct-deposit data.
• Current — checking with savings pods and in-app crypto buy and sell.
• Varo — a chartered neobank holding deposit, card, and cash-advance records.
• Revolut — multi-currency balances, card spend, transfers, and crypto in one app.
• Cash App — P2P transfers, a Cash Card, plus stock and bitcoin holdings.
• Netspend — prepaid debit accounts with reload and transaction history.
• BOSS Revolution — international remittance and bill-pay records aimed at cross-border senders.
• Bluebird by American Express — a prepaid account with bill pay and family sub-accounts.

Questions integrators ask about MyTime

Can you read the wallet balance separately from the linked Mastercard balance?

Yes. MyTime keeps two ledgers — the Mobile Wallet Account and the linked MyTime Debit Mastercard — and money moves between them in real time. We model them as distinct accounts so a balance read doesn't double-count funds mid-transfer, and we capture the move itself as its own event.

Does the crypto and gold and silver activity come through the same integration?

It can. The buy, sell and hold activity for crypto and precious metals sits behind the same authenticated session as the cash wallet. We capture holdings plus each trade event and the quote at execution, kept apart from the cash balances so real-time pricing doesn't bleed into your available-funds number.

What is the authorized basis for reaching a US wallet like MyTime in 2026?

The dependable basis is the account holder's own authorization to access and share their data. The CFPB's Personal Financial Data Rights rule under Section 1033 is currently enjoined and back in agency reconsideration, so we don't build to it as live law; consumer consent, logged and revocable, is what the integration rides on.

How do you keep a sync alive given MyTime's short session tokens?

The access token we observe during the build has a short lifetime, so the client refreshes ahead of expiry instead of re-prompting for a one-time code on every poll. We design the sync schedule around that window so a consented pull re-authenticates cleanly rather than silently dropping.