Reaching the transfer records behind Western Union Send Money

Records this app keeps for each sender

Every transfer in this app carries a ten-digit Money Transfer Control Number, and that number is the spine of everything an integrator wants out of it. Western Union exposes the MTCN in the confirmation email and inside the in-app transfer history, where it resolves to a live status — per its own MTCN documentation, the stages a sender sees move through in progress, available, paid, and on hold. Around that sit a saved-receiver list (the app calls it the resend list), a real-time exchange-rate widget with user-set rate alerts, recurring-transfer schedules, scanned card and bank funding instruments, and an agent-location directory for cash pickup. Where a sender also holds a WU+ digital banking wallet, there is a balance and a posted-transaction ledger behind the same login.

The table below maps each surface to where it originates in the app and what an integrator does with it. None of this is a public feed; all of it is per-user state behind an authenticated session, which is exactly the kind of data this work reaches.

The bottom line: the valuable records here are the transfer state machine and the receiver graph, and both sit in the app's own authenticated session rather than in any open-banking scope. We treat interface integration as the working spine and add the regulated account feed only for the wallet, where it genuinely applies.

Reading a transfer the way the app does

The core call an integration leans on is a status read keyed by MTCN against an authenticated session. The shape below is illustrative and gets confirmed against live traffic during the build; field names are normalised in the deliverable, not guessed at in the dark.

GET /v3/transfers/{mtcn}            # authenticated session, step-up may apply
Authorization: Bearer <session-token>
X-WU-Locale: pt_PT                  # pinned to the regional build

200 OK
{
  "mtcn": "1234567890",            # 10-digit, per WU MTCN docs
  "status": "available",           # in_progress | available | paid | on_hold
  "payoutType": "bank_account",    # bank_account | mobile_wallet | cash_pickup
  "sendCurrency": "EUR",
  "receiveCurrency": "INR",
  "fxRate": 92.41,                 # rate locked at send, not the live widget
  "sendAmount": 250.00,
  "receiver": { "ref": "rcv_8842", "name": "redacted" },
  "statusHistory": [ { "stage": "in_progress", "at": "..." },
                     { "stage": "available",   "at": "..." } ]
}

# 401 -> session expired or step-up (Face/Touch ID) required: re-auth, retry once
# 423 -> transfer on hold (compliance review): surface, do not poll aggressively

The status field is a state machine, not a flag, so a real integration models every stage and a held-transfer path rather than assuming success. The locked FX rate on a transfer is distinct from the live rate widget; conflating them is a common mistake we design out.

What lands at the end of the build

Output is concrete and tied to the surfaces above:

• An OpenAPI specification covering the transfer-status read, history listing, saved-receiver list, rate-alert objects and, where in scope, the WU+ account feed.
• A protocol and auth-flow report: the session token chain, where step-up (Face/Touch ID) re-auth is forced, token refresh, and the locale/package pinning that keeps corridor data correct.
• Runnable source for the key endpoints in Python and Node.js — MTCN lookup, history pagination, receiver export, FX-alert capture.
• Automated tests over the transfer state machine, including the on-hold and re-auth paths, plus a normalised JSON schema for transfers and receivers.
• Interface documentation and data-retention guidance: what is logged, what is minimised, how consent records are kept.

Three routes to the same transfer records

Authorized interface integration (protocol analysis)

Working from the app's own authenticated traffic under the customer's authorization, this reaches the full set: MTCN lifecycle, history, saved receivers, FX alerts, recurring schedules. Effort is moderate; durability depends on the regional front end, which we account for with a re-validation pass. We set the access up with you during onboarding — a consenting account or a test sender, not a hurdle you clear first.

PSD2 account information (regulated consent)

For a sender who also holds a WU+ digital banking wallet, the wallet is an EU payment account, so account-information access under PSD2 can return balance and posted transactions with the user's consent. It does not reach the remittance pipeline. Durable and clean where it applies, narrow in what it covers.

User-consented credential access / native export

Where a user consents, a credential-driven session can pull the same in-app records; the confirmation-email and history views also give a thinner native fallback for reconciliation. Useful as a backstop, weaker for real-time status.

For most integrators the recommendation is plain: build on interface integration because that is where the transfer state machine and receiver graph actually live, and bolt on the PSD2 wallet feed only for users who hold WU+. The native export is a safety net, not a primary source.

Consent, EU payment rules, and what we log

The package here is the Portugal/EU build, so the governing frame is EU payment-services regulation and GDPR. Western Union's own privacy statement records that it processes personal data on a consent basis for parts of the wallet and money-transfer flow and that a user may withdraw consent and exercise data-subject rights through its privacy portal — we work inside that, not around it. Account-information access for a WU+ wallet runs under PSD2 with explicit, scoped, time-bound consent that the user can revoke, and we design the sync around the consent-refresh window so it does not silently lapse. US senders on this brand sit additionally under FinCEN money-services-business registration and state money-transmitter rules; that shapes which records carry compliance flags (the on-hold status above is one) and how we minimise what is retained. Access is authorized and logged, data is minimised to what the integration needs, consent records are kept, and an NDA is in place where the engagement calls for one.

Engineering realities we plan around

Two things on this app decide whether an integration stays correct. First, the regional package: Western Union ships multiple builds against a shared backend, and corridor rules, currency lists and funding methods differ by region and locale. We pin the integration to the exact package and locale you run (the .pt build here) so what you sync matches what the sender sees, and we keep a maintenance re-validation pass for when a regional front end shifts. Second, step-up authentication: login can use Face or Touch ID and a session can demand re-auth mid-flow. We build the token and session refresh around that so a scheduled sync survives a step-up challenge instead of dropping silently. Two smaller ones we also handle: the MTCN status is a multi-state machine with an on-hold branch we model explicitly, and rate alerts and recurring transfers are server-side schedule objects we capture as objects rather than re-deriving from spot rates.

Where integrators put this

• A remittance-reconciliation back office that matches outbound transfers to MTCN status events and clears them when the receiver is paid.
• A multi-provider money-movement dashboard that mirrors a user's saved receivers and recurring schedules across senders.
• An FX-monitoring tool that ingests the user's own rate alerts and the locked rate on each transfer to report true cost.
• A wallet-aggregation view that adds the WU+ balance and statement lines for users who hold the digital banking account.

Screens we mapped

The app surfaces referenced above, from the public store screenshots, as a quick visual cross-check.

Other remittance apps in the same integration problem

The same transfer-state and beneficiary mapping recurs across the category, which is why a unified integration usually spans several of these:

• Remitly — app-first remittances with tracked transfers and saved recipients across roughly 170 destination countries.
• Wise — multi-currency accounts and transfers, with balances and transaction history behind the account.
• MoneyGram — a large transfer network with reference-number tracking similar in shape to the MTCN.
• Xoom — a PayPal service for transfers to bank accounts, wallets and cash pickup, with its own status tracking.
• WorldRemit — online transfers to bank, mobile money, airtime and cash pickup, each with a transfer record.
• Ria Money Transfer — remittance corridors with strong reach to Mexico, India and the Philippines.
• Revolut — a multi-currency account app with balances, FX and international transfers under one login.
• Paysend — card-to-card and account transfers with saved recipients and tracked sends.
• Skrill — a wallet with international transfers and a transaction ledger behind the account.
• Small World — corridor-focused remittances with cash pickup and bank deposit and per-transfer tracking.

What was checked

This was put together in May 2026 from the app's Play Store description and screenshots, Western Union's published MTCN and tracking pages, its global privacy statement covering consent and data-subject rights, its EU digital banking (WU+) pages, and FinCEN's money-services-business registration material for the US compliance frame. Where a detail is not publicly disclosed — exact in-app endpoint paths, the regional package's full corridor table — it is confirmed against live traffic during the build, not asserted here.

MTCN tracking documentation · Western Union global privacy statement · WU+ digital banking · FinCEN MSB registration

Mapped by the OpenBanking Studio integration desk · May 2026.

Questions integrators ask about this one

Is the MTCN status the same data the public tracking page shows, and can it be polled?

It is the same lifecycle, but richer in-session. The public page returns a coarse stage; the authenticated transfer record carries the full state set the app shows a sender — in progress, available, paid, on hold, plus payout type, send and receive currency, the locked FX rate and receiver reference. We model that whole state machine and poll it on a cadence that matches how the backend updates, rather than scraping one snapshot.

Does the EU open-banking route reach the remittance history or only a WU Wallet balance?

PSD2 account-information access covers a payment account — for a sender who also holds a WU+ digital banking wallet, that means balance and posted transactions for that account. The cross-border send pipeline, the MTCN state machine and the saved-receiver list are not a PSD2 payment account; they live in the app session and come through authorized interface integration. We usually run interface integration as the spine and add the PSD2 account feed only where the user actually has the wallet.

We run the Portugal build of the app — will the integration match other regional Western Union apps?

The listing here is the Portugal/EU package (ending .pt, per its Play Store entry). Western Union ships several regional builds against a shared backend, but corridor rules, available currencies and funding methods differ by region and locale. We pin the integration to the exact package and locale you operate so the currency list, fee model and corridor logic match what your users actually see, and we keep a re-validation pass for when a regional front end shifts.

Can you capture exchange-rate alerts and recurring-transfer schedules, not just the spot rate?

Yes. The app stores rate alerts as threshold objects (a corridor, a target rate, a daily-or-on-match trigger) and recurring transfers as server-side schedules. We capture those objects and their state, not only the point-in-time rate widget, so an integration can mirror a user's alerts and forecast scheduled debits instead of re-deriving them.

Source for the transfer-status and rate-alert endpoints lands inside one to two weeks. You can take it as a source-code delivery from $300, paid only after delivery once you have what you asked for and are satisfied with it; or call our hosted endpoints and pay per call with no upfront fee. You give us the app name and what you need from its data — access and the EU/US compliance side are arranged with you as part of the work. Start the conversation at /contact.html and tell us which records matter to you.