Bank rails · inbound + payouts
ACH direct-deposit, SEPA Direct Debit, Bacs, Interac and PIX behind one unified authorise / capture / payout contract. Mandate handling, R-code-aware retries and one reconciliation feed across every direct bank rail — same platform, same dashboard, same ledger as your card side.
Key benefits
Four properties that show up the moment a merchant stops routing recurring or high-ticket flows through cards and starts riding bank rails instead.
Bank rails settle inter-bank; there's no scheme interchange to pay. On recurring or high-ticket flows the landed cost drops well below the card equivalent. topropay's direct payment processing exposes the same authorise / capture shape as card so the merchant doesn't fork their integration.
NACHA authorisations for ACH, SEPA mandate IDs for SDD, Bacs DDIs for UK direct debit — all captured on first payment and stored per scheme rules. R-code / return-code events (NSF, R01, R03, R04) drive scheme-aware retry timing rather than blind re-runs.
The same rail relationships that clear inbound direct debits push outbound ACH direct deposits, SEPA credits and Interac e-Transfer payouts. Payroll, marketplace seller payouts and refund push-backs all ride the same API surface.
Inbound debits, outbound payouts, returns, R-code adjustments and fees normalise into the same ledger as card, wallet and BNPL. Finance reads one export tagged by rail, scheme, currency and mandate ID.
How direct payment processing works
What actually happens between the first mandate capture and the row in the merchant's ledger — and where topropay sits inside that chain.
First payment captures the scheme mandate — NACHA authorisation for ACH, SEPA mandate ID for SDD, Bacs DDI for UK. The mandate is stored with the vault token so refunds and recurring debits reference it later.
The authorise endpoint takes the debit request, tags it with the mandate, and hands it to the partner ACH / SEPA / Bacs processor. The response returns a pending status per rail (bank rails don't clear instantly).
The rail clears on its own calendar — 1–3 business days for standard ACH, next-day for same-day ACH, T+2 for SEPA SDD Core, T+1 for Interac. Returns produce R-code events; the platform surfaces the reason and drives the retry policy.
Settlement files from the rail processor normalise into the unified ledger. Payouts on the same rails (ACH credit, SEPA credit, Interac e-Transfer) are reconciled in the same feed.
Refunds ride the same mandate on the same rail; ACH refunds push a credit; SEPA refunds trigger a scheme-defined refund path. The refund is tagged back to the original vault token for the audit trail.
Main use cases
Six recurring merchant shapes — SaaS, B2B, marketplaces, payroll, insurance and charity — that benefit from bank-rail acceptance and payouts on one API.
SaaS billing pairs recurring card (default) with SEPA SDD for EU customers and ACH direct debit for US customers — lower landed cost on renewals over their lifetime.
B2B counterparties often prefer bank rails to card on invoices. The invoice pay link surfaces ACH / SEPA on the same URL as card; the merchant doesn't run separate billing systems per rail.
Marketplace pays sellers by ACH credit (US), SEPA credit (EU) or Interac e-Transfer (CA). All ride the same API and settle into the same reconciliation feed.
ACH direct deposit for US W-2 payroll, SEPA credits for European contractors, Interac e-Transfer for Canadian gig workers — one API in the payroll platform, many rails behind.
Recurring SEPA SDD or ACH debits collect premiums; ACH credit or SEPA credit pushes claim payouts. Refund of premium overpayments ride the same mandate.
Recurring SEPA SDD or ACH debits keep collection costs low on donor renewals; retry policy is tuned to donation age to avoid burning goodwill on aggressive re-attempts.
Platform features
Twelve capabilities grouped into rail coverage, mandate mechanics, and platform / finance. Each applies whether the merchant runs direct rails only or pairs them with the card and wallet side.
Standard, same-day; consumer (WEB / TEL / PPD) and business (CCD).
SEPA Credit Transfer (SCT), SCT Inst, and SEPA Direct Debit (SDD Core / B2B).
Bacs Direct Debit for recurring, Faster Payments for near-real-time credits.
Interac Online for debits, Interac e-Transfer for payouts.
WEB / TEL / PPD authorisation shapes captured and retained per NACHA rules.
Mandate ID + creditor ID stored per SDD scheme rules; SDD Core and SDD B2B pathways.
Retry timing tuned per rail return code (NSF, insufficient funds, invalid account, etc.).
Bank-account validation via partner services before the first debit lands.
Same authorise / capture / refund contract for every direct rail — no per-rail integration.
Outbound ACH credit, SEPA credit, Interac e-Transfer surfaces alongside inbound debit.
Inbound, outbound, returns and fees across every direct rail normalised into one ledger.
Signed lifecycle events; connectors for popular ERPs and accounting systems.
Industry relevance
topropay's direct-rail posture targets licensed merchants operating across Europe, the UK, North America, LATAM and APAC — SaaS with recurring billing, B2B invoicing, marketplaces with seller payouts, payroll platforms, insurance carriers with premium collection and claim payouts, and charity organisations with donor renewals.
Trust & compliance
Rail-specific scheme rules — NACHA, SEPA mandate handling, Bacs indemnity — layered on top of the platform's PCI DSS Level 1 posture where card also applies.
Ready to run bank rails
A 30-minute rail-coverage review covers the direct rails relevant to your buyer geographies (ACH, SEPA, Bacs, Interac, PIX), mandate handling and R-code retry policies, and a sandbox to test against before any commercial commitment.
Frequently asked
Definitions, rail differences, ACH direct-deposit mechanics, refund and reversal windows, and the practicalities of running bank rails alongside card.
Direct payment solutions on topropay cover bank-rail acceptance and payouts on one unified API: ACH (US), SEPA (EU), Bacs / Faster Payments (UK), Interac (CA), PIX (BR) and PayID / OSKO (AU). Mandate handling, R-code / return-code retries and reconciliation ride the same platform as card and wallet acceptance.
Yes — direct payment gateway describes the inbound side of the same platform. The merchant integrates one gateway API and the routing engine picks the connected rail processor per authorisation. For direct-rail debits (ACH, SEPA SDD, Bacs), the gateway captures the mandate on first payment and reuses it on renewals.
Yes. Interac direct payment on the platform covers Interac Online for consumer-authorised debits and Interac e-Transfer for outbound payouts. Both surface through the same authorise / capture / payout API contract used by ACH and SEPA. Canadian buyers see Interac as an option alongside card at checkout where enabled.
The direct payment system settles inter-bank instead of via a card scheme, so there's no interchange to pay. That drops landed cost — especially on high-ticket and recurring flows. The trade-off is settlement timing (rail-specific, not real-time on most rails) and mandate handling (extra scheme rules to comply with).
ACH payment direct deposit is the outbound side of the ACH rail — a credit push from the merchant's funding account to the recipient's bank account. topropay's payout API takes the recipient's bank details (or vault token if previously stored), tags the batch with the merchant's ACH originator ID and hands it to the partner ACH processor. Standard ACH direct-deposit settles 1–2 business days; same-day ACH where supported.
Direct deposit ACH payment is generally irreversible after settlement; a NACHA reversal is only permitted for specific scenarios (duplicate, wrong amount, wrong account) within a 5-business-day window. topropay's payout API surfaces the reversal endpoint where applicable; the merchant's operator has to justify the reversal reason for the audit trail.
Direct payment processing starts with mandate capture (for debits) or recipient details (for payouts), then submission to the partner rail processor, then settlement on the rail's own calendar, then reconciliation into the unified ledger. R-code / return-code events feed into the retry policy for debits and the reversal window for payouts. The whole flow is exposed through the same unified API as card processing.
Payment processing direct rides bank rails (ACH, SEPA, Bacs, Interac, PIX). Card processing rides scheme rails (Visa, Mastercard, Amex). Direct rails settle inter-bank with no scheme interchange; card rails offer instant authorisation and full chargeback rights. topropay exposes both through the same unified API — the routing engine picks the optimal rail per authorisation.
Yes. Recurring direct debits are the highest-value use case for bank rails: cost per transaction drops well below card, and the mandate captured on first payment authorises future debits. Scheme-specific mandate retention rules (NACHA, SEPA, Bacs) are all handled server-side. The recurring engine drives the debit schedule and R-code-aware retries.
Bank rails have return / dispute mechanisms rather than card-style chargebacks. ACH has R-code returns (funding, account, authorisation, error). SEPA SDD has an unconditional 8-week refund window plus a 13-month unauthorised-transaction refund. Bacs has an indemnity claim path. The platform surfaces the rail-specific dispute path in the same unified dispute queue as card chargebacks.
Bank-rail coverage today includes ACH (USD), SEPA (EUR across SEPA-zone), Bacs / Faster Payments (GBP), Interac (CAD), PIX (BRL) and PayID / OSKO (AUD). Additional rails are added via partner connectivity as they come online in target markets. Multi-currency settlement is handled at the platform level.
Merchants who already have their card side live on topropay typically add direct rails inside 1–2 weeks — the onboarding is a routing-policy and mandate-capture configuration rather than a fresh integration. Fresh merchants take 2–4 weeks including KYB and any rail-processor scheme registrations.
Yes. A merchant can enable direct rails without turning on card acceptance if that's the target model — for example, a payroll platform that only ever pushes ACH direct deposits. The same API contract applies; card-side capabilities remain available for the merchant to enable later without re-onboarding.
ACH refunds push a credit through the same mandate. SEPA SDD refunds follow the scheme's own refund path (customer-initiated refund within 8 weeks; unauthorised-transaction refund within 13 months). Bacs refunds ride the indemnity claim path. Every refund is tagged to the original vault token and mandate ID for the audit trail.
Direct-rail transactions (ACH, SEPA, Bacs, Interac) don't involve card data, so they're out of PCI DSS scope on the card-data side. Merchants who run both card and direct rails still inherit the PCI DSS Level 1 vault for the card side; the direct-rail side sits under NACHA / SEPA scheme compliance instead.
Related