Documentation

Payment Rails

Payment Rails

PerfectPay lets you orchestrate across multiple payment rails without changing your application contract each time you add a new processor or settlement path.

Cards

Best for broad acceptance, recurring billing, and wallet compatibility.

  • card-present and card-not-present support depends on your processor setup
  • 3DS and wallet flows are already represented in the intent and next_action schemas
  • settlement is not instant, but acceptance is broad

ACH and Bank Debit

Best for lower-cost pull-based transactions where settlement speed is less important than margin.

  • strong fit for subscriptions and high-AOV invoices
  • expect asynchronous settlement and returns handling

RTP and FedNow

Best for instant account-to-account movement when both sides are eligible.

  • real-time settlement
  • useful for disbursements, QR payments, and agent-negotiated discounts
  • requires profile, partner, and operational readiness beyond a basic card setup

Stablecoin

Best for treasury-aware flows, cross-border movement, and instant settlement patterns where on-chain rails make sense.

  • often paired with wallet or bridge flows
  • useful in QR and agent-commerce scenarios where instant settlement changes conversion economics

Wallets and Alternative Methods

Wallets, bank redirect methods, vouchers, and other alternatives still fit inside the same intent model.

PerfectPay supports these payment method types:

  • wallet
  • bank_redirect
  • bank_transfer
  • real_time_payment
  • crypto
  • mobile_payment

Choosing a Rail

Use this rule of thumb:

PriorityBest fit
Maximum acceptanceCards and wallets
Lowest blended costACH or account-to-account rails
Fastest settlementRTP, FedNow, or stablecoin
Best embedded checkout UXWeb SDK with cards plus wallets first