Pulling transfer status, history and live quotes out of Walmart2Walmart powered by Ria

Every send in this app resolves to one value that keeps changing after you read it: a status that walks from sent, to in process, to ready for cash pickup, to paid. The sender follows it by an order number or PIN, the same reference printed on the receipt, through Ria's track-a-transfer tool. Build an integration here and that status field — plus the history, the recipients, and the quote that priced the send — is the real payload. The route we take is authorized interface work against the sender's own session, reconciling what the app shows against the rail underneath it.

Where the money data lives inside the app

These are the surfaces a real account touches, named the way the app and Ria's help pages name them rather than a generic feed list.

Getting at the transfer data, the authorized way

Three routes apply to this app. Each is described by what it reaches, how durable it is, and what we set up to run it — onboarding and access are arranged with you as the build starts, not handed to you as a list to clear first.

Authorized interface integration of the sender's session

We analyse the app's own authenticated traffic under the account holder's authorization and rebuild the calls behind status, history, recipients and quotes as a clean interface. This reaches everything the sender can see. Effort is moderate — there is a token or cookie session to carry, and mobile remittance apps commonly add device attestation we account for during onboarding. Durability tracks app releases, so a short re-validation pass rides with each meaningful update. This is the route we would build the integration on.

User-consented account access

Where the use case is reading one sender's data on their behalf, the same surfaces are reachable through a consent the sender grants, scoped and time-boxed. Reach is identical to the session route; lifetime is bounded by the consent and is refreshed within its own window rather than left to lapse mid-sync.

Native history export as a backfill baseline

Ria offers a transfer-history report — downloadable in-app in a few markets, and elsewhere requested through a form with a government-ID upload, per its help centre. It is slower and not real-time, but it is an honest reconciliation baseline for historical amounts, fees and FX rates. We pair it with the live poll: the report anchors the past, the session route carries anything still moving.

What lands in your repo

The deliverable is working code first, with the written artefacts alongside it.

• Runnable client source in Python and Node.js for the status, history, recipient and quote calls — the part you can run on day one.
• A webhook or callback handler that turns each status transition into an event your systems can consume, with the order number as the dedupe key.
• An automated test suite that exercises the corridors you care about against recorded fixtures, pinning the rebuilt interface to the app's real responses.
• A sync design that states plainly what is polled (live status), what is event-driven, and what is batch-loaded (the history report) — including the rate-quote freshness window.
• An OpenAPI/Swagger description of the rebuilt interface, plus a protocol and auth-flow write-up covering the session token, any device attestation, and the cookie chain as it actually behaves here.
• Interface documentation and data-retention guidance, written for engineers maintaining this after handover.

A status call, sketched

This is the shape of the central call — reading one send's status by the order number on the receipt. Field names are illustrative and get confirmed against the app's own track surface during the build.

# Read one send's current state from the Ria rail, keyed on the order
# number / PIN the app prints on the receipt. Shape is illustrative;
# exact fields are confirmed against the track-a-transfer surface.

GET /session/transfers/{order_number}
Authorization: Bearer <session token from the authenticated app login>
X-Device-Attest: <device token captured during onboarding>

200 OK
{
  "order_number":  "RIA-XXXXXXXXX",        # the PIN / order number on the receipt
  "status":        "READY_FOR_PICKUP",     # SENT | IN_PROCESS | READY_FOR_PICKUP | PAID | CANCELLED
  "corridor":      "US-MX",
  "send_amount":   { "amount": "200.00",  "currency": "USD" },
  "fee":           { "amount": "4.00",    "currency": "USD" },
  "fx_rate":       "17.10",                # rate locked at send time
  "payout_amount": { "amount": "3420.00", "currency": "MXN" },
  "payout_method": "CASH_PICKUP",          # CASH_PICKUP | BANK_DEPOSIT | WALLET | HOME_DELIVERY
  "quoted_at":     "<timestamp>",
  "collect_by":    "<deadline>"            # recipient collection cut-off
}

# Reconcile: map status onto your own ledger row keyed by order_number.
# On a US-MX corridor the fee / fx_rate / payout_amount mirror the
# receipt the sender was shown — treat them as the disclosed figures.
      

Keeping status and quotes fresh

A transfer's status is the one field that moves on its own clock, so the design is built around it. We poll the track surface by order number and key the stored record on that same order number — re-reading a send that has already settled updates the existing row rather than appending a second. Rate quotes get the opposite handling. A quote is good for a short window only, so a cached price is marked stale on a timer and re-fetched from Check Prices before it is presented as current. For a recipient who has up to roughly two months to collect, per the consumer guides, a send can sit at ready-for-pickup for weeks; the poll cadence backs off for long-lived sends instead of hammering an unchanged record.

Remittance rules, KYC, and the consent we build on

This is a US money-services context, and the settled framework that matters here is the CFPB's Remittance Transfer Rule under Regulation E (12 CFR Part 1005, Subpart B), which the bureau says applies to providers handling more than 500 remittance transfers a year. It governs the international leg — a US-to-Mexico send — by requiring the provider to disclose the exchange rate, fees and the amount the recipient receives, give a receipt, and honour a roughly 30-minute cancellation window, with up to 180 days to report an error, per the CFPB. Those disclosure fields are exactly what surfaces in the data, which is why we treat the FX, fee and payout figures as the receipt the sender was legally shown. On the anti-money-laundering side, Ria operates as a FinCEN-registered money-services business, and identity verification plus beneficiary record-keeping above the $3,000 threshold are part of how the rail works, per FinCEN/BSA guidance.

For data rights, the dependable basis is the sender's own authorization — their consent to operate their session, logged, with consent records kept and an NDA where the engagement needs one. The forward-looking US data-portability rule, the CFPB's Personal Financial Data Rights rule (12 CFR Part 1033), is back in agency reconsideration and not in force, so we do not build against it as if it were settled law; if it lands, the consent-based design adapts to it. Access is data-minimised — we read what the integration needs and no more.

What this corridor forces us to handle

Two things about this specific app shape the build, and we account for both rather than passing them back to you.

• Domestic and international sends are not the same record. A US-to-Mexico transfer carries the cross-border disclosure block — FX rate, itemised fee, payout in the destination currency — that the Remittance Transfer Rule attaches to the international leg, while a US or Puerto Rico domestic send does not. We model the corridor as a first-class field so a consumer of the data never reads an FX rate that was never quoted, and so the disclosure fields only appear where they genuinely exist.
• History comes from a different door than live status. Live state is the track-by-order-number surface; deep history, for US senders, comes from Ria's transfer-history report request with an ID upload, per its help centre. We design the sync so the report-based backfill and the live poll meet cleanly on the order number, and so a sender's older sends reconcile against the live ones without duplicates. Access to a consenting account or a sponsor sandbox for this is arranged with you during onboarding.

Screens we mapped against

Store-listing screenshots of the surfaces above — the send flow, status tracking and pricing — for reference.

How this brief was put together

The surfaces above were checked in June 2026 against the Google Play listing, Ria's own Walmart and track-a-transfer pages, and the CFPB's remittance materials; the regulatory figures come from the bureau's published rule, not from memory.

• Google Play — Walmart2Walmart powered by Ria listing
• Ria — Walmart 2 Walmart and Walmart 2 World
• Ria — Track a Transfer (order number / PIN)
• CFPB — Remittance Transfer Rule
• eCFR — 12 CFR Part 1005, Subpart B

Notes compiled by OpenFinance Lab — payments interface engineering, 2026-06-08.

Other remittance apps in the same integration picture

If you are unifying cross-border money movement across providers, these sit in the same category and hold comparable per-sender data; named here for ecosystem context, not ranked.

• Remitly — digital remittance with express and economy tiers; holds transfer status, recipients and corridor pricing per account.
• Western Union — global transfers tracked by MTCN; per-send status, payout method and fee history behind a login.
• Wise — multi-currency transfers at the mid-market rate; holds balances, recipients and itemised transfer records.
• Xoom — PayPal's international transfer service; per-transaction status, payout type and FX details per user.
• MoneyGram — cash and digital transfers with reference-number tracking; status and payout-location data per send.
• WorldRemit — digital transfers strong in mobile-money corridors; recipient, status and delivery-method records.
• Sendwave — fee-light app focused on African and Asian corridors; holds send history and recipient profiles.
• Paysend — card-to-card cross-border sends; per-transfer status and linked-card metadata per account.
• Xe Money Transfer — transfers paired with rate tooling; quote, transfer and recipient data behind an account.
• ACE Money Transfer — corridor-focused remittance with cash and bank payout; status and beneficiary records per sender.

Questions integrators ask about this one

How do you keep a copy of a transfer's status in sync once a send is already in flight?

We poll the track surface keyed on the order number printed on the receipt and map each state change — sent, in process, ready for cash pickup, paid, cancelled — onto your own record. The stored row is keyed on that same order number, so re-reading a send that has already settled updates the existing row instead of writing a second one. Rate quotes are handled the other way around: a quote is good only for a short window, so a cached price is treated as stale on a timer and re-fetched from the Check Prices surface before it is shown as current.

Does a US-to-Mexico send expose different fields than a US-to-US one?

The record shape is the same, but the international corridor carries the disclosure fields the CFPB Remittance Transfer Rule requires — the exchange rate, the itemised fee, the amount the recipient will collect, and the date funds become available. We surface those exactly as the app presents them, since on a US-to-Mexico transfer they are the figures the sender was legally shown at send time. A US or Puerto Rico domestic send carries the funding and status fields but not the cross-border FX disclosure block.

Can you pull historical sends, not just the live ones?

Yes. Live transfers come from the track-by-order-number surface; for history we use the account's past-sends list, and where the in-app download is not offered for a market the transfer-history report is requested through Ria's form with a government ID upload, per its help centre. That report is a good reconciliation baseline for backfill — amounts, fees, FX rates and dates going back across prior sends — while the live poll handles anything still moving.

We only want the rate-and-fee quote feed, not the whole account — is that a smaller build?

It is. Scoping to the Check Prices surface — amount in, fee, exchange rate, amount out for a given corridor — is a narrower job than mapping the full authenticated account, and it needs no consenting login because pricing is quoteable without one. Tell us the corridors you care about and what you want back; access and any compliance paperwork are arranged with you as part of the work, and a first drop is typically one to two weeks out.

A first working drop lands inside one to two weeks. Take the source outright from $300, paid only once it is in your hands and runs as described; or skip the build entirely and call our hosted endpoints, paying per call with nothing up front. Send us the app name and what you want out of its data and we will scope it — Start a Walmart2Walmart integration

Last checked 2026-06-08