---
title: "What is push-to-card — and what to call it in a contract"
description: "Push-to-card explained: how Visa Direct and Mastercard Send deliver payouts to a debit card in minutes, what it costs, and the contract language to use."
url: "/blog/what-is-push-to-card/"
date: "2026-07-16"
author: "Valeria Vahorovska"
tags: ["Guides","Payouts"]
---

# What is push-to-card — and what to call it in a contract

Push-to-card is a payout delivered to a debit card: money pushed *onto* the card over Visa Direct or Mastercard Send — the reverse of a normal charge — landing in the cardholder's bank account within minutes, around the clock. It's the rail behind most "instant pay" buttons in gig and marketplace apps, and the answer to a question one operator asked verbatim in a thread we tracked: *"what do you even call the push-to-card stuff in a contract?"*

Both halves of that question matter — what it is, and what to write down — because the gap between "instant payout" on a landing page and an enforceable contract term is where marketplace disputes are born.

## How it actually works

A normal card transaction *pulls*: the merchant charges the card, money leaves the cardholder. Push-to-card runs the same networks backwards: an **Original Credit Transaction** pushes funds to the card, and the issuing bank credits the cardholder's account — [typically in under thirty minutes](/docs/payouts/when-will-the-money-reach-my-bank-account/), often near-instantly, 24/7 including the Friday 11pm that bank rails sleep through.

What makes it valuable for payouts is **reach**. Bank-to-bank real-time schemes (RTP, FedNow) need the recipient's bank to be on the network — and coverage is thinnest exactly where gig workers bank. Nearly everyone, though, has a debit card. The recipient types in a card number instead of routing details, which is also simply easier onboarding.

The trade-offs are equally concrete: a **per-transaction fee** (a percentage or fixed amount someone — you or the recipient — pays), **per-network limits** on transaction size, **eligibility gaps** (some prepaid and credit cards don't accept pushes), and **irrevocability** — once pushed, the money is the recipient's; recovery is a negotiation, not a reversal. We've covered where it sits among the four "instant" rails in [Instant payouts isn't one thing](/blog/instant-payouts-isnt-one-thing/) and what happens [when the primary rail fails](/blog/instant-payout-fallback-rail/).

## What to call it in a contract

"Instant payout" is a marketing phrase, not a term of art — and writing it into a contract unqualified is how you end up owing "instant" during a network outage. The contract needs four things named:

**1. The rail.** *"Payouts may be delivered via push-to-card (Visa Direct / Mastercard Send), real-time bank transfer (RTP / FedNow), or ACH."* Naming rails keeps the promise tied to things that exist.

**2. The availability promise, hedged honestly.** *"Funds typically available within 30 minutes of payout initiation."* "Typically" plus a named exclusion list — card ineligibility, network outages, compliance review — beats an absolute promise you can't keep on a holiday weekend.

**3. The fallback.** *"Where push-to-card is unavailable for a recipient, payouts fall back to same-day ACH, subject to network cut-off times."* This is the sentence most contracts miss and [most disputes hinge on](/blog/instant-payout-fallback-rail/).

**4. The fee and the limits.** Who pays the push fee (a flat per-payout charge, or a percentage — many platforms pass it to the worker as the price of speed, with free standard payout as the default), and what per-transaction limits apply.

If your platform's terms say less than that, your support team is the contract.

## Where Fynex fits

In Fynex, push-to-card is one rail among several rather than a product you integrate separately. Each payout is routed to the fastest compliant rail that can actually reach that recipient — push-to-card where a card is registered and the amount fits, RTP or FedNow where the bank supports it, [same-day ACH as the disclosed fallback](/features/payouts/) — with the fee difference visible before you approve the run and every payout recording which rail it took. Because pushes are irrevocable, verification happens where it belongs: the agent checks the payout against your rules *before* the money moves, and anything that moves money [waits for your approval](/docs/payouts/why-do-i-need-2fa-or-a-passkey-to-approve-a-payout/).

Push-to-card earned its place: it's the rail that made "get paid before you're home from the shift" real. Just don't let the landing-page word do the contract's job — name the rail, the promise, the fallback and the fee, and "instant" becomes something you can actually deliver.