Mastercard Send, Real‑Time Payouts – Product Teardown
Case Study
One‑liner: Make instant payouts predictable, measurable, and easy to build, so money reliably lands “in minutes” across cards, accounts, and wallets.
Problem and goal
Goal: Increase payout adoption and satisfaction by making time‑to‑wallet predictable and transparent, while reducing build time for partners.
Users and Jobs‑to‑Be‑Done
Product vision and north star
Vision
Send is the fastest way to put money in a customer’s hands, with corridor‑level predictability and a single builder experience.
North star
P95 time‑to‑wallet within 20 minutes on supported cards, with ≥96 percent issuer acceptance on top corridors.
Strategy, three product pillars
Predictability
Surface live corridor SLAs and issuer health, set clear customer promises, route around problems.Control
Expose policy, risk, and fee controls in one console, give finance real cost and SLA views.Ease
Shorten partner build time with a UX SDK and simple API shapes, reduce custom code.
PRD summary, the three core features
A. Corridor Explorer, public and embeddable
Problem
Partners cannot see which corridors, payout types, and SLA bands are available.
Solution
A searchable map and API that returns corridor, payout types (card, account, wallet), P50 and P95 time‑to‑wallet, fee range, weekend coverage.
Key user stories:
As a sales engineer, I can show a prospect live SLAs for US→US and US→CA cards.
As a platform, I can query an API for corridor capabilities at checkout.
Acceptance criteria:GET /corridors?from=US&to=CA&type=card returns p50, p95, fee_min, fee_max, availability_hours.
Data is refreshed at least hourly.
Regions without coverage return a structured, cacheable error.
Analytics
Search to integration rate, top corridor requests, abandonment where coverage is missing.
B. Issuer Health and Smart Routing
Problem
Issuer controls and outages create variance and declines.
Solution
An internal health score per issuer BIN with live status and a routing policy that chooses the best rail, with optional fallback to ACH or RTP if the promise cannot be met.
Key user stories
As a platform, I want Send to avoid issuers where card posting is slow today.
As risk, I want velocity and spend caps by issuer and merchant category.
Acceptance criteria
POST /payout accepts sla_target=20m, returns route=card or route=rtp plus expected_p95.
If the SLA cannot be met, the API returns alternatives with expected time and fees.
Merchant policy can lock routing to certain rails.
Analytics
Acceptance by issuer, reroute rate, met vs missed SLA, false decline rate, fraud loss per million.
C. Partner Console and Risk‑aware UX SDK
Problem
Partners rebuild the same payout UI and policy logic, onboarding is slow.
Solution
A console for fee rules, KYC tiers, and policy, plus a drop‑in UI that handles fees, bank card capture, and real‑time status. Webhooks keep platforms updated.
Key user stories
As a PM, I can set who pays the fee and cap it.
As a developer, I can drop in a prebuilt “Cash out now” component and ship in days.
Acceptance criteria
SDK component renders fee, ETA band, and status.
Webhook events: payout_queued, payout_posted, payout_failed, payout_slow.
Console exports issuer and corridor reports to CSV.
Analytics
SDK adoption rate, time‑to‑first payout, support tickets per 1,000 payouts.
API surface, first draft
Core objects, minimal fields
Payout: id, amount, currency, destination_type, masked_pan_or_account, route, submitted_at, expected_p95, status, posted_at, fee, sla_met:boolean.
IssuerHealth: bin, status, acceptance_rate, p50, p95, last_updated.
Corridor: from, to, type, p50, p95, fee_min, fee_max, hours.
System flow, high level
Client calls /payouts with sla_target=20m.
Router checks IssuerHealth, corridor SLA, and merchant policy.
Route selected, example card push, else RTP fallback if SLA cannot be met.
Webhooks fire status events, console updates SLA met vs missed.
Analytics pipeline aggregates issuer acceptance and time‑to‑wallet.
