Reaching a BOSS Money sender's transfer and recipient records

Every completed transfer in BOSS Money lands on a screen the app calls YourActivity, stamped with a status, the amount sent, the fee, and the exchange rate the sender locked. That feed, the recipient book sitting beside it, and the separate mobile top-up history are the three things a partner usually wants to pull. BOSS Money is the consumer brand of BOSS Revolution Money, the remittance product from IDT; per its Google Play listing it serves senders in the United States out to roughly 49 receiving countries, with cash pickup, bank deposit, mobile wallet, debit-card and (in a few corridors) home delivery as payout choices. We do authorized integration work against exactly that surface and hand back source you can run.

The short version: a sender's own history is structured, consistent, and worth syncing, but it is split across products — a cross-border remittance and a $5 airtime recharge sit in the same list. The route we run is protocol analysis of the authenticated app traffic, carried out under the account holder's authorization, with a consented sign-in flow doing the credential handling. That gives a partner the activity feed, recipients, live payout status and the top-up ledger as clean, typed collections.

What the account actually exposes

These are the surfaces a sender sees once signed in, named the way the app presents them where we could confirm it.

How we reach it

Two routes carry the weight here, with a third that matters only for the funding side.

Protocol analysis of the authenticated session

We observe the app's own traffic against a consenting account, map the request and response shapes behind YourActivity, the recipient book, the quote step and the top-up catalog, then reimplement those calls in a small client. Reachable: essentially everything the signed-in sender can see. Effort is moderate and front-loaded into the mapping. Durability is good between releases but the app does ship updates, so we account for that in maintenance. Onboarding here is something we arrange with you — a consenting account or a test profile is set up together at the start of the build.

Consented sign-in for the credential chain

Layered on top, a user-consented login handles the token or session the app issues, so the integration acts strictly as the account holder, on records that belong to that person. This is the piece that keeps the work authorized and auditable, and it is how a multi-user product would onboard each of its own users.

Consumer-permissioned bank link for the funding leg

When a transfer is funded from a linked bank account, the source-of-funds side can be corroborated through a consumer-permissioned bank-data connection rather than scraped from BOSS Money itself. Narrow in scope, useful only when reconciliation needs the ACH origin.

For most partners we build on the first route and wrap it in the consented sign-in, because that combination returns the full picture a sender sees while keeping every read tied to a real authorization. The bank link is added only when the funding origin has to be matched.

What lands in your repo

Each item is shaped around the surfaces above, not a generic checklist.

• An OpenAPI description covering the activity feed, recipient reads, quote lookups and the top-up history, with the request and response fields we confirmed during the build.
• A protocol and auth-flow write-up: how sign-in issues its token, how the session is carried, refresh behaviour, and the error and retry shapes the app returns.
• Runnable source for the core reads — Python or Node.js, your pick — including a normalizer that splits remittances from airtime and types payout status per delivery method.
• Automated tests against recorded fixtures so a later app update shows up as a red test, not a silent data gap.
• Interface documentation a developer can follow, plus guidance on retention and data minimization given the regulated nature of the underlying service.

A representative call

Illustrative only — field names and the auth header shape are confirmed and pinned during the engagement, not guessed from the outside.

# Pull a page of the sender's activity, then normalize by product type
GET /money/v1/activity?cursor=&limit=25
Authorization: Bearer <session-token from consented sign-in>
Accept: application/json

# Illustrative response shape
{
  "items": [
    {
      "id": "txn_9f2c...",
      "type": "remittance",          # vs. "topup"
      "status": "SENT",              # SENT | IN_REVIEW | READY_FOR_PICKUP | PAID | CANCELLED
      "send": { "amount": "200.00", "currency": "USD", "fee": "1.99" },
      "fx":   { "rate": "17.42", "payoutCurrency": "MXN" },
      "payout": { "method": "CASH_PICKUP", "country": "MX" },
      "recipientId": "rcp_4a1d..."
    }
  ],
  "nextCursor": "eyJvZmZzZXQ..."
}

# Client-side: branch status by payout method, since the lifecycle differs
def settled(item):
    method = item["payout"]["method"]
    if method == "BANK_DEPOSIT":
        return item["status"] == "PAID"
    if method == "CASH_PICKUP":
        return item["status"] in ("READY_FOR_PICKUP", "PAID")
    return item["status"] == "SENT"
      

Things we plan around

Two specifics shape how we build this one.

One feed, two products. BOSS Money is more than a remittance app — it also recharges 300-plus carriers across 100-plus countries, per its listing, and both flows surface in the same activity history. We tag each record by product type during normalization and expose remittances and top-ups as separate collections, so a reconciliation system never counts an airtime recharge as a cross-border send.

Status means different things per payout method. A bank deposit, a cash pickup and a home delivery do not share a lifecycle, and home delivery only exists in a handful of corridors. We model the status sequence per delivery type so a sync reports the true delivery state instead of collapsing everything to one flag. We also wire the read client to re-check field shapes when the app updates, so a release that moves a field is caught in maintenance rather than in production. Access to a consenting account or a test profile is arranged with you during onboarding; the build runs against that.

Consent and the regulated backdrop

The money transfer service is operated by IDT Payment Services, a licensed US money transmitter and a FinCEN-registered money services business; its money terms page lists NMLS 935577. Each transfer also carries Regulation E remittance disclosures — the receipt, the rate, and a short cancellation window — which is settled, in-force US law for cross-border consumer transfers and is the regime that genuinely applies here. The dependable basis for our integration is simpler than any of that: the account holder's own authorization to access their own records. We keep reads scoped to that consent, log them, minimize what is retained, and sign an NDA where the work touches anything sensitive. As for where US data-access rules may go next, the CFPB's Personal Financial Data Rights rule under Section 1033 is the forward-looking piece — it is not in force, with enforcement enjoined and the rule back in agency reconsideration — so we treat it as a direction of travel, not a framework to build on today. Consent stays the foundation.

Cost and how it runs

The activity feed, recipient reads and the top-up split are the deliverable, and there are two ways to pay for it. Source-code delivery starts at $300: you get the runnable client, the spec, the tests and the docs, and you pay after delivery once it works for you. Or skip the build and use our hosted endpoints on a pay-per-call basis, with no upfront fee. Either way the cycle is one to two weeks. Tell us the app name and what you need from its data — start the conversation here and we handle access and the compliance paperwork with you from there.

Keeping it current

Remittance status is time-sensitive, so a stale sync is worse than no sync. The activity reads are built to poll on a cadence you set and to react to the app's own status changes, and the test fixtures double as a tripwire: when BOSS Money ships an update that shifts a field or a status value, the suite fails and we patch the client. That maintenance loop is part of how the integration is meant to be operated, not an afterthought.

Interface evidence

Store screenshots of the surfaces described above. Select to enlarge.

Where it sits among its peers

Other US-facing remittance and top-up apps hold comparable per-sender records; naming them helps frame what a unified, multi-provider integration would cover.

• Remitly — bank deposit, cash pickup and mobile-money transfers with detailed per-transfer tracking.
• Xoom (PayPal) — cross-border transfers, debit-card and wallet payouts, and bill pay tied to a PayPal account.
• WorldRemit — transfers to 130-plus countries with cash pickup, bank transfer, mobile money and airtime in one history.
• Wise — multi-currency balances and transfers at the mid-market rate, with rich statement data.
• Sendwave — fee-light transfers focused on African and Asian corridors, with a simple activity log.
• Ria Money Transfer — a large cash-pickup network and bank deposits, strong on Mexico, India and the Philippines.
• Western Union — broad cash-pickup reach plus app-based transfers and a transaction history.
• Ding — mobile top-up and airtime across many carriers, overlapping the recharge side of BOSS Money.

Questions integrators ask

Which BOSS Money screens hold the data worth syncing?

The YourActivity screen carries the sender's transfer records with status, amount, fee and exchange rate; the recipient book holds beneficiaries and their payout method; and the top-up history holds carrier, country and package. Those three are the surfaces we map first.

Can you separate remittance transfers from mobile top-up records?

Yes. BOSS Money mixes both in one activity feed, so we tag each record by product type during normalization and expose them as distinct collections so a reconciliation system never treats an airtime recharge as a cross-border transfer.

How is payout status tracked when delivery methods differ by country?

Bank deposit, cash pickup, mobile wallet, debit-card and home delivery each move through different state sequences, and home delivery is limited to specific corridors. We model the status lifecycle per payout method so a sync reflects the real delivery state rather than a single generic flag.

Who is the regulated servicer behind BOSS Money and does it affect access?

The money transfer service is operated by IDT Payment Services, a licensed US money transmitter and FinCEN-registered MSB, with Regulation E remittance disclosures attached to each transfer. We keep the integration consumer-authorized and data-minimized so it sits cleanly alongside that regulated activity.

Sources and review

Checked in June 2026 against the app's own listing and BOSS Revolution's published terms and help pages. Primary sources opened: the Google Play listing for features, markets and top-up reach; the BOSS Money app FAQ for the YourActivity flow, recipients and payout options; and the BOSS Money licensing and terms page for the IDT Payment Services money-transmitter detail. Where a figure was not confirmable it is attributed or left out rather than asserted.

Mapping by the OpenBanking Studio integration desk · June 2026.