Push-to-Card vs ACH: When to Route Payouts to Card Networks

If you're building a payout system, you've probably asked: should this payment go over ACH or straight to a card? The answer isn't one-size-fits-all. Modern treasury platforms now offer Push-to-Card as a unified API option alongside ACH, RTP, and FedNow—which means developers need a routing strategy, not just one rail.

Let's break down the tradeoffs and when to pick each.

The Core Differences: Cost, Speed, and Settlement

Feature	ACH	Push-to-Card	RTP	FedNow
Settlement	1–2 business days	Immediate (card network)	Real-time	Real-time
Cost per txn	$0.25–$1.50	$0.50–$2.00	$0.50–$2.00	$0.25–$1.00
Reversibility	60 days (R-codes)	Dispute-based (chargeback)	Immediate reversal possible	Immediate reversal possible
Reach	98% of US accounts	Card-holders only	Growing (major banks)	Growing (Fed-backed)
Failure rate	2–5% (returns)	0.5–2% (invalid card)	<1%	<1%

Push-to-Card loads funds directly onto a cardholder's debit or prepaid card via Visa or Mastercard networks. It's instant—the customer sees the balance within seconds. But it only works if you have a valid card number, and the issuer must support the feature.

ACH remains the workhorse: cheap, reliable, and reaches nearly every US bank account. But it's slow (1–2 days), and returns can arrive up to 60 days later, creating reconciliation headaches.

RTP and FedNow are real-time alternatives that live between ACH and Push-to-Card: faster than ACH, cheaper than cards, but require both sender and receiver to be on the network.

When to Route to Push-to-Card

Use Push-to-Card when:

Speed matters. Gig workers, freelancers, and on-demand payouts expect same-second settlement.
You have a card on file. Subscription services, marketplace platforms, and payroll apps already collect card data.
Return rates are killing you. If your ACH return rate is >3%, card failures (which fail fast) may reduce reconciliation overhead.
Customer friction is high. Instant visibility reduces support tickets.

Example: Marketplace Payout Logic

async function routePayout(recipient, amount) {
  // Check if we have a valid card on file
  if (recipient.card && isCardValid(recipient.card)) {
    try {
      const result = await pushToCard({
        cardToken: recipient.card.token,
        amount: amount,
        idempotencyKey: `payout_${recipient.id}_${Date.now()}`
      });

      if (result.status === 'immediate') {
        return { method: 'push-to-card', status: 'settled', ...result };
      }
    } catch (err) {
      // Card declined or network issue—fall back to ACH
      console.log(`Push-to-Card failed: ${err.code}, falling back to ACH`);
    }
  }

  // Default to ACH for reliability
  return await initiateACH({
    accountNumber: recipient.bankAccount,
    routingNumber: recipient.routingNumber,
    amount: amount
  });
}

When to Stick with ACH

Use ACH when:

Cost is primary. At $0.25–$0.50 per transaction, ACH beats cards for high-volume, low-urgency payouts.
You lack card data. B2B payments, vendor settlements, and international transfers rarely have card details.
Regulatory clarity matters. ACH is fully regulated under NACHA rules; card network rules vary by issuer.
Dispute risk is low. ACH returns are predictable (R01, R03, R10); card chargebacks are messier.

Building a Hybrid Router

Production payout systems use a waterfall strategy:

Try Push-to-Card (if card on file, amount <$5k, recipient opted in).
Fall back to RTP (if both banks support it, amount <$100k, settlement within 2 hours acceptable).
Default to ACH (always works, cheapest, handles edge cases).

The key is idempotency: every payout attempt needs a unique key so retries don't double-charge. Modern treasury APIs (Modern Treasury, Stripe

Decoding ACH return codes programmatically? The ACH Return Codes API returns the full Nacha R01–R85 set with plain-language descriptions and handling guidance.