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_actionschemas - 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:
walletbank_redirectbank_transferreal_time_paymentcryptomobile_payment
Choosing a Rail
Use this rule of thumb:
| Priority | Best fit |
|---|---|
| Maximum acceptance | Cards and wallets |
| Lowest blended cost | ACH or account-to-account rails |
| Fastest settlement | RTP, FedNow, or stablecoin |
| Best embedded checkout UX | Web SDK with cards plus wallets first |