May 29, 2026

Prepaid Card APIs vs Push-to-Card vs ACH: A 2026 Decision Framework for Rewards & Disbursements

Dalia

Head of Growth

If your team sends money to anyone outside your payroll — research participants, partners, sales spiffs, referral winners, gig workers, conference panelists, marketing-incentive recipients — you are already running a payouts program. Most teams pick a rail by reflex (usually ACH) and never revisit it. That reflex is now expensive.

In 2026, four real options compete for a B2B payout: ACH, RTP/FedNow, Push-to-Card (Visa Direct, Mastercard Send), and Prepaid Card APIs (the bridge between bank rails and the gift card economy). They have different settlement times, different fee structures, different decline-rate failure modes, and different recipient experiences. The right rail depends on four variables — none of which are “which one is cheapest.”

This is the decision framework GIFQ uses to size which rail a buyer should actually pick. No vendor pitch. The cases where GIFQ is the wrong answer are called out explicitly.

The four options at a glance

ACH — settlement 1–3 business days (Same-Day ACH adds an intraday window); requires US bank account + routing/account numbers; typical all-in cost $0.20–$1.50 per transfer; failure modes are NSF returns, R-code reversals up to 60 days later, no recipient-side visibility.
RTP / FedNow — settlement under 60 seconds, 24/7/365; requires US bank account at a participating institution (~70% coverage in 2026); typical all-in cost $0.50–$2.50 per transfer; failure mode is recipient’s bank not on network → silent fallback to ACH, no recall window.
Push-to-Card (Visa Direct / Mastercard Send) — settlement seconds to 30 min depending on issuer; requires debit card number (PAN); typical all-in cost 1.0%–2.5% + $0.10–$0.50; failure modes are decline rates of 5–18% in the wild (prepaid debit, expired card, OFAC) and the absence of idempotent retry primitives at most aggregators.
Prepaid Card APIs (open + closed loop) — settlement instant (link delivery) to 24h (physical card); requires email address or phone number — no banking data; typical all-in cost 3%–8% (varies by brand mix); failure modes are brand catalog gaps in a geography and recipient breakage if links expire unredeemed.

The first three move money to a bank or card account the recipient already has. The fourth moves spend power to the recipient without touching their banking surface at all. That distinction is the entire reason the prepaid card API category exists.

When ACH is the right answer

ACH is correct when all of these are true:

The recipient has a US bank account and you can collect routing/account numbers without friction
Recipients are repeat (W-9’d vendors, employees, repeat panelists)
Speed-to-recipient does not affect program outcomes (no LTV halo on instant)
Per-transaction value is high enough ($100+) that the percentage savings vs card rails matter
You are operationally tolerant of 60-day reversal risk

Where ACH breaks: one-off recipients (collecting bank details for a $50 honorarium kills your response rate), international recipients (ACH is US-only — SEPA and Faster Payments are the geographic equivalents and have their own rules), or any program where “I want my money now” affects conversion (referral programs, sales spiffs, gig payouts).

When RTP / FedNow is the right answer

RTP and FedNow are correct when all of these are true:

US recipient with a bank account at a participating institution — verify before you commit, coverage is real but uneven
Sub-minute settlement materially changes recipient behavior
You have idempotency primitives in place — RTP transfers are irrevocable, a duplicate post is permanent
Per-transfer fees of $0.50–$2.50 are acceptable

Where instant payments break: the recipient’s bank isn’t on the network and your aggregator falls back to ACH without telling you (you’ve now paid the RTP fee for ACH speed), the recipient is outside the US, or your finance team isn’t ready for 24/7 reconciliation.

When Push-to-Card is the right answer

Push-to-Card (Visa Direct, Mastercard Send) is correct when all of these are true:

You can collect a debit card PAN (not a bank account)
Recipient is US or in one of the ~30 markets with mature push-to-card rails
Decline rate of 5–18% is acceptable, or your aggregator gives you decline classification and retry logic
Per-transfer cost of 1–2.5% is below the LTV-to-CAC lift of “instant” in your program

Where push-to-card breaks: the recipient hands you a prepaid debit (rejected at most issuers), an expired card, or a card in a region your aggregator doesn’t service. Decline classification is the make-or-break engineering problem — “card declined” without a structured reason is unactionable. Most aggregators surface a fraction of what the network actually returns.

Engineering watch-out: push-to-card looks identical to ACH in your database schema (recipient → amount → status), but the failure modes are categorical, not statistical. Build retry logic around the decline classification, not around fixed-interval polling.

When Prepaid Card APIs are the right answer

Prepaid card APIs (the GIFQ category) are correct when any of these are true:

You don’t have, can’t get, or don’t want the recipient’s banking surface
Recipient is international and you’d otherwise be stuck with FX-on-FX losses and cross-border ACH equivalents
The recipient population is wide-and-shallow: many one-time recipients, low average value, high collection friction on bank rails
You’re optimizing for redemption joy, not just successful delivery — research participants, conference speakers, marketing incentive winners, customer loyalty
You need a single API to fan out to multiple brand catalogs plus open-loop options (Visa virtual card, Mastercard virtual card)

Where prepaid card APIs break:

You need to deliver $5,000+ of value per recipient — at that ticket size, the percentage cost of any closed-loop catalog is rough vs ACH
The recipient is your employee on regular payroll — use payroll
Tax reporting rules in your jurisdiction make non-cash equivalents administratively expensive (1099 thresholds, certain country-level prohibitions on gift card honoraria — verify with your accountant before scaling)
You require exactly cash, not “spend power” (some procurement teams have this constraint; respect it)

This is the section most “rewards platform” posts skip. Skip it at your own risk.

The 4-variable decision framework

Run every new payout program through these four questions. The combination decides the rail, not any single answer.

Variable 1 — Recipient persona

Employees / repeat W-9’d vendors → ACH (already have banking surface; cost matters more than speed)
One-time international recipients → Prepaid Card API (banking-rail collection friction kills response rate)
US gig workers / sales spiffs → Push-to-Card (debit-card collection is acceptable; speed converts)
Research participants / honorarium recipients → Prepaid Card API (IRBs increasingly object to paper checks; banking-rail collection wrecks completion rates)
Customer referral winners / marketing incentive recipients → Prepaid Card API (open-loop virtual card gives them choice without the bank-detail ask)

Variable 2 — Geography

US-only → all four rails work; choose by recipient persona
US + EU → ACH/SEPA for repeat vendors, Push-to-Card for sub-30 markets, Prepaid Card API as the global fallback
Long-tail international (90+ countries) → Prepaid Card API (open-loop virtual card + localized closed-loop catalog) — this is the ICP GIFQ was built for
Specific country bans → check before you ship; do not assume

Variable 3 — Speed-to-recipient as a program variable

If “instant” doesn’t change behavior in your program, you are paying for it for no return. Run the actual A/B before locking in RTP or push-to-card.

Speed materially lifts response rate (referral, sales spiff, research participant) → push-to-card or prepaid card API (instant link)
Speed doesn’t matter (B2B vendor invoice, recurring stipend) → ACH

Variable 4 — Recipient acceptance rate (the silent killer)

This is the variable most teams miss until quarter-end reconciliation.

ACH: ~99% acceptance for verified accounts, but 60-day reversal window
RTP: acceptance depends on bank participation — verify, don’t assume
Push-to-card: 82–95% acceptance in the wild. Track your specific aggregator’s decline rate.
Prepaid Card API: 95–99% delivery; redemption rate of 70–90% depending on brand mix and link-expiry policy. The 10–30% breakage is a real number — design your program economics around it.

If you don’t know your acceptance rate per rail, you don’t know what your program costs.

The economics math

A worked example for a 1,000-recipient referral program at $50 each ($50,000 face value):

ACH: ~$500 in fees, <1% returns, ~$49,500 net delivered — effective ~$0.50 per recipient plus collection-friction loss.
RTP: ~$1,500 in fees, <1% issues (assuming bank coverage), ~$49,500 net delivered — ~$1.50 per recipient.
Push-to-Card: ~$1,250 fees (2.5%), ~10% decline, $45,000 delivered (5,000 retry queue) — $1.25 per attempted, but retry-ops cost dominates.
Prepaid Card API (closed-loop blend): ~$2,500 fees (5%), ~15% breakage depending on link-expiry policy, $42,500 redeemed — if breakage credits back, effective ~$0 per recipient.
Prepaid Card API (open-loop virtual card): ~$3,500 fees (7%), ~5% breakage, $47,500 spent — $3.50 per recipient, but no banking surface ask.

The right comparison isn’t fee-vs-fee. It’s fee + collection friction + reversal/retry ops + program-completion lift. Push-to-card and prepaid card APIs both look expensive on the headline rate and both routinely win on the full-stack number when collection friction or completion rate matters.

When GIFQ is the wrong answer

GIFQ is wrong for: $5K+/recipient payouts where ACH or wire economics dominate; pure payroll; programs where the recipient explicitly requires cash equivalents only; jurisdictions where non-cash incentives have a tax-reporting cost your operations team can’t carry. We say no to these regularly.

GIFQ is right for: international payouts at scale (90+ countries, mixed open-loop and closed-loop), research and honorarium programs, marketing-incentive programs, sales spiffs where the recipient population is wide and one-time, and referral programs that optimize for completion and LTV halo over headline cost.

Decision tree, in one paragraph

If your recipient already has and will share their bank account, the value is over $500, and speed is not a program variable → ACH. If they have and will share a bank account at a participating FI and instant materially helps → RTP/FedNow. If they have a debit card and you accept a 5–18% decline window → Push-to-Card. Otherwise — international, one-time, low-friction collection, program-completion-sensitive, or you want recipient choice — Prepaid Card API. Most B2B payout programs are some mix of the bottom two.

What ships next

If you’re sizing a payouts program right now and want the math run against your specific recipient population, geographies, and per-recipient value: book 30 minutes and we’ll model it across all four rails, including the case where GIFQ is the wrong answer. We do this every week.

If you want to see the API shape before you talk to anyone: GIFQ payouts API · pricing · brand catalog.