Mastercard Send vs Visa Direct: Push-Payment Architecture

A payout API’s approval is only one part of the money movement. The product team also needs to know which destination is eligible, how the send is funded, when the recipient can use the money, and how the originator reconciles settlement. Compare those contracts before comparing the brands.

Visa Direct for Card uses Account Funding Transactions (AFTs) to pull funds and Original Credit Transactions (OCTs) to push funds to eligible Visa accounts. It is one product within the broader Visa Direct portfolio. The supported account types and restrictions depend on the program and market. Visa Direct for Card documentation

Mastercard Send is part of the Mastercard Move portfolio, alongside Cross-Border Services. Send documentation also covers disbursements over non-Mastercard networks. A comparison that treats Send as “Mastercard cards only” or calls every underlying operation an OCT misses those product boundaries. Mastercard Send and Move release notes · Send disbursements to non-Mastercard networks

Separate funding, payout and settlement

Start with three questions. Where do the originator’s funds come from? What instruction delivers value to the recipient? What records establish the originator’s settlement obligation and its completion?

A card-funded transfer can have a funding leg and a payout leg with different outcomes. A funded payout can still fail at the destination. An accepted payout can still need investigation before the recipient’s availability is known. Model those states separately and agree how failed or uncertain legs are recovered.

Recipient availability and the originator’s settlement schedule also answer different questions. Do not impose a generic T+1 or T+2 cycle on both products. Request the funding, settlement, fee, FX and reporting terms for the actual program, entity and corridor. Record the relevant time zones and cutoffs.

Product comparison: the evidence to request

The Visa-specific product and eligibility entries follow its developer guide. Mastercard describes Move as a portfolio with multiple rails and endpoints, subject to market availability; its portfolio totals are not proof that every Send integration reaches every endpoint. Mastercard Move

For speed, use a measurable promise. Visa’s public Fast Funds explanation specifies a maximum of 30 minutes from approval for participating fast-funds issuers, with actual availability dependent on institution and region. It does not establish a universal sub-30-second payout. Do not transfer that Visa definition to another provider’s product. Visa Fast Funds explanation

Four use cases that change the decision

Marketplace and gig-worker payouts. Compare eligible recipient accounts, expected access to funds, fees and recipient preference. A bank fallback may help a particular route, but it is safe only after the original payout is resolved. “Card first” is a routing policy to test, not a universal recommendation.

Insurance and other disbursements. Test amount limits, destination validation and the correction path for a mistaken payment. The recipient needs an understandable status and a support route when the payout is delayed.

Remittance and cross-border payouts. Compare the actual corridor: sending entity, destination, permitted use case, receive amount, FX basis, charges and funding requirements. Assign legal, sanctions and reporting responsibilities to named parties under the applicable arrangement. A network brand does not establish the whole compliance model.

Supplier payouts. Confirm that the business recipient, amount and destination are supported. Test invoice references, reconciliation and correction handling before choosing between card, bank or other available endpoints. A successful consumer payout is not evidence that the same program supports a supplier flow.

A payout trace that can survive a timeout

The following is an illustrative internal model, not a list of either provider’s API statuses:

A funding failure, payout rejection and settlement mismatch belong to different parts of the trace. Keep their identifiers linked without overwriting one outcome with another.

If the first route is uncertain, automatically sending the same obligation over a second route can pay twice. Use the payment timeout and idempotency guide to define recovery and bounded escalation before enabling fallback.

Failure modes to test before launch

• Destination not eligible: distinguish a definitive eligibility failure from a temporary service error. Test whether the lookup and the send can disagree and how the final result is handled.
• Funding succeeds but payout fails: preserve both legs and apply the service’s supported recovery procedure.
• Duplicate submission or update: demonstrate one business effect for the same operation, including worker restarts and delayed responses.
• Uncertain outcome: query or escalate the original attempt; do not assume timeout means failure.
• Recipient reports missing funds: retain the promised availability window and evidence needed for an investigation, rather than repeating “instant.”
• Mistaken or returned payout: establish which query, reversal, return or correction options the product actually supports. Do not assume every send is freely reversible or that every error must use a dispute.
• Settlement mismatch: reconcile gross amount, charges, FX and settlement references under the agreed report contract.

Test failure handling with the provider and record the evidence. A sandbox that accepts the happy-path payload has not proved a recovery procedure works in production.

Launch evidence and ownership

Visa says a Direct for Card originator must be a licensed Visa acquirer or a third-party originator sponsored by one. Its guide requires accountability for the full lifecycle, including settlement, disputes and reporting, before production approval. Visa program and production requirements

For each selected service, keep a launch record with:

1. The contracted product, entity, use case, corridor and approved destinations.
2. Funding and settlement arrangements, limits, cutoffs and report samples.
3. Status meanings, inquiry references, duplicate protection and recovery evidence.
4. Customer-support ownership and escalation contacts for missing or mistaken payouts.
5. Applicable compliance responsibilities and the owners who accepted them.
6. Provider approval and internal acceptance of operational tests.

Track confirmed payout outcomes, time to recipient availability where observable, unresolved attempt age and settlement exceptions by route. Define the event behind each metric. A fast API response is not a measurement of funds availability.

FAQ

Are Mastercard Send and Visa Direct the same product?

No. Compare the exact service and contract. A card API, a cross-border service and a wider money-movement portfolio can have different endpoint, funding and operating requirements.

Is Mastercard Send limited to Mastercard-branded destinations?

No. Its published disbursement release notes explicitly cover non-Mastercard networks. The destination still needs to be supported by the contracted program and market.

How fast will the recipient receive the money?

Use the availability commitment for the actual route and receiving institution. Measure confirmed recipient availability where the integration provides that evidence; do not substitute API latency.

Does an approved payout mean settlement is complete?

Interpret the provider’s status precisely. The originator must still reconcile its obligation, provider reports, fees and bank movement under the settlement contract.

Should a failed card payout automatically fall back to a bank transfer?

Only after the original outcome is resolved and the fallback is allowed by the product’s routing and authorization policy. An unknown result is not a safe trigger for another payout.

For corridor design, see cross-border corridors as operating systems. For the settlement evidence, see three-way reconciliation.